代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。 Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性得被引入到软件开发过程中。
(代码评审、轻量级、流程正确、软件开发过程)
如何实现CodeReview？
最后一步合并由别人去做：查看别人提交的代码。@用户名。点击头像可以看到别人的@。最后点击merged。点击别人提交的注释就可以看到别人的修改。
Why we do Code Review(为什么进行)
1、提高代码质量
2、及早发现潜在缺陷与BUG，降低事故成本。
3、促进团队内部知识共享，提高团队整体水平
4、评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。
(知识共享、思路重构)
Types of Code Review(代码评审的几种类型)
一般来说，代码评审分为正式代码评审与轻量级代码评审两种
Formal Code Review(正式代码评审)
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.(记录员)
Options of Code Review(代码评审的选择)
1、最近一次迭代开发的代码
2、系统关键模块(封装好的网路请求框架、数据库框架)
3、业务较复杂的模块
4、缺陷率较高的模块
Practice of Code Review(代码评审实践)
1、代码评审不是批斗会，不能以缺陷和错误来打击开发人员的积极性，评审的目标的提高质量和提高整体水平，作者应该带着学习和提高的态度来参加评审。
2、代码集体所有制：对发现的问题要本着整体承担责任的原则，因此建议把代码质量与团队绩效（而不是个人绩效）挂钩。
3、评审程度，进行一次整体的地毯式的评审成本很高。
4、代码评审的可操作性，首先需要评审团队具备经验丰富的系统架构师和精通业务的行业专家。其次团队需建立其开发规范或指南，在项目初期建立少量的Sample代码与checklist为评审提供依据。
评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷。
记录评审中出现的问题，跟踪改进。
评审前充分准备，评审后详细总结。
不要因为时间和成本问题取消评审。
包括重构、代码逻辑、代码规范。
对于变更的代码，coder应该提供一份ChangeList，基于需求或者功能点，列举出增删改动了那些类和方法以及关键变量，这就迫使owner首先review一下自己的代码，从而首先自身发现一些问题。
对于代码重构，更需要这份清单，甚至是一个变更前后的类之间的关系图（当然可以从之前的LLD中复制过来）。额外的一个好处就是，重构会把很多方法原封不动的从一个类迁移到另一个辅助类，那么，reviewer就不用去care这些代码，而只是关心整体的结构，从而对症下药，对架构而不是代码，提出新的见解。