代碼評審

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

高效代碼審查的十個經驗

http://www.csdn.net/article/2012-11-07/2811609-Efficient-Code-Review-10-Experience


摘要：我們在實踐中發現，隨著開發平臺和開發語言的不同，最優的代碼審查量有所不同。但是限制每次審查的數量確實非常必要，因為這個過程是高強度的腦力密集型活動。時間一長，代碼在審查者眼里只是字母，無任何邏輯聯系，自然不會有太多的產出。
代碼審查（Code Review)是軟件開發中常用的手段，和QA測試相比，它更容易發現和架構以及時序相關等較難發現的問題，還可以幫助團隊成員提高編程技能，統一編程風格等。


1.代碼審查要求團隊有良好的文化

團隊需要認識到代碼審查是為了提高整個團隊的能力，而不是針對個體設置的檢查“關卡”。

“A的代碼有個bug被B發現，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴散從而影響團隊內部的協作，因此需要避免。另外，代碼審查本身可以提高開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。如果開發者對這個流程有抵觸或者反感，這個目的就達不到。

2.謹慎的使用審查中問題的發現率作為考評標準

高效代碼審查的十個經驗

在代碼審查中如果發現問題，對于問題的發現者來說這是好事，應該予以鼓勵。但對于被發現者，我們不主張使用這個方式予以懲罰。軟件開發中bug在所難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔責任，不愿意在審查中指出問題，代碼審查就沒有任何的價值和意義。

3.控制每次審查的代碼數量

根據smartbear在思科所作的調查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發現問題的能力就會下降，具體的比例關系如下圖所示：

高效代碼審查的十個經驗

我們在實踐中發現，隨著開發平臺和開發語言的不同，最優的代碼審查量有所不同。但是限制每次審查的數量確實非常必要，因為這個過程是高強度的腦力密集型活動。時間一長，代碼在審查者眼里只是字母，無任何邏輯聯系，自然不會有太多的產出。

4.帶著問題去進行審查

我們在每次代碼審查中，要求審查者利用自身的經驗先思考可能會碰到的問題，然后通過審查工作驗證這些問題是否已經解決。一個竅門是，從用戶可見的功能出發，假設一個比較復雜的使用場景，在代碼閱讀中驗證這個使用場景是否能夠正確工作。

使用這個技巧，可以讓審查者有代入感，真正的沉浸入代碼中，提高效率。大家都知道看武俠小說不容易瞌睡，而看專業書容易瞌睡，原因就是武俠小說更容易產生代入感。

有的研究建議每次樹立目標，控制單位時間內審核的代碼數量。這個方法在我們的實踐中顯得很機械和流程化，不如上面的方法效果好。

5.所有的問題和修改，必須由原作者進行確認

如果在審查中發現問題，務必由原作者進行確認。

這樣做有兩個目的：

確認問題確實存在，保證問題被解決
讓原作者了解問題和不足，幫助其成長
有些時候為了追求效率，有經驗的審查者更傾向于直接修改代碼乃至重構所有代碼，但這樣不利于提高團隊效率，并且會增加因為重構引入新bug的幾率，通常情況下我們不予鼓勵。

6.利用代碼審查激活個體“能動性"

即使項目進度比較緊張，無法完全的進行代碼審查，至少也要進行部分代碼的審查，此時隨即抽取一些關鍵部分是個不錯的辦法。

背后的邏輯是，軟件開發是非常有創造性的工作，開發者都有強烈的自我驅動性和自我實現的要求。讓開發者知道他寫的任何代碼都可能被其他人閱讀和審察，可以促使開發者集中注意力，尤其是避免將質量糟糕，乃至有低級錯誤的代碼提交給同伴審查。開源軟件也很好的利用了這種心態來提高代碼質量。

7.在非正式，輕松的環境下進行代碼審查

如前所述，代碼審查是一個腦力密集型的工作。參與者需要在比較輕松的環境下進行該工作。因此，我們認為像某些實踐中建議的那樣，以會議的形式進行代碼審查效果并不好，不僅因為長時間的會議容易讓效率低下，更因為會議上可能出現的爭議和思考不利于進行如此復雜的工作。

8.提交代碼前自我審查，添加對代碼的說明

所有團隊成員在提交代碼給其他成員審查前，必須先進行一次審查。這次自我修正形式的審查除了檢查代碼的正確性以外，還可以完成如下的工作：

對代碼添加注釋，說明本次修改背后的原因，方便其他人進行審查。
修正編碼風格，尤其是一些關鍵數據結構和方法的命名，提高代碼的可讀性。
從全局審視設計，是否完整的考慮了所有情景。在實現之前做的設計如果存在考慮不周的情況，這個階段可以很好的進行補救。
我們在實踐中發現，即使只有原作者進行代碼審查，仍然可以很好的提高代碼質量。

