高效code review指南

大多数程序员都知道而且相信code review（代码审查）的重要性，但并必定都能很好的执行这一过程，作好code review也须要遵循必定的原则、流程和规范。

咱们团队的code review实践也并非一路顺风，两年前刚开始的时候，形式很粗糙，就是一堆人对着代码品头论足。致使的结果要么是陷入争论，reviewer说这里写得很差，author（本文中用author这个单词来指代被评审者）辩论说其实没问题；要么只关注一些无伤大雅的细节，发现不了更为严重的问题（好比设计的问题）。试了几回，逐渐感受流于形式，后来也就不了了之了。

若是发现一个广为推荐的工具不太好用，那么除了怀疑这个工具适不适合以外，更应该想一想使用姿式是否正确。因而花了些实践来学习code review的知识，并与其余团队交流，在实践中逐渐造成了一套行之有效的方法。本文记录对code review的一些认识与思考

本文地址：http://www.javashuo.com/article/p-vvvitypt-ku.html

code review的出发点

咱们从一个需求开发的完整生命周期来看，大约会包含如下过程：

• 需求分析，考虑人员状况、功能预期上线时间、技术难度等诸多因素，与PM讨论合理调整需求，分配资源；
• 总体设计，对设计进行review；
• 代码开发；
• 开发自我review，观察、思考与总体设计的出入，保证代码遵循团队规范（至少得经过静态代码检查）；
• 添加相应的单元测试，并保证已有的单元测试不受影响；
• code review，请相关同事对代码进行review，修复review中发现的问题；
• 提交代码给QA测试，QA会进行功能测试、集成测试、性能测试、压力测试等；
• 修复测试发现的bug后功能上限。

从上属流程能够看出，代码写完了会有专业的测试同事来进行全方位的测试，那么为何还要code review呢？其次，合格的程序员理论上都会review本身的代码，还有没有必要请同事来review呢？

一个bug，可能在代码review的时候被发现；也可能在测试的时候被发现；最坏的状况下，被用户发现，固然，此时极可能给用户、产品带来损失。越早发现问题，受影响的人员越少，修复成本就越小。想一想前几天淘宝的弹窗bug，若是能经过review发现，能拯救多少人的绩效。

开发人员有时也有一个误区，以为本身完成“代码开发”这一步就万事大吉了，测试的事情就应交给QA去执行。但不少时候，QA更多从功能角度去验证代码，有时候黑箱测试也很难覆盖到所有状况，好比异常、安全性问题、版本依赖。何况如今不少公司都逐渐去掉专门的Test，开发得本身测试，但思惟定势致使很难发现本身的问题，对本身代码的review也是如此。另外，知道本身的代码也被人“拿着放大镜仔细观察”，天然写代码的时候也认真一些。

另外，从上述流程能够看出：

• 其实应该有两次定位不一样的review：对总体设计的review，主要目的是从大方向上保证设计确实能知足需求；其次是code review，保证代码实现符合设计约束，且编码没有明显的缺陷。
• 用来code review的代码，应该既知足团队代码规范，又基本保证功能的正确。

在咱们的实践中，对于复杂的系统，会要求现先设计review。而对于简单的、或者开发比较有把握的功能，则是将设计review与代码review合并。本文讨论的code review其实就是后者：既关注设计，又关注核心代码。

code review的目标和原则

code review的首要目标是：找出代码中的缺陷，保证代码质量。其次，经过review也能相互学习，提升团队总体水平，并且特别有利于新人快速融入团队，保持与团队风格一致。最后，保证每一个核心功能有多个同事了解，下降风险。

从其核心目标咱们就能够看出code review的第一原则：对事不对人。这一点须要reviewer、author达成共识。code review不是批斗大会，reviewer、author并无高低之分。

对于reviewer而言，参与的首要目的在于协助发现问题，所以

• 尽可能质疑本身而不是对方

我没有看懂这段代码的逻辑
而不是
你这段代码有问题吧

• 指出代码有问题而不是指责人

这段代码是否是可能出问题
而不是
你又写出bug来了

对于author，应当把review看成一次学习成长的机会 -- 毕竟平时又有谁来给你免费建议和指导呢？所以，不要一开始就是防护的姿态，即便reviewer有所误解也不用脸红脖子粗的去争论。

要真正让author放松，达到和谐review的效果，我的以为还要注意如下几点：

• review不该该与任何KPI挂钩，review发现的缺陷不该归入绩效考核。
• 团队Leader应该少发言（不然就会变成Leader说啥就是啥），甚至要少参加无关的review，毕竟任何人都不但愿给Leader留下本身很菜的印象。
• 得须要有人充当仲裁者的角色，化解reviewer与author的冲突。并且，必要的时候维护author。

code review步骤以及注意事项

code review 并不简单是一堆人一块儿看代码，要让code review的效果最大化，整个流程是须要认真组织的：

review前

• author得保证代码质量：代码知足团队规范且基本测试经过
• author至少提早一天通知参与review会议的同事，提供必要的需求、设计文档
• reviewer简单了解需求、设计、代码实现

这里须要注意的是，与会人员越少越好，无关的同事最好不要参加review。若是与会者对相关的功能不感兴趣，那么就存粹是在浪费时间，这也是不少人不喜欢code review的缘由。

review中

review的过程大约是：

• author大体讲解需求和总体设计，而后是核心代码
• reviewer提出问题，author确认是不是问题
• 对发现的问题进行记录，分类处理

review中须要注意：

• 控制review的时间，codereview自己就是一个高强度的活动，时间过长你们都很疲惫，效率也会降低，经验值一个小时左右比较合适。
• 控制review的代码量，须要你们仔细阅读的代码最好也控制在200 - 400逻辑行（这个数值也是the art of unix programming中对模块代码量的建议值）
• 须要有支主持人控场，把控时间和进度。和任何高效会议同样，应该避免发散，尽可能只发现问题，并不深刻讨论如何解决问题。
• 记录发现的问题，以及相应的解决方案：
  • 已有明确修复方案只待执行？
  • 仍是须要修复但解决方法尚须要进一步讨论？
  • 仍是在下一次迭代时再修复？

reviewer内容依次是：

• 是否知足功能需求，有没有多作，有没有少作，有没有潜在的bug，
• 是否知足非功能需求。性能（高频调用的函数、核心算法）？可用性（异常处理是否完善）？可读性？
• 代码质量、规范

上面也提到，code review自己是个高强度的活动，所以容易漏掉一些关键点点，所以不妨作一个review list，对照这个list去考察代码。list保证了code review的质量下限，且不影响与会者发挥主观能动性，发现其余问题。

此外，也须要避免在没有明确规范的问题下过多争执。达到一样的效果，A方法能够，B方法也能够，若是团队没有约束用哪一种方法，那么就不要在code review的时候讨论。

review后

review会议结束并不意味这个review这个活动结束，由于还有待解决的问题，所以应该借助工具跟踪review发现的问题，指明问题的修复者、问题的验收人、问题的验收时间。当一次review所关联的全部问题都获得修复以后，review活动才算结束。

总结

如何才能code review有效且高效，总结如下几点：

• 会前充分准备，与会人员最少化
• 参考review list，发现问题但不发散去讨论解决问题
• 会后跟进问题修复

最重要的事，是经过几回组织良好的实践让你们看到code review确实是有价值的，有所收获才愿意持续付出。