Google 是如何做 Code Review 的？| 原力计划( 四 ) _Google

代码有适当的单元测试。

测试逻辑设计良好。

开发者使用了清晰明了的命名。

注释清晰明了实用，通常解释清楚了为什么这么做，而不是做了啥。

代码又相应完善的文档。

代码风格符合规范。

确保你review了要求你看的每一行代码，确保你正在提升代码质量，并且为开发者做的提升点赞。
Code Review步骤
概要
现在你知道了要从CL中得到什么，那能在众多文件中完成评审的方法是什么？

这条改动是否生效？这次变更是不是描述清晰?
首先阅读CL最重要的一部分，整体上是否设计良好？
按照合适的顺序阅读剩下的变更。

第一步: 综观这个改动
阅读CL描述并且明白CL大体内容。这些修改是否有意义？首先如果这个修改不应该有，请立刻说明为什么这些修改不应该有。当你因为这个拒绝了这次改动提交时，告诉开发人员该怎么去做是非常好的。
例如，您可能会说：“看起来您为此做了一些出色的工作，谢谢！但是，我们实际上正着手删除FooWidget系统，您正在此处进行修改，因此我们不想进行任何新的修改现在。所以，您可以重构我们的新BarWidget类吗？"
请注意，审阅者不仅拒绝了当前的CL并提供了替代建议，但他们礼貌地做到了。这种礼貌是重要，因为我们想表明我们甚至在开发人员之间也相互尊重，尤其是当我们意见不同时。
如果您得到的多个CL并且您不想进行的更改，您应该考虑重新设计团队的开发流程或发布的外部贡献者的流程，以便在CL完成之前进行更多的交流。最好在做大量工作之前告诉人们“不必做” ，因为现在要将其丢弃或彻底重写。
第二步: 检查CL的主要部分
查找属于此CL的“主要”部分的文件。通常来说一个CL最重要的部分是它逻辑修改数最多的那个文件。这样有助于了解相关的CL ，通常来说会加快code review 。如果CL太大，您无法确定哪些部分是主要部分，请开发人员告诉你应该首先看什么，或要求他们将CL拆分为多个CL 。
如果您发现CL的这一部分存在一些主要的设计问题，则即使您现在没有时间审查CL的其余部分，也应立即写下这些评注。实际上，检查其余的CL可能会浪费时间，因为如果设计问题足够严重，那么许多其他正在检查的代码将消失并且无论如何都不会发生。
立即写下这些主要设计评注非常重要有两个主要原因：

开发人员通常会发送给审核者一个CL ，然后在等待审核时立即基于该CL进行新工作。如果您正在审查的CL中存在重大设计问题，那么他们也将不得不重新设计其以后的CL 。你能在他们做太多无用功之前制止他们。
重要的设计变更比小的变更需要更长的时间。开发人员几乎都有截止日期；为了在截止日期之前完成工作，并在代码库中保留高质量的代码，开发人员需要尽快开始CL的所有主要的重做。

第三步:依序阅读CL的其余部分
确认CL整体上没有大的设计问题后，请尝试找出逻辑顺序来浏览文件，同时还要确保不要错过对任何文件的审查。通常，在浏览了主要文件之后，按照代码审查工具向您展示它们的顺序浏览每个文件是最简单的。有时在阅读主要代码之前先阅读测试代码也是有帮助的，因为这样您就可以知道更改应该做什么。
Code Review的速度
为什么Code Review应该快？
在谷歌内部，我们在持续优化团队开发新产品的速度，而不是优化单个开发人员编写代码的速度。个人开发的速度固然重要，但它没有团队整体的速度那么重要。
如果Code Review速度慢了，可能会发生以下这些事：