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