预防胜于治疗,研究表明高效的 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 以及协议的修改
-
没有测试覆盖的代码没必要去看
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)