接上篇: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),谢谢!