Google 是如何做 Code Review 的

2019 年 11 月 12 日
筆記

作者 | Michaela Greiler

翻译 | 漫慢忙

本文翻译自 Dr. Michaela Greiler 的 Code Reviews at Google are lightweight and fast，作者所在的团队调研了 Google 是如何做代码审查的，并做了相关的总结。原文附有大量链接资源，在此没有整理出来，相关链接可以查看原文获取。

Google 的代码审查在工程实践中起着重要作用，并且 Google 早期就已经开始采用。直到今天，代码审查仍用于保证代码库的整洁，一致，并确保没有人随意提交代码。Google 代码审查过程看上去与 Microsoft 的代码审查相似，不过仍有一些差别，让代码审查过程变得很轻。

本文展示了 Google 的代码审查的流程以及与 Microsoft 的代码审查的不同之处。尤其是展示了 Google 的 25,000 名工程师为何能比同等规模的其他公司更快地实施代码审查。

Google 的代码审查研究

Google 的研究员 Caitlin Sadowski 和其他人进行了一项研究，以了解 Google 的内部代码审查流程。这项研究与 Microsoft 的代码审查研究相似，因此可以比较两家公司的代码审查过程。

Google 的通用代码审查流程

Google 的通用代码审查与 Microsoft 的通用代码审查非常相似。让我们举一个例子，这回我们以 Mark 为假想员工。

准备要审查的代码

这一切都是在 Mark 对代码进行了一些更改并希望将这些代码更改合并到共享代码库开始的。与 Microsoft 相似，Google 借助工具来进行代码审查。因此，在 Mark 将他的代码更改发送出去进行审核之前，他使用该工具最后一次浏览了该代码。

Google 的内部代码检查工具 Critique 提供了一些对比功能，这些功能使 Mark 可以轻松发现错误并查看新版本代码中的更改。

在将代码发送出去进行审核之前，Mark 需要执行另一个操作：通过静态分析工具运行代码。因此，Mark 运行了 Tricorder（一种在 Google 广泛使用的工具），并检查了静态分析的结果。当他对自己的更改感到满意时，他会将更改发送给至少一位代码审阅者。

审阅人提供反馈

代码审阅者仔细查看代码并在发现问题或有疑问时留下评论。然后，Mark 通过更改代码或回复评论来解决每个评论。在 Mark 对所检查的代码进行了一些更改后，他将上载新版本供审阅者再次检查。如果审阅者感到满意了，她可以通过将其标记为 “LGTM(looks good to me)”来批准更改。为了能够将代码提交到共享代码库，至少需要一名审阅者批准该代码。

这个代码审查生命周期，看起来像是 Microsoft 的代码审查的副本。但是，接下来将向您展示一些巨大的差异。

公司范围内的审查政策

首先，Google 要求对每个代码更改进行审查。没有例外。

另一方面，在 Microsoft，代码审查以及审查的方式和内容由部门或团队自行决定。例如，某些团队会跳过代码审查中的细微变化。通常，公司范围内没有关于代码审查的统一政策。团队和部门决定需要多少代码审阅者，或者代码审查如何与测试和静态分析活动等等联系起来。

Google 的代码审查要求所有权和可读性

同样与微软不同的是，谷歌有一些公司层级的要求，代码审查者必须达到这些要求才能批准代码更改。这与 Google 强大的代码所有权有关。代码库的每个目录均由一组人员明确拥有。为了能够批准代码更改，至少一名审阅者必须是受审代码的所有者。这个人充当守门员的角色。仅当此人同意时，才能签入代码。

另一个严格的要求是，至少一个审查人员必须接受代码“可读性”的培训。这意味着该人必须已获得可读性认证。该认证表明他们已经证明自己知道代码的可读性和可维护性。

必须获得每种语言的可读性证明。这样的标准是确保代码规范和设计一致的好方法。

对审阅者的要求不只是资历或地位

尽管许多其他公司（包括Microsoft的多个部门）看重审阅者的资历、专业领域以及决策权的层次结构，但 Google 却更看重所有权和可读性认证。

这解决了一些常见的代码审查陷阱。要求高级开发人员批准代码很容易导致工作过载，进而造成瓶颈。

在另一方面，同样重要的是足够多的人有这样的可读性认证。否则，这会造成审核的瓶颈。众所周知，等待代码审查反馈是代码审查期间的主要陷阱之一。尽管要花很多精力来获得可读性证书，但显然比更改等级或资历更容易。

如何获得可读性认证

为了展示其对代码进行可读性审查的能力，Google 的开发人员进行了“对其代码审查实践的审查”。因此，开发人员将代码更改提交给可读性专家团队。这些人将检查代码。但是这种检查并不像普通的代码审查那样。可读性专家会仔细检查代码。此类审查的目的是指出每个小错误以及每个改进的潜力，尤其是在编码约定和编码样式方面。而且，诸如缩进或多余空间之类的挑剔问题也是此过程的一部分。如果您有兴趣，可以在这里1找到 Google 的各种语言的编码规范指南。

一旦专家们确信开发人员学会了并能够应用 Google 的编码风格和约定，他们就会颁发可读性认证。

批准代码需要什么

因此，要概括一下，要使您的代码在 Google 上获得批准，您至少需要一名代码审查人员对代码拥有所有权，并拥有所用语言的可读性认证。如果满足这两个条件，那么就可以了。

此外，在 Google 团队中，存在多个开发人员必须批准或对审阅者执行不同标准的地方。但是，一般规则是，一个开发人员的认可就足够了。

