====================
== Hi, I'm Vimiix ==
====================
Get hands dirty.

如何做code review

code review notes project

为什么要做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, 特此留存学习。