为什么代码评审应该是快速的?
我们优化的是开发团队共同生产产品的速度，而不是单个开发人员编写代码的速度。个人发展的速度很重要，只是没有整个团队的速度重要。
当代码评审缓慢时，会发生以下几种情况:
- 整个团队的速度降低了。是的，那些对评审没有快速反应的人，可以完成其他的工作。但是，由于每个CL都要等待评审和重新评审，团队其他成员的新特性和bug修复会延迟几天、几周或几个月。
- 开发人员开始抗议代码审查过程。如果评审员每隔几天才回复一次，但每次都要求对CL进行重大修改，这对开发人员来说是很困难的。通常情况下，这表现为对评审员的“严格”的抱怨。如果评审员要求进行同样的重大更改(这些更改确实改善了代码的健康状况)，但是每次开发人员进行更新时都能快速做出响应，那么抱怨就会消失。对代码评审过程的大多数抱怨实际上是通过加快过程来解决的。
- 代码健康状况可能会受到影响。当评审缓慢时，就会增加压力而允许开发人员提交不太好的CLs。缓慢的评审还会阻碍代码清理、重构和对现有CLs的进一步改进。
代码评审应该多快?
如果你没有在执行一个正在关注的任务中，当有Code Reivew请求后应该在很短时间内进行Code Reivew。
一个工作日是响应代码评审请求(即第二天早上的第一件事)所需要的最长时间。
遵循这些指导原则意味着一个典型的CL应该在一天之内(如果需要的话)进行多轮评审。
速度 vs. 中断
有一段时间，个人的速度比团队的速度更重要。如果你正在集中精力做一项任务，比如写代码，不要打断自己去代码评审。研究表明，在中断开发之后，开发人员可能需要很长时间才能恢复到正常的开发流程。因此，对团队来说，在编写代码时打断自己的工作实际上比让另一个开发人员等待代码评审的时间更昂贵。
相反，在你的工作中等待一个断点，然后你才回应一个审查的请求。这可能是当你当前的编码任务完成后，午饭后，从会议回来，从茶水间回来，等等
快速的响应
当我们讨论代码评审的速度时，我们关心的是响应时间，而不是CL完成整个评审并提交所需的时间。理想情况下，整个过程也应该是快速的，但个人快速响应比整个过程快速发生更重要。
即使有时需要很长时间才能完成整个评审过程，在整个过程中得到评审员的快速响应可以极大地减轻开发人员对“缓慢”的代码评审感到的挫败感。
当需要你对一个CL进行Review时，你实在太忙了。你仍然可以发送一个快速反应,让开发人员知道什么时候可以开始Review,或建议其他可以更快地响应的评审员,或者提供一些最初的广泛评论。(注意:这并不意味着您应该中断编码，即使是为了发送这样的响应—在您工作中的一个合理的断点发送响应。)
重要的是评审员要花足够的时间在评审上，以确保他们的“LGTM”(looks good to me:看起来不错)是指“这段代码符合我们的标准”。然而，个人的反应仍然应该是快速的。
跨时区Review
处理时区差异时，试着在作者还在办公室的时候联系他。如果他们已经回家了，那么在他们第二天回到办公室之前，确保你的Review已经完成。
LGTM的评论
为了加快代码审查的速度，在某些情况下，审查员应该给予LGTM/通过，即使他们在CL上留下了未解决的注释。这是在以下情况下完成的:
- 评审员确信开发人员将适当地处理评审员的所有剩余评论。
- 其余的变更是次要的，不必由开发人员完成。
如果不清楚的话，评审员应该指明他们想要的选项。
当开发人员和评审员在不同的时区时，LGTM的评论尤其值得考虑，否则开发人员可能要等一整天才能得到“LGTM，通过”。
过大的CL
如果有人提交给你一个过大的CL，你无法确定有时间去review。你一般要求开发者将该CL拆分成几个小的CLs，而不是一个必须一次全部审查的巨大CL。这通常是可行的，并且对评审员非常有帮助，即使它需要开发人员做额外的工作。
如果一个CL不能分解成更小的CL，并且您没有时间快速地检查整个CL，那么至少要对CL的总体设计写一些注释，并将其发送给开发人员进行改进。作为审查人员，您的目标之一应该是始终解除对开发人员的阻塞，或使他们能够迅速采取某种进一步的行动，而不牺牲代码的健康状况。
随着时间的推移，代码评审会得到改进
如果您遵循这些指导原则，并且对代码评审非常严格，那么您应该会发现，随着时间的推移，整个代码评审过程会变得越来越快。开发人员了解健康的代码需要什么，并从一开始就向您发送很棒的CLs，这需要的审查时间越来越少。评审员要学会快速响应，不要在评审过程中增加不必要的延迟。但是不要为了提高速度而在Code Review标准或质量上妥协——从长远来看，这实际上不会使任何事情效率得到提升。
紧急情况
在一些紧急情况下，CLs必须非常快速地通过整个评审过程，并且质量方针将会放松。但是，请看看什么是紧急情况?用于描述哪些情况实际上属于紧急情况，哪些不属于紧急情况。
下一章：如何编写代码评论
