在很多知名团队，他们都优化了开发团队共同开发产品的速度，而不是优化单个开发者编写代码的速度。个人开发的速度很重要，它并不如整个团队的速度那么重要。
当代码审查很慢时，会发生以下几件事：
- 整个团队的速度降低了。是的，对审查没有快速响应的个人的确完成了其他工作。但是，对于团队其他人来说重要的新功能与缺陷修復将会被延迟数天、数周甚至数月，只因为每个 CL 正在等待审查和重新审查。
- 开发者开始抗议代码审查流程。如果审查者每隔几天只响应一次，但每次都要求对 CL 进行重大更改，那么开发者可能会变得沮丧。通常，开发者将表达对审查者过于“严格”的抱怨。如果审查者请求相同实质性更改（确实可以改善代码健康状况），但每次开发者进行更新时都会快速响应，则抱怨会逐渐消失。大多数关于代码审查流程的投诉实际上是通过加快流程来解决的。
- 代码健康状况可能会受到影响。如果审查速度很慢，则造成开发者提交不尽如人意的 CL 的压力会越来越大。审查太慢还会阻止代码清理、重构以及对现有 CL 的进一步改进。
Code Review 应该有多快？
如果你没有处于重点任务的中，那么你应该在收到代码审查后尽快开始。
一个工作日是应该响应代码审查请求所需的最长时间（即第二天早上的第一件事）。
遵循这些指导意味着典型的 CL 应该在一天内进行多轮审查（如果需要）。
速度 vs. 中断
有一种情况下个人速度胜过团队速度。如果你正处于重点任务中，例如编写代码，请不要打断自己进行代码审查。研究表明，开发人员在被打断后需要很长时间才能恢复到顺畅的开发流程中。因此，编写代码时打断自己实际上比让另一位开发人员等待代码审查的代价更加昂贵。
相反，在回复审查请求之前，请等待工作中断点。可能是当你的当前编码任务完成，午餐后，从会议返回，从厨房回来等等。
快速响应
当我们谈论代码审查的速度时，我们关注的是响应时间，而不是 CL 需要多长时间才能完成整个审查并提交。理想情况下，整个过程也应该是快速的，快速的个人响应比整个过程快速发生更为重要。
即使有时需要很久才能完成整个审查流程，但在整个过程中获得审查者的快速响应可以显着减轻开发人员对“慢速”代码审查感到的挫败感。
如果你太忙而无法对 CL 进行全面审查，你仍然可以发送快速回复，让开发人员知道你什么时候可以开始，或推荐其他能够更快回复的审查人员，或者提供一些大体的初步评论。 （注意：这并不意味着你应该中断编码，即使发送这样的响应，也要在工作中的合理断点处发出响应。）
重要的是，审查人员要花足够的时间进行审查，确信他们的“LGTM”意味着“此代码符合我们的标准。”但是，理想情况下，个人反应仍然应该很快。
跨时区审查
在处理时区差异时，尝试在他们还在办公室时回复作者。 如果他们已经下班回家了，那么请确保在第二天回到办公室之前完成审查。
带评论的 LGTM
为了加快代码审查，在某些情况下，即使他们也在 CL 上留下未解决的评论，审查者也应该给予 LGTM/Approval，这可以是以下任何一种情况：
- 审查者确信开发人员将适当地处理所有审查者的剩余评论。
- 其余的更改很小，不必由开发者完成。
如果不清楚的话，审查者应该指定他们想要哪些选项。
当开发者和审查者处于不同的时区时，带评论的 LGTM 尤其值得考虑，否则开发者将等待一整天才能获得 “LGTM，Approval”。
大型 CL
如果有人向你发送了代码审查太大，你不确定何时有时间查看，那么你应该要求开发者将 CL 拆分为几个较小的 CL 而不是一次审查的一个巨大的 CL。这通常可行，对审查者非常有帮助，即使需要开发人员的额外工作。
如果 CL 无法分解为较小的 CL，并且你没有时间快速查看整个内容，那么至少要对 CL 的整体设计写一些评论并将其发送回开发人员以进行改进。作为审查者，你的目标之一应该在不牺牲代码健康状况的前提下，始终减少开发者能够快速采取某种进一步的操作的阻力。
代码审查随时间推移而改进
如果你遵循这些准则，并且你对代码审查非常严格，那么你应该会发现整个代码审核流程会随着时间的推移而变得越来越快。开发者可以了解健康代码所需的内容，并向你发送从一开始就很棒的 CL，且需要的审查时间越来越短。审查者学会快速响应，而不是在审查过程中添加不必要的延迟。但是，从长远来看，不要为了提高想象中的代码审查速度，而在代码审查标准或质量方面妥协，实际上这样做对于长期来说不会有任何帮助。
紧急情况
还有一些紧急情况，CL 必须非常快速地通过整个审查流程，并且质量准则将放宽。请查看什么是紧急情况？ 中描述的哪些情况属于紧急情况，哪些情况不属于紧急情况。
