如何做code review

为什么要做code review

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

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

从上属流程可以看出，代码写完了会有专业的测试同事来进行全方位的测试，那么为什么还要 code review 呢？其次，合格的程序员理论上都会 review 自己的代码，还有没有必要请同事来 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 确实是有价值的，有所收获才愿意持续付出。

本文摘自: https://www.cnblogs.com/xybaby/p/12601471.html, 特此留存学习。