google code review系列4 - ​code review的速度

接上篇：google code review系列3 -  浏览审查中的change list。本篇主要讲述快速响应对code review整个过程的重要性，这里说的是快速响应，而不是整个code review过程加速草草了事。快速响应是一种好的体验。当然快速响应的前提不是让你打断现有的，需要专注的手头任务（例如：编码）；以及大的change list我们应该如何处理，跨时区协作如何更加高效的review，紧急情况如何处理等等问题。

翻译：

https://google.github.io/eng-practices/review/reviewer/standard.html

Code Review名词解释

整个Code Review分成如下五个部分，本节主要讲述Google在code review中寻找什么？

目录

• code review的标准

• 在code review中寻找什么

• 浏览审查中的CL

• code review的速度

• 如何编写code review注释

• 处理code review中的pushback

在Google主要优化开发团队共同开发产品的速度，而不是优化个人开发的速度。当然，不是个人的开发速度不重要，而是和整个团队的开发速度相比，团队开发更重要。

当code review很慢时，会发生以下几件事：

• 整个团队的速度会降低，有些人去做其他工作而不去快速响应review的要求。从而导致整个团队的新功能和bug修复可能会因为没有人做code review被延迟几天、几周甚至几个月。

• 开发人员开始抗议code review过程。倘若reviewer每隔几天才回应一次，但每次都要求对CL进行重大更改的话，那么开发人员可能会感到非常沮丧与觉得困难，通常这种情况下，会抱怨reviewer的“严格”的程度。如果reviewer请求相同的实质性更改(且确实可以改善代码质量状况)，但在每次开发人员提交新的改动时都能快速反应的话，这些抱怨往往会消失。大多数关于code review的抱怨，往往可以通过加快流程来解决。

• 代码质量会受到影响。当review很慢时，会造成开发者提交不完全尽如人意的CL 的压力越来越大。评论的越慢也会阻止他人进行代码清理、重构、甚至是对现有CL 的进一步改进。

代码审查应该有多快？

如果你现在不是处在一个需要高度专注的任务当中，code review应该越快越好。

一个工作日是响应代码审阅请求所需的最长时间（即第二天早上的第一件事）。

遵循这些指南意味着一个典型的CL应该在一天内得到多轮审核（如果需要）。

速度 vs 中断

只有一种情况下，个人的速度要胜过团队速度。如果您正在处理诸如编写代码之类的重要工作，请不要打断自己的工作去做Code Review，研究表明，开发人员在被中断后，可能需要很长时间才能恢复到专注的状态。因此，对于团队来说，在编写代码时打断自己，实际上比让另一个开发人员等待一段时间进行代码审核更得不偿失。

所以，建议你在工作断点的时候回应code review，比如写完代码后、午饭后、会议结束后、从茶水间回来等等。

快速响应

当我们谈论code review的速度时，我们最关注的是：响应时间，另一方面是指整个review从提交到通过的时间。理想情况下，整个过程应该非常快的，但是每个reviewer个体的快速响应，比迅速完成整个过程更为重要。

即使有时需要很长时间才能完成整个code review流程，reviewer在整个过程中的快速响应也可以大大缓解开发人员因为code review“慢”而产生的沮丧情绪。

如果你太忙不能全身心投入到code review中，你也应该让开发者知道你什么时候会去review，或者建议其他reviewer快速响应，再或者提供一些初步的建议。（注意：这不是建议你中断自己的工作，而是在工作间隙合理响应）

重要的是，评审人员要花足够的时间进行评审，确保他们的“LGTM”表示“该代码符合我们的标准”然而，理想情况下，每个回应应当保证足够快速。

跨时区Code Review

当遇到跨时区的code review时，尽量在作者回家前回复。如果他们已经回家了，尽量在他们第二天来公司前完成code review。

LGTM和注释

为了加快代码审查的速度，在某些情况下，审查员应该给予LGTM/批准，即使他们也在CL上留下未解决的评论。这是在以下情况下完成的：

为了加快code review的速度，有些情况下也应该让code review提前通过，给予LGTM，即便有些评论没有被解决，比如：

• reviewer信任开发者能适当解决所有评审者的建议。

• 其余的改动很小，不必由开发人员完成。

除非另有明确说明，reviewer应指明他们打算使用这些选项中的哪一个。

当开发人员和reviewer处于不同的时区时，带有LGTM的注释尤其值得考虑，否则开发人员会等一整天才得到“LGTM，批准”

当开发者和reviewer在不同时区时，应当着重考虑下通过code review，否则开发者还得等一天。

大的CL

如果有人给你发了一个非常大的代码评审，你不确定什么时候你能有时间来评审它，你的典型反应应该是要求开发人员将CL拆分为几个较小的、彼此构建的CL，而不是一次性review一个巨大的CL。即使这需要开发人员进行额外的工作，但是对reviewer是非常有帮助的。

如果一个CL不能被分解成更小的CL，你也没有时间快速完整的review整个代码，那么至少写一些关于CL整体设计的评论，并将其发送回开发人员进行改进。作为一名reviewer，您的目标之一是在不牺牲代码质量的前提下，应该始终在不阻碍开发者的进程尽可能让他们向前推进。

持续提升code review

如果您遵循这些指导原则，并且严格要求代码审查，那么您应该会发现，随着时间的推移，整个代码审查过程往往会越来越快。开发人员了解优质代码所需的内容，并从一开始就向您发送出色的CLs，需要的审阅时间越来越少。reviewer学会快速响应，不会在code review过程中增加不必要的延迟。但是，不要在代码审查标准或质量上妥协，以实现想象中的速度改进。从长远来看，这并不会提升速度。

紧急情况

有一些紧急情况，CLs需要快速走完这个code review流程，这时候在质量上的把控可以稍微放松一些。

往期阅读

google code review系列3 -  浏览审查中的change list

google code review系列2 - 在code review中寻找什么?

google code review系列1 - code review的标准

快乐程序员、读书狂魔、爱撸代码、开源项目、硬核互联网技术分享

欢迎一键三连：点赞，转发，在看

关注我：西西球球 (xixiqiuqiu8)，谢谢！