隨筆 - 62  文章 - 1 評論 - 727 trackbacks - 4

我一直認為Code Review(代碼審查)是軟件開發中的最佳實踐之一,可以有效提高整體代碼質量,及時發現代碼中可能存在的問題。包括像Google、微軟這些公司,Code Review都是基本要求,代碼合并之前必須要有人審查通過才行。

 

然而對于我觀察到的大部分軟件開發團隊來說,認真做Code Review的很少,有的流于形式,有的可能根本就沒有Code Review的環節,代碼質量只依賴于事后的測試。也有些團隊想做好代碼審查,但不知道怎么做比較好。

 網上關于如何做Code Review的文章已經有很多了,這里我結合自己的一些經驗,也總結整理了一下Code Review的最佳實踐,希望能對大家做好Code Review有所幫助。

Code Review有什么好處?

很多團隊或個人不做Code Review,根源還是不覺得這是一件有意義的事情,不覺得有什么好處。這個問題要從幾個角度來看。

  • 首先是團隊知識共享的角度 

一個開發團隊中,水平有高有低,每個人側重的領域也有不同。怎么讓高水平的幫助新人成長?怎么讓大家都對自己側重領域之外的知識保持了解?怎么能有人離職后其他人能快速接手?這些都是團隊管理者關心的問題。

而代碼審查,就是一個很好的知識共享的方式。通過代碼審查,高手可以直接指出新手代碼中的問題,新手可以馬上從高手的反饋中學習到好的實踐,得到更快的成長;通過代碼審查,前端也可以去學習后端的代碼,做功能模塊A的可以去了解功能模塊B的。

可能有些高手覺得給新手代碼審查浪費時間,自己也沒收獲。其實不然,新人成長了,就可以更多的幫高手分擔繁重的任務;代碼審查中花時間,就少一些幫新人填坑擦屁股的時間;良好的溝通能力、發現問題的能力、幫助其他人成長,都是技術轉管理或技術上更上一層樓必不可少的能力,而通過代碼審查可以有效的去練習這些方面的能力。

  • 然后是代碼質量的角度

現實中的項目總是人手缺進度緊,所以被壓縮的往往就是自動化測試和代碼審查,結果影響代碼質量,欠下技術債務,最后還是要加倍償還。

也有人寄希望于開發后的人工測試,然而對于代碼質量來說,很多問題通過測試是測試不出來的,只能通過代碼審查。比如說代碼的可讀性可維護性,比如代碼的結構,比如一些特定條件才觸發的死循環、邏輯算法錯誤,還有一些安全上的漏洞也更容易通過代碼審查發現和預防。 

也有人覺得自己水平高就不需要代碼審查了。對于高手來說,讓別人審查自己的代碼,可以讓其他人學習到好的實踐;在讓其他人審查的同時,在給別人說明自己代碼的時候,也等于自己對自己的代碼進行了一次審查。這其實就跟我們上學時做數學題一樣,真正能拿高分的往往是那些做完后還會認真檢查的。

  • 還有團隊規范的角度 

每個團隊都有自己的代碼規范,有自己的基于架構設計的開發規范,然而時間一長,就會發現代碼中出現很多不遵守代碼規范的情況,有很多繞過架構設計的代碼。比如難以理解和不規范的命名,比如三層架構里面UI層繞過業務邏輯層直接調用數據訪問層代碼。 

如果這些違反規范的代碼被糾正的晚了,后面再要修改就成本很高了,而且團隊的規范也會慢慢的形同虛設。

通過代碼審查,就可以及時的去發現和糾正這些問題,保證團隊規范的執行。

關于代碼審查的好處,還有很多,也不一一列舉。還是希望能認識到Code Review和寫自動化測試一樣,都是屬于磨刀不誤砍柴工的工作,在上面投入一點點時間,未來會收獲代碼質量,會節約整體的開發時間。

該怎么做? 

現在很多人都已經有意識到Code Review的重要性了,只是苦于不知道如何去實踐,不知道怎么樣算是好的Code Review實踐。

把Code Review作為開發流程的必選項而不是可選項

在很早以前,我就嘗試過將代碼審查作為代碼流程的一部分,但只是一個可選項,沒有Code Review也可以把代碼合并到master。這樣的結果就是想起來才會去做Code Review,去檢查的時候已經有了太多的代碼變更,審查起來非常困難,另外就算審查出問題,也很難得以修改。 

我們現在對代碼的審查則是作為開發流程的一個必選項,每次開發新功能或者修復Bug,開一個新的分支,分支要合并到master有兩個必要條件:

  • 所有的自動化測試通過
  • 有至少一個人Code Review通過,如果是新手的PR,還必須有資深程序員Code Review通過

圖片來源:How to Do Code Reviews Like a Human

這樣把Code Review作為開發流程的一個必選項后,就很好的保證了代碼在合并之前有過Code Review。而且這樣合并前要求代碼審查的流程,好處也很明顯:

  • 由于每一次合并前都要做代碼審查,這樣一般一次審查的代碼量也不會太大,對于審查者來說壓力也不會太大
  • 如果在Code Review時發現問題,被審查者希望代碼能盡快合并,也會積極的對審查出來的問題進行修改,不至于對審查結果太過抵觸

如果你覺得Code Review難以推行,不妨先嘗試著把Code Review變成你開發流程的一個必選項。

