代碼評審

代碼評審，是指通過閱讀代碼來檢查源代碼與編碼標準的符合性以及代碼質量的活動（也有工具支持自動檢查）。 

評審內容：

1. 編碼規範（包括註釋規範、變量命名規範、System.out<日誌使用>、代碼可讀性），

2. 代碼結構（重複代碼、大方法、耦合性等需要合理重構的點），

3. 複雜業務邏輯的實現代碼（這是個問題，業務邏輯實現是否需要評審呢？）

    複雜業務邏輯的評審應該以代碼作者講述流程爲主，大家梳理流程的同時評審代碼質量，可以順帶讓大家在共同梳理這個負雜邏輯的過程中發現邏輯的合理性。

4. 系統基礎資源的使用是否合理等

 

評審方式：

交叉評審：團隊成員互相檢查代碼。

會議集中評審：項目組成員共同評審，由負責人主導，應該選擇關鍵、邏輯複雜或者容易出問題的模塊進行重點評審。

 

評審時機：可以考慮在每個短週期期迭代的代碼實現完成時？還是...？

 

評審準備：評審提綱、評審模塊、參與者預先瀏覽相關代碼，可以先通過郵件評審方式，提出各自意見，包括優質代碼和劣質代碼，以便在真正評審會議時有重點針對性，減少逐行讀代碼的時間。

 

評審案例：用評審前的代碼與評審後優化的代碼做對比 ，觸發參與者對代碼評審的積極性
問題跟蹤：對評審中發現的問題代碼應加以跟蹤，確保問題得以解決，防止復發 

 

評審的意義：提高代碼質量，大家共同梳理複雜問題的過程，統一大家對公共、複雜邏輯的理解一致性等，加深對系統的理解。

 

參與人員：代碼評審很容易流於形式，尤其在外圍不瞭解邏輯，不瞭解系統架構及具體實現技術的人員參與時，個人認爲，很難取得好的效果。應該以項目組內成員參與爲主，同時引入外圍 技術 大拿可以從一些宏觀層面、公共技術層面給出意見，並對不確認問題給出結論，防止各持己見、爭論不休，當然，有爭論問題需要記錄並在會後達成一致性意見作爲規範。

 

很多東西不寫下來，僅僅是腦袋裏模糊不清的意識，零散的東西無法起到具體作用。以後得強迫自己多寫，不管當時想法有多少，儘量寫下來，慢慢豐富，集中整理應該會有好的效果。