Google 的代码审查轻巧快捷

Google 明确希望其代码审查轻巧而快速。即使 Google 强制执行所有权和可读性标准以进行批准，但代码审核过程仍非常快（平均4个小时）。较小的更改将在 1 小时内就可以得到审查，较大的更改将在 5 小时内得到审查。其他公司报告的平均周转时间超过15小时。

那么，Google如何做到这一点？

好了，查看一下数据[2]，我们可以发现有两个重要因素：审查参与者的数量和变更规模。

只需一名审阅者可以加快代码审阅速度

该研究最有趣的发现之一是，超过 75％的代码审查只有一名审阅者。这很不寻常。研究表明，两位审阅人更能提供有价值的反馈。

在 Goggle 中，仅需要一名审阅者似乎是一个有意识的决定，为了速度而降低严格程度。只有这样，Google 才能实现快速的周转时间。跳过等待别人的需要，减少了很多复杂性。但这也损害了审查的严格性，该研究也提到了这一点。在质量方面的损失是多少是未知的。尽管如此，Google 似乎还是取得了不错的成果。

小步快跑对高质量的代码审查至关重要

这项研究的另一个关键见解是修改的规模。您能想象 90％的代码评审更改的文件少于 10 个吗？这确实让人映像深刻，也解释了为什么 Google 的代码审查速度如此之快。大多数更改还仅更改了约 24 行代码。与包括微软在内的其他公司的研究报告相比，这种变更的规模要小得多。

审查小的、一致的变更是一种行之有效的代码审查最佳实践。首先，它提高了查看速度。正如我们在对有价值的代码审查反馈的研究中所看到的那样，它还提高了代码审查反馈的价值。代码审查反馈的有效性随代码审查规模的增加而降低。Google 员工深知这一点，并经常提交少量代码更改。

代码审查是否有价值？

在分析 Microsoft 的代码审查实践和工具时，我经常思考在代码审查期间提供价值的真正含义。什么时候代码评审值得让一个团队在上面花费时间？

为了回答这个问题，我求助于开发人员，问他们为什么进行代码审查以及何时从中获得价值。

事实证明，代码审查肯定是能提供价值。即使某些代码审查不会导致任何更改也可以，但重要的是大多数代码审查实际上会对代码产生影响。否则，我们可以跳过它们，对吗？

因此，回到 Google 的研究中，我发现有趣的是，研究人员还假设，如果不采取任何措施，则可能会跳过代码审查。好消息是，Google 中 80％的代码审查确实要求开发人员采取行动。这清楚表明代码审查对代码库有积极影响。但是那剩余的 20％呢？浪费时间吗？

事情并不是那么简单。幸运的是，代码审查可带来广泛的好处。

Google 进行代码审查的动机和获得的收益

尽管代码审查通常与发现错误相关，但是一些关于代码审查的研究表明，进行代码审查的好处和动机远不止这些。此外，Google 员工都知道代码审查的好处是多方面的，尤其是遵循了代码审查最佳实践。在 Google 引入代码审查的员工的最初愿景是迫使开发人员编写其他开发人员可以理解的代码。

在这项研究中，Google 员工说明了进行代码审查的以下动机：

• 教育（指导，学习，知识传播）

• 保持规范（例如进行适当的测试，样式和设计的一致性）

• 守护（确保安全性，提供额外的安全网，以便单个开发人员不能提交任意代码）

• 事故预防（包括确保尽可能好地防止错误和缺陷，并确保源代码质量高）。

• 跟踪和跟踪决策（了解代码的演变以及发生更改的原因和方式）

动机因角色而异

在 Google 进行代码审查研究的另一个有趣发现是，进行代码审查的动机和期望取决于关系人的角色和职责。例如，经理对在代码库中创建一致的编码样式所带来的好处更感兴趣。另一方面，开发人员更关心发现缺陷或错误。

对于代码审查的原由，Google 员工和 Microsoft 工程师的理由是一致的，除了 Microsoft 员工不会将代码审查描述为“守护”的方式。例如，安全检查不是 Microsoft 常规代码审查过程的一部分。

Google 的代码审查工具

在 Google，借助工具可以完成代码审查。Google 主要使用两种代码审查系统。对于开源代码和与外部协作者共享的代码，如 Go、Chromium、Android，Google 员工使用 Gerrit 代码审查工具。Gerrit 是与 Git 集成的开源代码审查工具。

另一方面，对于内部代码，Google 员工使用称为 Critique 的内部代码审查工具。没有关于 Critique 功能的详细描述，但是 Google 员工似乎对这套工作流程和功能非常满意。

Microsoft 的许多代码检查也通过工具执行。但是在 Microsoft，其他形式的代码审查也有其公正而合理的保证。有时，没有什么能打败面对面的对话。

Google 的统一流程针对速度进行了优化

综上所述，Google 对于代码审查有明确的规定。您与提交共享代码库之间的关系是至少一个具有代码所有权的人员和可读性认证的审核批准。大多数评论只有一名评论者，这也使代码审查过程变得轻便。公司范围内的代码规范，使代码清晰易读。结合较小的代码更改量，Google 员工可以在 1-5 个小时内获得代码审核反馈。

与 Microsoft 员工类似，Google 员工对代码审查过程非常满意，并发现它是有价值的工程实践。

参考

[1] https://github.com/google/styleguide

[2] https://sback.it/publications/icse2018seip.pdf