什么是代码 review

代码 review (以下简称 review) 就是在你完成一个开发任务后，让团队其它成员对你本次修改过的代码进行检查，这么做的主要目的是找出代码中可能存在的问题。

review 除了能提前发现代码中的问题以外，还会带来其它的好处。

代码 review 的好处

• 提高代码质量。

• 团队知识共享。负责 review 的同学也需要对需求背景比较清楚，这就可以让多一个人知道这部分业务逻辑。

• 起到传帮带的作用。负责 review 的一般是对项目比较了解的老员工，在这个过程中可以部分起到老人带新人的作用。

我们可以从数据上来直观感受一下 review 给我们带来的帮助。下面是我所在团队的 review 统计数据：

我们团队在开始做 review 以后，1 年多的时间里共做了约 3000 次 review, 累计发现了约 2000 个问题。这个数量还是挺可观的，等于是把 2000 个潜在问题消灭在了测试之前，这大大降低了测试的工作量。而且其中一些问题如果没有测出来，就会流入生产。假设这些问题中有 1% 流入到生产，那就是 20 次生产事故了。从这个数据上可以看出， review 可以有效提高代码质量，从而对保障系统稳定性提供了非常大的帮助。

也正是因为有了 review 的保障，我们的团队只需要 1 个测试工程师就可以支持 8 个程序员的测试工作，且很少出现线上问题。

完整的代码 review 有哪些步骤

一个较完整的 review 包括以下步骤：

• 签入代码后提交合并请求。github 叫 pull reqeust (简称PR), gitlab 叫 merge request (简称MR)。

• 指派给帮你 review 的同学，如果配置了自动分配则不用指定，会由系统自动按策略分配。

• 审查者对你的代码进行查看，发现问题时，添加一条评论描述问题。

• 你对审查者的评论进行处理，修复代码并回复解决情况。

• 审查者再次查看修改后的代码，确认每一处都得到正确修复后，将该合并请求标记为通过。

• 将代码合并到目标分支。

上面这些步骤，可以有很多变化。比如审查代码时，有的团队是坐在一起由开发同学先进行讲解后，2个人再一起查看代码，有问题随时沟通。有的团队会要求代码必须有2个审查者同意后，才可以合并。

每个团队可以灵活安排 review 的各个步骤，找到适合自己的方式。

小团队要不要做代码 review

在大团队中，代码 review 是必须做的，不然每天上百人提交代码，不做 review 的话，早就乱成一团了。

小团队人少事多，虽然想做 review，但因为这个事情属于重要但不紧急的类型，容易被搁置。

但 “出来混，早晚要还的”, 忽视 review 的后果早晚会显现，明显的表象有：

• 有人离职后他写的代码没人知道是什么意思。

• 经常有问题流入生产，造成各种事故。导致数据错误，客户投诉，紧急修复问题，还要修复生产数据，频频救火。

• 代码越来越乱，有些代码没人敢碰，一碰就出问题。实在要改，就加一个 if 判断，把逻辑引到另一个方法里重新写。这样代码就更乱，恶性循环。

大团队也是从小团队开始的，不做代码 review 永远成为不了大团队。面对历史“债务”，小团队要鼓起勇气，把 review 做起来。代码中的历史问题，可以先暂时搁置。放下包袱，轻装上阵。做代码 review 最合适的时机就是在项目开始时和现在。

小团队如何做代码 Review

小团队在做 review 时，有些流程可以简化，这样开展 review 的阻力会更小，效率会更高。可以参考下面的这些方式：

• 人员固定搭配

  • 先确定团队中可以做 review 的同学，比如 A 和 B。
  • A 负责检查 x,y,z 三位同学的代码，B 负责检查 i,j,k 三位同学的代码。
  • A 和 B 的代码互相检查。

  这样固定的搭配可以让大家尽快熟悉审查者对代码的要求，磨合沟通方式，形成默契。

• 避免 2 个人坐在一起看代码

  坐在一起看代码的话，大部分时间只有1个人在工作，另一个人会没事干，容易尴尬，影响工作状态，也降低了工作效率。而且好的代码应该是不需要人解释就能看懂的。可以在代码逻辑确实复杂需要面对面沟通时，再呼唤开发同学过来当面沟通。小团队一般都在一个办公室，需要充分发挥小团队沟通便捷的优势。

• 问题一定要记录

  在发现代码中的问题后，一定要在问题代码的位置添加评论，留下记录。这样一是方便开发同学统一处理，并在处理后标记修复状态。二是重新进行复核时才不会遗漏。

• 一个人审查通过即可

  大团队往往需要代码被 2 个人 review 并批准后才允许代码合并，但小团队具备 review 资历的往往只有 2,3 个人。如果每次要 2 个人 review 的话，工作量过大，也增加了代码合并发布的周期，也就是增加了成本。小团队还是要在成本上精打细算的。

• 确定代码 review 的原则，让团队形成共识

  在首次启动 review 前，有必要先和团队沟通一下 review 时大家遵循的原则，将非常有助于后续的工作开展。建议考虑下面这些原则:

  • 提交代码前，开发同学需先自行浏览一遍自己修改过的代码，保证代码清晰易懂，复杂的逻辑中添加了必要的注释。

  • 每次尽量只提交一个单一的功能或几个小优化，不要多个功能同时提交。这也符合敏捷开发小步快跑，快速迭代的思路。

  • 审查者在 review 代码前需要先了解一下这个需求的背景情况，这有助于更好的理解代码是否符合需求场景。但不需要特别关注需求细节。review 的目的是提高代码质量，不是检查代码是否严格按需求实现了，这是开发同学和测试同学的职责。

  • 避免争论。完成一个算法可以有多种方式，在 review 代码时不用为了一个算法的实现方式进行过多争论。主要聚焦在代码是否有 bug，是否有坑，是否易懂上。 review 代码的人都是有一定资历的，如果审查者和开发者意见不一致，谁也说服不了谁，那就按审查者的要求进行修改。开发者可以在改了以后，将此处提出来在团队中讨论。

Review 示例

下面两张图片展示了一个实际的 review 例子。

• 在代码中添加评论时的操作方式：

• 代码修改后复核时的显示效果

有时代码比较复杂，修改前后差异较多，用 gitlab 或 github 网页方式 review 会不太容易。此时，也可以考虑用 IDEA 自带的代码比较工具来进行 review，发现问题后还是在网页中对应位置填写。这种方式略微有些不便，但这样的情况不会太多。

总结

检查代码就像是一个老师在改一篇作文，找出文章中的错别字、病句等，目标是让文章语句通顺，逻辑合理。遇到写得优秀的段落也可以狠狠的夸一下，以资鼓励。当在 review 中帮助开发同学找出了问题，并提出修改建议，开发同学也会觉得高兴，因为他在这个过程中得到了提高。

通过代码 review，可以非常有效的提高代码质量，让开发同学们逐渐远离垃圾代码，让工作更有愉悦感，创造出更好的团队氛围。