为什么进行
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为评审提供依据。
评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷。
记录评审中出现的问题，跟踪改进。
评审前充分准备，评审后详细总结。
不要因为时间和成本问题取消评审。
