代码审查(code review)的意义

个人理解，code review有两个作用：

1. 两个人总比一个人想的周全，看问题的角度不一样更容易发现BUG或找到更简单有效的解决方案。所谓旁观者清就是这个道理。

2. 理想状态下团队的每个人都要对项目的每个部分都很熟悉，但当项目很大时这不大现实，通过代码审查至少可以让每个人了解更多的业务模块，同时也能达到人员互备的目的。

同时代码审查要注意如下问题：

1. 审核者与被审核者的不存在能力高低问题。代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这是一个误区。

2. 代码审查本身可以提高开发者的能力：被审查者从自身犯过的错误中学习，从他人的思路中学习；审查者从审查的思考过程中学习，从被审查者好的设计中学习。

3. 代码审查不涉及奖惩机制，即便有也是对审查者和被审查者同时的奖励或处罚，也就是说两者要同时对交付负责。

code review采取的方式：

实践中，我们团队成员建议的闭环式审查很适用。如4个人的子团队，审查关系为A --> B --> C --> D --> A（B审查A，C审查B，D审查C，A审查D）。当然，要适成员能力做到高低的有效穿插。那么让初级工程师审查高级工程师的代码是否有问题呢，能发现BUG么？首先，肯定能发现BUG，只是多少和频率的问题；其次，即便初级工程师发现不了高级工程师的BUG，在审查高级工程师的代码时也能学习到好的思路和业务知识，这也是很有意义的，间接起到培训的作用了。

code review的单元粒度及时间问题：

以future和task任务为单元做review较容易实施，大规模review可以在重大改进时单独发起。同时，把review结合到任务工作流里也是不错的实践。如：start --> 设计 --> 开发 --> code review --> 测试 --> 产品确认 --> end。

一个review单元的时间应控制在10~20分钟。如果超出这个时间，可能是如下几个原因：

1. 如果20分钟一个reviewer还看不懂一个任务的代码，那么这个代码本身就存在问题，太复杂了；

2. reviewer不懂业务，那么开发者就需要向reviewer讲解下了，当然不需讲解就能看懂的代码自然是更好了；

3. 任务太大，代码太多，那么这个任务应该拆分，分阶段交付产出。

参考资源：

http://www.infoq.com/cn/news/2014/02/code-review-best-practice?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=%E7%BC%96%E7%A8%8B-news