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