google code review 04

原文
https://google.github.io/eng-practices/review/reviewer/speed.html
Speed of Code Reviews (程式审核的速度)
Why Should Code Reviews Be Fast? (为什么审核速度要快)
在Google 我们优化开发团队共同生产产品的速度，而不是优化个人开发程式的速度。

个人的开发速度很重要，但它不如整个团队的开发速度(velocity of the entire team) 那般重要。

当程式审核很慢时，会发生以下几件事:

团队整体的速度下降
是的，没有快速回应的个人(individual) 的确完成自己所属的工作。但同时也表示，对于团队其他人来说重要的新功能与缺陷修复将会被延迟数天、数周甚至数月，只因为它们正在等待审核与再审核。

开发人员开始抗议程式审查流程
若审核者每隔几天才回应一次，但每次都要求对CL 进行重大更改的话，那么开发人员可能会感到非常沮丧与觉得困难，而这通常会演变成对评论者的「严格」程度的抱怨。如果审核者请求相同的实质性更改(且确实可以改善程式品质状况)，但在每次开发人员提交新的改动时都能快速反应的话，这些抱怨往往会消失。

大多数关于程式审查过程的抱怨，往往可以通过加快流程来解决。

程式品质会受到影响
当审核评论很慢时，会造成开发者提交不完全尽如人意的CL 的压力越来越大[1]。评论的越慢也会阻止他人进行程式清理(cleanups)、重构(refactorings)、甚至是对现有CL 的进一步改进。

[1] 还记得前面所说的吗? 没有完美的程式只有最佳的程式!
How Fast Should Code Reviews Be? (那程式审核应该要多快)
如果你并没有处于需要专注工作(focused task) 中间时，那么你应该在CL 被提交后尽快进行审查。

回应程式审查最长的极限是一个工作日是(意即隔天早上的第一件事)

若遵循以上指南，意味着一般的CL 应该在一天内得到多轮审核(如果必要的话)。

Speed vs. Interruption (速度vs. 中断)
但有时候个人的速度优先度会胜过团队速度。

如果你处于需要专注工作的中间时(比方说写程式)，不要中断自己去做程式审查

研究证实，若开发者在被打断后会需要很长时间才能恢复到原本顺畅的开发流程。因此，开发程式时打断自己实际上会比让另一位开发者等待审查来得更加昂貴。

取而代之的是，我们可以在投入到处理他人给的审核评论之前，找个适当的时机点来进行程式审核。这有可能是当你的当前开发任务完成后、午餐、刚从会议脱身或从微型厨房回来等等。

Fast Responses (快速回应)
当我们谈论程式审查的速度时，我们关注的是回应时间，而非CL 需要多长时间才能完成整个审核过程并提交。在理想情况下，整个过程应该是快速的。

总的来说个人回应评论的速度，比起让整个审核过程快速结束来得更为重要。

即使有时需要很长时间才能完成整个审核流程，但若在整个过程中能快速获得来自审核者的回应，这将会大大减轻开发人员对于緩慢的程式審核的挫败感。

如果真的忙到难以抽身而无法对CL进行全面审核时，你依然可以快速的回应让开发者知道你什么时候会开始审核、建议其他能够更快回覆的审核人员，又或者提供一些初步的广泛评论。(注意:这并不意味着你应该中断开发去发送这样的回应-请找到适当的中断点(break point)去做。)

很重要的是，审核人员要花足够的时间来进行审核，

确保他们给出的「LGTM」意味着「此程式符合我们的标准」。

尽管如此，理想的个人的回应速度还是越快越好。

Cross-Time-Zone Reviews (跨时区审核)
在面对时区不同的问题时，尝试在他们还在办公室时回覆作者。如果他们已经回家了，那么请确保在他们第二天回到办公室前完成审核。

LGTM With Comments (LGTM 评论)
为加快审查速度，在某些情况下审阅者可以给予LGTM 或Approval，即便CL 上仍有未解决的评论。类似情况会发生在:

审核者确信开发人员会适当地处理所有剩余的评论
剩余的评论是微不足道[1] 的或它们不需由开发者来处理
审核者必须清楚指明他们是指上面哪种情况[2]。

LGTM 评论对双方处于不同的时区时尤其值得考虑，否则开发人员会等待一整天才得到“LGTM，Approval”。

[1] nitpick
[2] 要说明是因为nitpick 不用立刻解决或是留待其他CL 来处理
do it later
改动本身带来的效益超过因修改导致延迟合并时，不妨告知对方我们用另个PR 来处理

Large CLs (大型改动)
如果有人要求审查时，但由于改动过于庞大导致你难以确定何时才有时间查看它时，你通常该做的是要求开发人员将CL拆解成多个较小的CL，而不是一次审查巨大的CL。这种事是可能发生的，而且对于审核人员非常有帮助，即便它需要开发人员付出额外心力来处理。

如果CL 無法分解为较小的CL，且你没有足够时间快速查看整个内容时，那么至少对它的整体设计写些评论，并发送回开发人员以便进行改进。身为审核者，你的目标之一是在不牺牲程式品质的状况下，避免阻档(unblock)开发人员继续前进，或让他们能够快速采取其他更进一步的动作。

Code Review Improvements Over Time (程式审查的能力会随着时间进步)
如果你遵循这些准则，并且对于审查非常严格的话，你会发现整个程式审核流程会随着时间的推移而变得越来越快。因为开发者学到什么是一个具有品质的程式该具备的内容，并于开头就提交一个很棒的CL，而这正恰好只需要越来越少的审核时间。而审核者则学会快速回应，而非在审核过程中加入不必要的延迟。

但不要为提高想象中的速度(imagined improvement in velocity)，

而对程式审核标准或品质做出妥协。

毕竟从长远来看它实际上并不会让任何事情发生得更快。

Emergencies (紧急状况)
在某些紧急情况下，CL会希望放宽审查标准以求迅速地通过整个审查过程。但请看文件「什么样的紧急情况?」来知道哪些情况实际上属于紧急情况，而哪些不符合。