把Code Review變成一種開發文化而不僅僅是一種制度

把Code Review 作為開發流程的必選項后,不代表Code Review這件事就可以執行的很好,因為Code Review 的執行,很大部分程度上依賴于審查者的認真審查,以及被審查者的積極配合,兩者缺一不可!

如果僅僅只是當作一個流程制度,那么就可能會流于形式。最終結果就是看起來有Code Review,但沒有人認真審查,隨便看下就通過了,或者發現問題也不愿意修改。

真要把Code Review這件事做好,必須讓Code Review變成團隊的一種文化,開發人員從心底接受這件事,并認真執行這件事。

要形成這樣的文化,不那么容易,也沒有想象的那么難,比如這些方面可以參考:

  • 首先,得讓開發人員認識到Code Review這件事為自己、為團隊帶來的好處
  • 然后,得要有幾個人做好表率作用,榜樣的力量很重要
  • 還有,對于管理者來說,你激勵什么,往往就會得到什么
  • 最后,像寫自動化測試一樣,把Code Review要作為開發任務的一部分,給審查者和被審查者都留出專門的時間去做這件事,不能光想著馬兒跑得快又舍不得給馬兒吃草 

如何形成這樣的文化,有心的話,還有很多方法可以嘗試。只有真正讓大家都認同和踐行,才可能去做好Code Review這件事。

一些Code Review的經驗技巧

在做好Code Review這件事上,還有一些經驗技巧可以參考。

選什么工具輔助做CODE REVIEW?

現在很多源代碼管理工具都自帶Code Review工具,典型的像Github、Gitlab、微軟的Azure DevOps,尤其是像Gitlab,還可以自己在本地搭建環境,根據自己的需要靈活配置。 

配合什么樣的開發流程比較好?

Github Flow這樣基于分支開發的流程是特別適合搭配Code Review的。其實不管什么樣的開發流程,關鍵點在于代碼合并到master(主干)之前,要先做Code Review。

真遇到緊急情況,來不及代碼審查怎么辦? 

雖然原則上,必須要Code Review才能合并,但有時候確實會存在一些緊急情況,比如說線上故障補丁,而又沒有其他人在線,那么這種情況下,最好是在任務管理系統中,創建一個Ticket,用來后續跟蹤,確保后續補上Code Review,并對Code Review結果有后續的代碼更新。

先設計再編碼

有些新人發現自己的代碼提交PR(Pull Request)后,會收到一堆的Code Review意見,必須要做大量的改動。這多半是因為在開始做之前,沒有做好設計,做出來后才發現問題很多。 

建議在做一個新功能之前,寫一個簡單的設計文檔,表達清楚自己的設計思路,找資深的先幫你做一下設計的審查,發現設計上的問題。設計上沒問題了,再著手開發,那么到Review的時候,相對問題就會少很多。

代碼在提交CODE REVIEW之前,作者要自己先REVIEW和測試一遍 

我在做代碼審查的時候,有時候會發現一些非常明顯的問題,有些甚至自己都沒有測試過,就等著別人Code Review和測試幫助發現問題。這種依賴心理無論是對自己還是對團隊都是很不負責任的。 

一個好的開發人員,代碼在提交Code Review之前,肯定是要自己先Review一遍,把該寫的自動化測試代碼寫上,自己把基本的測試用例跑一遍的。 

我對于團隊提交的PR,有個要求就是要在PR的描述中增加截圖或者錄屏,就是為了通過截圖或者錄屏,確保提交PR的人自己是先測試過的。這也是一個有效的輔助手段。

PR要小 

在做Code Review的時候,如果有大量的文件修改,那么Review起來是很困難的,但如果PR比較小,相對就比較容易Review,也容易發現代碼中可能存在的問題。

所以在提交PR時,PR要小,如果是比較大的改動,那么最好分批提交,以減輕審查者的壓力。

對評論進行分級

在做Code Review時,需要針對審查出有問題的代碼行添加評論,如果只是評論,有時候對于被審查者比較難甄別評論所代表的含義,是不是必須要修改。

建議可以對Review的評論進行分級,不同級別的結果可以打上不同的Tag,比如說:

  • [blocker]: 在評論前面加上一個[blocker]標記,表示這個代碼行的問題必須要修改
  • [optional]:在評論前面加上一個[optional]標記,表示這個代碼行的問題可改可不改
  • [question]:在評論前面加上一個[question]標記,表示對這個代碼行不理解,有問題需要問,被審查者需要針對問題進行回復澄清 

類似這樣的分級可以幫助被審查者直觀了解Review結果,提高Review效率。

評論要友好,避免負面詞匯;有說不清楚的問題當面溝通 

雖然評論是主要的Code Review溝通方式,但也不要過于依賴,有時候面對面的溝通效率更高,也容易消除誤解。

另外文明用語,不要用一些負面的詞匯。 

總結 

Code Review是一種非常好的開發實踐,如果你還沒開始,不妨逐步實踐起來;如果已經做了效果不好,不妨對照一下,看有沒有把Code Review作為開發流程的必選項而不是可選項?有沒有把Code Review變成一種開發文化而不僅僅是一種制度?

posted on 2019-07-20 01:35  寶玉  閱讀(14978)  評論(31編輯  收藏
最新chease0ldman老人|无码亚洲人妻下载|大香蕉在线看好吊妞视频这里有精品www|亚洲色情综合网