最近在考慮在公司建立代碼評審的機制，發(fā)現(xiàn)不像想象的那么簡單：
代碼評審的好處是毋庸置疑的，但也要付出成本，
而且評審別人的代碼是一個比較敏感的事，所以具體操作的時候也有許多要注意的問題。
下面是我整理的文檔準(zhǔn)備開會討論：
什么是代碼評審：
代碼評審也稱代碼復(fù)查，是指通過閱讀代碼來檢查源代碼與編碼標(biāo)準(zhǔn)的符合性以及代碼質(zhì)量的活動。
通過工具來進行code review不在本次討論范圍內(nèi)。
評審的內(nèi)容：
編碼規(guī)范問題：命名不規(guī)范、magic number、 System.out……
代碼結(jié)構(gòu)問題：重復(fù)代碼、巨大的方法和類、分層不當(dāng)、緊耦合
工具、框架使用不當(dāng)：Spring、Hibernate、AJAX
實現(xiàn)問題：錯誤驗證、異常處理、事務(wù)劃分、線程、性能、安全、實現(xiàn)過于復(fù)雜、代碼可讀性不佳、擴展性不好
測試問題：測試覆蓋度不夠、可測試性不好
代碼評審不負(fù)責(zé)檢查功能、邏輯是否正確，這些要靠單元測試和QA工作來解決
代碼評審的好處：
提高代碼質(zhì)量
在項目的早期發(fā)現(xiàn)缺陷，將損失降至最低
評審的過程也是重新梳理思路的過程，雙方都加深了對系統(tǒng)的理解
促進團隊溝通、促進知識共享、共同提高
交叉評審——代碼走查：團隊成員互相檢查代碼
參與者可以是任意兩個組員，或開發(fā)組長分別與每個組員結(jié)對進行
時機可以選擇在下班前半小時，對當(dāng)天改動的模塊進行評審
代碼作者講解如何以及為何這樣實現(xiàn)、評審者提出問題和建議
每次解決的問題要記錄到SVN注釋或JIRA
每次評審不要貪多，如下圖所示：當(dāng)一次評審超過400行代碼時，能發(fā)現(xiàn)缺陷數(shù)顯著降低——事倍功半
會審：以項目為單位，召開專門的代碼評審會議
參與者：包括項目組全體成員，其它組的開發(fā)組長也應(yīng)盡量參加
時機選擇：開發(fā)進行到某一階段時，對共性問題進行總結(jié)，對好的做法進行提煉和推廣
會前準(zhǔn)備工作：
組織者應(yīng)通知各參與者本次評審的范圍
參與者閱讀源代碼，列出發(fā)現(xiàn)的問題、亮點，匯總給組織者
準(zhǔn)備工作要細致，需要給出問題詳細描述以及相關(guān)代碼在SVN上的URL地址等
評審代碼的選擇：
最近一次迭代開發(fā)的代碼
系統(tǒng)關(guān)鍵模塊
業(yè)務(wù)較復(fù)雜的模塊
缺陷率較高的模塊
會議議程：
如果是第一次會議，先由該項目開發(fā)組長做整體介紹
參加者依次發(fā)言，結(jié)合代碼講解發(fā)現(xiàn)的問題
每講完一個問題，針對其展開討論，每個問題控制在10分鐘以內(nèi)
如果問題不多，還可以安排該組成員對最近開發(fā)的代碼進行地毯式的講解和排查；或者針對某個方面對整個項目做評審，例如性能、安全性或測試
會后總結(jié)：
把會上提出的所有問題、亮點及最終結(jié)論詳細的記錄下來，供其他團隊借鑒
未能討論清楚的問題，會后解決
實行代碼評審制度前的準(zhǔn)備工作：
架構(gòu)師提供開發(fā)規(guī)范、指南，為代碼評審提供依據(jù)
建立起單元測試規(guī)范，否則無法達到測試覆蓋度的要求、難以修正發(fā)現(xiàn)的問題
最好有樣例代碼庫作參照，以提高代碼評審的可操作性
提供評審案例：用評審前的代碼與評審后優(yōu)化的代碼做對比
問題跟蹤：對評審中發(fā)現(xiàn)的問題代碼應(yīng)加以跟蹤，確保問題得以解決，防止復(fù)發(fā)
評審到什么程度：
進行全面的代碼評審成本較高，也沒有必要
對發(fā)現(xiàn)的問題要本著集體代碼所有制的觀點和就事論事的原則，因此建議把代碼質(zhì)量與團隊績效（而不是個人績效）掛鉤。