為什麼進行
1、提高質量
2、及早發現潛在缺陷與BUG，降低事故成本。
3、促進團隊内部知識共享，提高團隊整體水平
4、評審過程對于評審人員來說，也是一種思路重構的過程。幫助更多的人理解系統。
代碼評審的幾種類型
一般來說，代碼評審分為正式代碼評審與輕量級代碼評審倆種
正式代碼評審
Fagan inspection（範根檢查法）:
RolesAuthor/Designer/Coder:作者
Reader: paraphrases the document（閱讀者）
Tester: reviews the document from a testing standpoint（評審員）
Moderator: responsible for the inspection session, functions as a coach（協調人）
Recorder：record detects.(記錄員)
Flow
輕量級代碼評審
幾種常見的輕量級代碼評審方式：
Over-the-shoulder–One developer looks over the author’s shoulder as the latter walks through the code.（它由作者啟動和主持評審，作者向評審者展示文檔。優點是啟動快，成本低，缺點是容易被作者誤導過程）
Email pass-around–Source code management system emails code to reviewers automatically after checkin is made.（優點自動化，可以及時提供最新代碼進行評審，缺點是無法達到人工篩選的功效）
Pair Programming–Two authors develop code together at the same workstation, such is common in Extreme Programming.（源于XP，作者與評審者平級，可以幫助同伴間的學習和共享）
Review Meeting–(定期組織review會議，輪流有團隊成員選出自己的評審作品，需要系統化得預備、總結和追蹤。優點可以提高團隊整體技能和對産品的理解，缺點是評審範圍有限，成本較高 )
Tool-assisted code review–Authors and reviewers use specialized tools designed for peer code review.（大量的代碼評審工具，比較流行的checkstyle/findbugs/pmd）
本文以下内容都是指針對輕量級代碼評審進行進一步讨論。
代碼評審的選擇
1、最近一次叠代開發的代碼
2、系統關鍵模塊
3、業務較複雜的模塊
4、缺陷率較高的模塊
代碼評審實踐
代碼評審不是批鬥會，不能以缺陷和錯誤來打擊開發人員的積極性評審的目标的提高質量和提高整體水平，作者應該帶着學習和提高的态度來參加評審。
代碼集體所有制：對發現的問題要本着整體承擔責任的原則，因此建議把代碼質量與團隊績效（而不是個人績效）挂鈎。
評審程度，進行一次整體的地毯式的評審成本很高。
代碼評審的可操作性，首先需要評審團隊具備經驗豐富的系統架構師和精通業務的行業專家。其次團隊需建立其開發規範或指南，在項目初期建立少量的Sample代碼與checklist為評審提供依據。
評審人員的職責是發現工作成果中的缺陷，并幫助開發人員給出消除缺陷的辦法，而不是替開發人員消除缺陷。
記錄評審中出現的問題，跟蹤改進。
評審前充分準備，評審後詳細總結。
不要因為時間和成本問題取消評審。
