代碼評審也稱代碼複查，是指通過閱讀代碼來檢查原始碼與編碼標準的符合性以及代碼質量的活動。
基本介紹
- 中文名：代碼評審
- 別名：代碼複查
- 性質：計算機
- 類別：檢查原始碼與編碼標準的符合性
評審的內容：,代碼評審的好處：,會前準備工作：,會議議程：,會後總結：,評審到什麼程度：,實踐要素：,人員結構,地理位置,所在領域,複雜性,
評審的內容：
通過工具來進行code review不在本次討論範圍內。
編碼規範問題：命名不規範、magic number、 System.out……
代碼結構問題：重複代碼、巨大的方法和類、分層不當、緊耦合
工具、框架使用不當：Spring、Hibernate、AJAX
代碼評審不負責檢查功能、邏輯是否正確，這些要靠單元測試和QA工作來解決
代碼評審的好處：
提高代碼質量
在項目的早期發現缺陷，將損失降至最低
評審的過程也是重新梳理思路的過程，雙方都加深了對系統的理解
促進團隊溝通、促進知識共享、共同提高
交叉評審——代碼走查：團隊成員互相檢查代碼
參與者可以是任意兩個組員，或開發組長分別與每個組員結對進行
時機可以選擇在下班前半小時，對當天改動的模組進行評審
代碼作者講解如何以及為何這樣實現、評審者提出問題和建議
每次解決的問題要記錄到SVN注釋或JIRA
每次評審不要貪多，如下圖所示：當一次評審超過400行代碼時，能發現缺陷數顯著降低——事倍功半
會審：以項目為單位，召開專門的代碼評審會議
參與者：包括項目組全體成員，其它組的開發組長也應儘量參加
時機選擇：開發進行到某一階段時，對共性問題進行總結，對好的做法進行提煉和推廣
會前準備工作：
組織者應通知各參與者本次評審的範圍
參與者閱讀原始碼，列出發現的問題、亮點，匯總給組織者
準備工作要細緻，需要給出問題詳細描述以及相關代碼在SVN上的URL地址等
評審代碼的選擇：
最近一次疊代開發的代碼
系統關鍵模組
業務較複雜的模組
缺陷率較高的模組
會議議程：
如果是第一次會議，先由該項目開發組長做整體介紹
參加者依次發言，結合代碼講解發現的問題
每講完一個問題，針對其展開討論，每個問題控制在10分鐘以內
如果問題不多，還可以安排該組成員對最近開發的代碼進行地毯式的講解和排查；或者針對某個方面對整個項目做評審，例如性能、安全性或測試
會後總結：
把會上提出的所有問題、亮點及最終結論詳細的記錄下來，供其他團隊借鑑
未能討論清楚的問題，會後解決
實行代碼評審制度前的準備工作：
架構師提供開發規範、指南，為代碼評審提供依據
最好有樣例代碼庫作參照，以提高代碼評審的可操作性
提供評審案例：用評審前的代碼與評審後最佳化的代碼做對比
問題跟蹤：對評審中發現的問題代碼應加以跟蹤，確保問題得以解決，防止復發
評審到什麼程度：
進行全面的代碼評審成本較高，也沒有必要
對發現的問題要本著集體代碼所有制的觀點和就事論事的原則，因此建議把代碼質量與團隊績效（而不是個人績效）掛鈎
實踐要素：
人員結構
在你的團隊中有多少同事擁有足夠的專業技能來擔當合格的代碼審查者？作者曾經和多個開發團隊溝通過，這些團隊都聲稱本身只有一個資深的開發人員，如果讓他來負責所有的代碼審查工作，那么團隊的核心開發就無法開展了。作者也遇到過類似的情況。在一個小規模團隊里，資深的同事總是忙不過來，因為核心的工作都在等著他做。
地理位置
你的團隊成員是如何分布的？他們是否是分散在世界各地還是坐在同一個敞亮的辦公室里？ 代碼審查需要精力的專注和反饋，如果開發人員能夠面對面的溝通，那么審查工作會便於實施。而物理隔離的遠程團隊很難達到代碼審查的滿意結果。
所在領域
你所在的IT領域需要遵守怎樣的規則和約束呢？如果你在一個受到嚴格監管的行業，那么你必須遵循有關審計和報告的規則，這意味著你必須想辦法跟蹤代碼審查的頻率和質量。如果所在的領域把安全性作為重點，那么可能在代碼審查過程中要引入安全審計。
複雜性
你的代碼複雜性如何？在代碼審查時，需要多個不同專業技能的審查者嗎？例如，遊戲開發可能會引入非常複雜的業務邏輯來處理文字互動和場景跟蹤，同時還需要特定的動畫處理和記憶體管理技術。在審查如此複雜的代碼時，應該引入多個審查者從不同角度來檢閱代碼的質量。