9.實現中記錄筆記可以很好的提高問題發現率

成員在編碼的時候應做隨手記錄，包括在代碼中用注釋的方式表示，或者記錄簡單的個人文檔，這樣做有幾個好處：

避免遺漏。在編碼時將考慮到的任何問題都記錄下來，在審查階段再次檢查這些問題都確認解決。
根據研究，每個人都習慣犯一些重復性的錯誤。這類問題在編碼是記錄下來，可以在審查的時候用作檢查的依據。
在反復記錄筆記并在審查中發現類似的問題后，該類問題出現率會顯著下降
10.使用好的工具進行輕量級的代碼審查

“工欲善其事，必先利其器”。我們使用的是bitbucket提供的代碼托管服務。

每個團隊成員獨立開發功能，然后利用Pull Request的形式將代碼提交給審查者。復審者可以很方便在網頁上閱讀代碼，添加評論等，然后原作者會自動收到郵件提醒，對審閱的意見進行討論。

即使團隊成員分布在天南海北，利用bitbucket提供的工具也能很好的進行代碼審查。
========

代碼審查總結

http://blog.csdn.net/limingjian/article/details/40455071
? ? ? ?最近所帶項目，因為人員素質良莠不齊，寫出的代碼質量不一，為了保證項目質量，不得不對代碼一行行進行審查。同時，為了對代碼審查有個更深的了解及借鑒其它同行實踐成果，在網上搜集了不少項目知識，下面是對這些知識做出的整理。
第1章前提
? ? ? ?在 Wikipedia 上，對代碼審查的定義是：代碼審查（英語：Code Review）是指對計算機源代碼系統化地審查，常用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提升軟件質量及開發者的技術。代碼審查常以不同的形式進行，例如結對編程、非正式的看過整個代碼，或是正式的軟件檢查。
1.1代碼審查首先要求團隊有良好的文化
? ? ? 團隊需要認識到代碼審查是為了提高整個團隊的能力，而不是針對個體設置的檢查“關卡”?！癆的代碼有個bug被B發現，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴散從而影響團隊內部的協作，因此需要避免。另外，代碼審查本身可以提高開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。如果開發者對這個流程有抵觸或者反感，這個目的就達不到。
1.2謹慎的使用審查中問題的發現率作為考評標準
? ? ? 在代碼審查中如果發現問題，對于問題的發現者來說這是好事，應該予以鼓勵。但對于被發現者，我們不主張使用這個方式予以懲罰。軟件開發中bug在所 難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔責任，不愿意在審查中指出問題，代碼審查就沒有任何的價值和意義。
第2章代碼質量的屬性
可理解性：代碼需要在各個層面上能夠被容易地理解。理想情況下，軟件應該非常簡單，并沒有非常明顯的缺陷。
可測試性：代碼需要被編寫的非常容易被測試。
正確性：代碼需要滿足功能和非功能性的需求。代碼的行為是否與預期一致，其邏輯是否是正確無誤的？被審查的代碼是否與其他代碼擁有類似的結構和功能？
有效性：代碼需要有效的使用系統資源（內存，CPU，網絡連接，等）。
第3章做代碼審查的好處
更容易發現和架構以及時序相關等較難發現的問題。
幫助團隊成員提高編程技能
統一編程風格
第4章代碼質量低下的癥狀
所有事情都很艱難
進度慢
測試套件運行緩慢
無法避免的缺陷
你的團隊是消極的
知識缺乏共享
新開發人員成長周期太長
第5章怎么審查
1個Review流程：先Review設計實現思路，然后Review設計模式，接著Review成形的骨干代碼，最后 Review完成的代碼，如果程序復雜的話，需要拆成幾個單元或模塊分別Review。
盡可能的讓不同的人Reivew你的代碼：不要總是只找一個人來Review你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼，有的從實現的角度，有的從需求的角度，有的從用戶使用的角度，有的從算法的角度，有的從性能效率的角度，有的從易讀的角度，有的從擴展性的角度……這樣以后會有更多的人幫你在日后維護你的代碼。
保持積極的正面的態度：程序最大的問題就是“自負”，尤其當我們Reivew別人的代碼的時候。所以，無論是代碼作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在一個戰壕里的戰友。
控制每次審查的代碼規模：根據smartbear在思科所作的調查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發現問題的能力就會下降。
要帶著問題去做：我們在每次代碼審查中，要求審查者利用自身的經驗先思考可能會碰到的問題，然后通過審查工作驗證這些問題是否已經解決。一個竅門是，從用戶可見的功能出發，假設一個比較復雜的使用場景，在代碼閱讀中驗證這個使用場景是否能夠正確工作。使用這個技巧，可以讓審查者有代入感，真正的沉浸入代碼中，提高效率。
盡量使用靜態代碼分析工具以提高審查效率。
二八定律處理高風險代碼：審查所有的代碼并沒有太大的意義，應該把審查的重點放在高風險的代碼和容易引起高風險的修改或者重構的代碼上。舊而復雜、處理敏感數據、處理重要業務邏輯和流程、大規模重構以及剛加入團隊的開發者實現的代碼都是審查的重點。
讓原作者對發現的問題進行確認：這樣做有兩個目的，確認問題確實存在，保證問題被解決；讓原作者了解問題和不足，幫助其成長。
自我審查：所有團隊成員在提交代碼給其他成員審查前，必須先進行一次審查。這次自我修正形式的審查除了檢查代碼的正確性以外，還可以完成如下的工作：
?對代碼添加注釋，說明本次修改背后的原因，方便其他人進行審查。
?修正編碼風格，尤其是一些關鍵數據結構和方法的命名，提高代碼的可讀性。
從全局審視設計，是否完整的考慮了所有情景。在實現之前做的設計如果存在考慮不周的情況，這個階段可以很好的進行補救。
代碼審查結束后的回顧總結：成員在編碼的時候應做隨手記錄，包括在代碼中用注釋的方式表示，或者記錄簡單的個人文檔，這樣做有幾個好處：
?避免遺漏。在編碼時將考慮到的任何問題都記錄下來，在審查階段再次檢查這些問題都確認解決。
根據研究，每個人都習慣犯一些重復性的錯誤。這類問題在編碼是記錄下來，可以在審查的時候用作檢查的依據。
在反復記錄筆記并在審查中發現類似的問題后，該類問題出現率會顯著下降。
第6章實踐要素
人員結構
? ? ? 在你的團隊中有多少同事擁有足夠的專業技能來擔當合格的代碼審查者？作者曾經和多個開發團隊溝通過，這些團隊都聲稱本身只有一個資深的開發人員，如果讓他來負責所有的代碼審查工作，那么團隊的核心開發就無法開展了。作者也遇到過類似的情況。在一個小規模團隊里，資深的同事總是忙不過來，因為核心的工作都在等著他做。
地理位置
? ? ?你的團隊成員是如何分布的？他們是否是分散在世界各地還是坐在同一個敞亮的辦公室里？ 代碼審查需要精力的專注和反饋，如果開發人員能夠面對面的溝通，那么審查工作會便于實施。而物理隔離的遠程團隊很難達到代碼審查的滿意結果。
所在領域
? ? ?你所在的IT領域需要遵守怎樣的規則和約束呢？如果你在一個受到嚴格監管的行業，那么你必須遵循有關審計和報告的規則，這意味著你必須想辦法跟蹤代碼審查的頻率和質量。如果所在的領域把安全性作為重點，那么可能在代碼審查過程中要引入安全審計。
復雜性
? ? ?你的代碼復雜性如何？在代碼審查時，需要多個不同專業技能的審查者嗎？例如，游戲開發可能會引入非常復雜的業務邏輯來處理文字交互和場景跟蹤，同時還需要特定的動畫處理和內存管理技術。在審查如此復雜的代碼時，應該引入多個審查者從不同角度來檢閱代碼的質量。
第7章一個時間安排的例子
? ? ? Eric Landes在一篇名為《敏捷技巧：什么時候以什么方式來進行代碼評審》的文章中，提供了一個時間安排的例子：
概覽本次代碼評審的故事(10分鐘)
討論團隊指標(10分鐘)
強調評審的特別關注點(5分鐘)
深入地評審代碼(55分鐘)
代碼覆蓋率
架構
深入的分析報告
總結并記錄行動事項(10分鐘)

第8章代碼檢查工具
Review board
Codestriker
Groogle
Rietveld
JCR
Jupiter
Find bugs
第9章參考資料
敏捷開發下平衡質量和進度
堅果云開發團隊分享高效代碼審查經驗
Code Review中的幾個提示
簡單實用的Code Review工具
從Code Review 談如何做技術
代碼整潔之所以重要的七個理由
揭秘Google是如何做代碼審查的
讓代碼審查成為你的團隊習慣
關于代碼審查的幾點建議
我們如何進行代碼審查
========

總結

以上是生活随笔為你收集整理的代码审查学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。