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

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

　　本人根據針對網路上某程式碼評審最佳實踐的公開文章談談自己的想法。

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

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

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

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

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

－－》　我的觀點：檢查清單對程式碼作者和評審者都有作用。對程式碼作者來說，可以在編碼的時候就犯止犯類似的錯誤。對評審者來說，可以幫助評審得更全面，特別是找出遺漏的問題。檢查清單可以定期更新，在評審過程中發現的問題都可以對照檢查清單，看看是否需要新增新的條目。最新的檢查清單需要在團隊內公佈，最好是放在一個固定的位置方便隨時檢視。這個檢查清單可以考慮和編碼規範放在一個文件，互為對照補充。

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

－－》　我的觀點：為什麼需要完全正面的看待在評審中發現的問題？如前文所述，在程式碼評審中發現問題的修復成本非常低，所以發現越多問題越是好事。只有完全正面看待程式碼評審發現的問題，評審者才會有更大的動機會發現更多的問題。對於程式碼作者來說，在程式碼評審中發現問題，可以幫助自己修正錯誤的編碼習慣和提高自身的編碼能力。同時，完全正面看待評審發現的問題，能使得評審者和程式碼作者建立更為和諧的關係，更有利於發現更多問題。為了建立正面評審文化，領導者需要在團隊中宣貫在評審中發現問題表明程式碼作者和評審者通過成功的團隊合作提高了程式碼質量，領導者絕對不應將評審中發現的問題列入任何針對個人的考核因子。

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

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

　　另外，我想再做一些補充。對設計的評審應該基於設計文件，在程式碼評審階段去評審設計將會是低效的並且需要花費巨大的溝通成本。當然如果在程式碼評審階段發現了設計的問題，需要回過頭去重新修改＆評審設計文件。

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

&n