談談代碼評審(code review)

　　什麼是代碼評審(code review)? 根據維基百科的定義，代碼評審是一種經過若干人員檢閱源代碼方式來進行的軟件質量保證活動。根據軟件工程的經典理論，代碼評審應該是收益很高的活動，因其產生在Coding階段（屬於開發生命週期的早期），在開發生命週期越早發現問題，解決問題的成本越低。工程實踐也能印證這個結論。 代碼評審有如下目標：

• 提升代碼質量和可維護性（可讀性，一致性）
• 發現代碼缺陷
• 知識經驗傳承
• 發現更好的解決方案
• 知足ＱＡ指導方針

　　本人根據針對網絡上某代碼評審最佳實踐的公開文章談談本身的想法。

原則１：每次只評審小於２００～４００行的代碼。

－－》　個人觀點：這個只要是考慮到一次評審的代碼過多，評審者發現問題的能力將大量縮小。若是一次評審過多代碼，會對評審者帶來智力和心理兩方面的挑戰。從智力上來講，拋開極少數智力超羣者不談，對普通人來講，一次評審更少許的代碼更容易理解代碼的意圖（同時減小了與代碼做者的溝通成本，提升效率）。這也是符合分而治之的解決問題方法論的。從心理上來講，一次評審過多代碼會對評審者產生倦怠感，評審者主觀上一般會下降評審的細緻度。根據個人經驗，若是某項軟件開發任務代碼量比較大，可將此任務分解爲若干子任務。子任務的劃分粒度儘可能作到一週的代碼提交量（提交的代碼須要測試經過）。固然，子任務的劃分是創建在良好的設計文檔基礎上，不然子任務劃分的隨意度比較高且工做量評估容易不許確。

原則２：代碼評審速度應小於每小時３００～５００行。

－－》　個人觀點：這條主要是考慮評審的細緻度，細緻度越高越能發現更多問題。換算一下，一個２０行的函數，評審時間應很多於２～４分鐘。

原則３：檢查清單（checklist）能夠大幅改善評審結果

－－》　個人觀點：檢查清單對代碼做者和評審者都有做用。對代碼做者來講，能夠在編碼的時候就犯止犯相似的錯誤。對評審者來講，能夠幫助評審得更全面，特別是找出遺漏的問題。檢查清單能夠按期更新，在評審過程當中發現的問題均可以對照檢查清單，看看是否須要添加新的條目。最新的檢查清單須要在團隊內公佈，最好是放在一個固定的位置方便隨時查看。這個檢查清單能夠考慮和編碼規範放在一個文檔，互爲對照補充。

原則４：團隊領導者應創建一種正面的評審文化，即應正面看待評審中發現的問題

－－》　個人觀點：爲何須要徹底正面的看待在評審中發現的問題？如前文所述，在代碼評審中發現問題的修復成本很是低，因此發現越多問題越是好事。只有徹底正面看待代碼評審發現的問題，評審者纔會有更大的動機會發現更多的問題。對於代碼做者來講，在代碼評審中發現問題，能夠幫助本身修正錯誤的編碼習慣和提升自身的編碼能力。同時，徹底正面看待評審發現的問題，能使得評審者和代碼做者創建更爲和諧的關係，更有利於發現更多問題。爲了創建正面評審文化，領導者須要在團隊中宣貫在評審中發現問題代表代碼做者和評審者經過成功的團隊合做提升了代碼質量，領導者絕對不該將評審中發現的問題列入任何針對我的的考覈因子。

原則５：輕量級的代碼評審是有效率的和現實的

－－》　個人觀點：軟件工程理論中很是正式的代碼評審通常要召集不一樣角色的工程師，經過召開會議來逐行審查代碼並進行討論。可是這種方式成本比較昂貴，較少有公司可以負擔起這種人力成本。因此現今大部分公司都傾向於實施非正式的代碼評審，通常是基於工具。最簡單的非正式代碼評審能夠是基於郵件列表，缺點是沒法很好的記錄評審過程當中的修改歷史和溝通訊息。幸運的是，如今有不少能夠用於作代碼評審的工具，包括商業的和免費的。

　　另外，我想再作一些補充。對設計的評審應該基於設計文檔，在代碼評審階段去評審設計將會是低效的而且須要花費巨大的溝通成本。固然若是在代碼評審階段發現了設計的問題，須要回過頭去從新修改＆評審設計文檔。

　　綜上所述，輕量級的代碼評審對於業界大部分的軟件開發組織都是一個很好的選擇。是否在內部創建起正面的評審文化經常起決定性的做用。根據個人觀察，是否進行有效的代碼評審也基本上是區分二流軟件開發組織和三流軟件開發組織的一個明顯標誌：）