代碼評審

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