如何做代码Code Review

预防胜于治疗，研究表明高效的 Code Review 可以发现70-90%的 bug，Review 作用如下：

• 提高团队代码标准，所有人共享同一套标准，阻止破窗效应

• 推动团队合作 reviewer 和 submitter 可能有不同的视角，主观的观点经常发生碰撞，促进相互学习

• 激励提交者，因为知道代码需要别人 review，所以提交者会倾向提升自己的代码质量。大部分程序员会因为同事对其代码显示出的专业性而感到自豪。

• 分享知识 submitter 可能使用了一种新技术或者算法，使 reviewer 受益。reviewer 也可能掌握某些知识，帮助改进这次提交。

对于Submitter和Reviewer的共同建议，开放的心态，良好的互动，Submitter给到 reviewer 更多的输入后，有益于问题的挖掘。

For Submitter 发起merge的提交者

1. 一次提交不要超过400行代码：

研究表明 ：在一次 CR 中，Reviewer 应一次至多处理200至400行代码(lines of code)。若超过400行，人的大脑无法有效的处理，发现缺陷的能力将下降。在实践中，使用60-90分钟来 review 一个200-400行的 patch，应该能发现70-90%的缺陷。即如果这个 patch 里面存在10个 bug，那么在 CR 阶段应该能发现7至9个。

2.做自己的第一个 reviewer。自我Review有以下几个注意事项：

• 端正心态，reviewer 是帮你发现问题的人，而不是阻塞你提交的人

• 认真对待 description，降低Reviewer的理解成本

• 一次提交只解决一个问题，降低review的复杂度

• 如果需要做重大修改，写找 reviewer 对齐大致的修改范围，再开始写代码，避免越行越远

For Reviewer code review的审查者

1.控制 review 速度

当 Reviewer 以超过500行/小时的速度 review 代码时，缺陷的发现率会有显著的下降。建议 Reviewer 控制好自己的速度，保障好 review 质量。建议一次 review 的时间不要超过一小时，当任务多时建议提高 review 的频率，避免持续过长时间。

2.Review 的重心

我们不可避免的需要 review 一些较大的 patch， Review的顺序：接口 >  测试 > 实现 ，reviewer 可以假设自己是该代码的使用方，该接口的定义及行为是否符合自己的预期？如果没有时间，至少也应该看一遍接口定义， 测试代码的质量与实现的质量同等重要，不可敷衍 ，理解提交者想通过测试测哪些东西比理解测试代码的含义更重要。

3. review Tips

• reviewer 应该尽量合理的安排自己的时间，不让自己成为 blocker，推荐每天在开始自己的工作前先 review 别人提交的代码。

• 给建议，更要给原因，帮助提交者进步

• 如果看到写得好的代码，不要吝啬赞赏的语句，提交者真的会很受鼓舞

• 对于看不明白的地方一定要提出问题，而不是轻易放过

• 不要花过多力气去理解难以理解的代码，如果一眼看不明白，第二眼还看不明白，说明这块代码需要改，很大可能过一段时间提交者也会看不明白

• 如果 patch 太大，应建议提交者分拆

• 慎重审查 .h 以及协议的修改

• 没有测试覆盖的代码没必要去看