代码评审的速度

为什么代码评审要快速进行？

在谷歌，我们对开发团队的整体交付速度（而不是针对个体开发人员写代码的速度）进行了优化。个体开发速度也很重要，但其重要性比不上整个团队的开发速度。

如果代码评审的速度很慢，就会发生以下这些事情：

· 团队的整体开发速度降低了。如果个体开发人员无法快速地对评审做出响应，可能是因为他们有其他事情要做。但是，如果每个CL都要等待一次又一次的评审，那么其他成员的新特性和bug修复就会被延迟，可能是几天、几周甚至是几个月。

· 开发人员开始对代码评审流程提出抗议。如果评审人员要隔几天才回复一次，但每次都要求对CL进行重大修改，开发人员可能会觉得很沮丧。通常，他们会抱怨评审人员太过严苛。如果评审人员能够快速提供反馈，抱怨就会消失，即使他们要求做出的修改是一样的。代码评审过程的大多数抱怨实际上可以通过加快评审速度来解决。

· 代码质量受影响。如果评审速度很慢，开发人员的压力也会随之增加，因为他们不能提交不甚完美的CL。缓慢的评审流程还会阻碍代码清理、重构和对现有CL做出进一步改进。

代码评审应该要多快？

如果你不是在集中精力完成手头的任务，那就应该在第一时间评审代码。

对代码评审做出响应最好不要超过一个工作日。

如果遵循这些原则，那么一个典型的CL在一天内（如果需要的话）可以进行多轮评审。

速度和中断

有一种情况，即如果你正在集中精力完成手头的任务，比如写代码，那就不要打断自己去做代码评审。研究表明，开发人员被中断之后可能需要很长时间才能恢复到之前的状态。因此，从团队整体上看，在写代码时打断自己比让另一个开发人员等待代码评审要付出更大的代价。

所以，对于这种情况，可以等到你手头工作可以停了再开始代码评审。可以是在完成手头的编码任务之后，午饭后，会议结束后，休息结束后等。

快速响应

我们所说代码评审速度指的是响应时间，而不是CL完成整个评审过程并提交到代码库所需的时间。理想情况下，整个评审过程也应该是很快的，但单次评审请求的响应速度比整个过程的响应速度更重要。

有时候可能需要很长时间才能完成整个评审过程，但在整个过程中评审人员的快速响应可以极大减轻开发人员对“慢”评审的沮丧感。

如果你太忙了，可以先向开发人员发送一个响应，让他们知道你什么时候可以开始评审，或者建议让其他可以更快做出响应的评审人员来评审代码，或者提供一些初步反馈。

最重要的是评审人员要花足够的时间进行评审，确保代码符合标准。但不管怎样，最好响应速度还是要快一些。