Google 是如何作 Code Review 的

本文由知乎网友 漫慢忙 翻译自 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 的开发人员进行了“对其代码审查实践的审查”。所以，开发人员将代码更改提交给可读性专家团队。这些人将检查代码。可是这种检查并不像普通的代码审查那样。可读性专家会仔细检查代码。此类审查的目的是指出每一个小错误以及每一个改进的潜力，尤为是在编码约定和编码样式方面。并且，诸如缩进或多余空间之类的挑剔问题也是此过程的一部分。若是您有兴趣，能够在这里¹找到 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