Google的代码评审在工程实践中发挥着重要作用，并且早在谷歌就已经采用。直到今天，它们仍然用于保持代码库的清洁，连贯并确保不提交任意代码。尽管代码评审过程与Microsoft的代码评审类似，但有一些Google细节允许特定的轻量级代码评审过程。
因此，让我向您展示Google的代码评审是什么样的，以及它们与Microsoft的代码评审区别开来的原因。特别是，我将向您展示什么允许Google的25,000名工程师比其他这样规模的公司更快地评审他们的代码。那么，让我们开始吧。
Google的代码评审研究
谷歌研究员凯特琳·萨多夫斯基（Caitlin Sadowski）和其他人已经开展了一项研究，以了解谷歌的内部代码审查流程。这项研究类似于微软的代码审查研究，这使得比较两家公司的代码审查流程变得有趣。
Google的典型代码审核看起来非常像Microsoft的典型代码审核。让我们通过想象一下Google员工的代码审核流程来看一个例子。我们叫他马克Mark。
1. 准备代码以供评审
这一切都是在马克对代码进行一些更改并希望将这些代码更改与共享代码库合并之后开始的。在Google，代码审查与Microsoft类似，在工具的帮助下完成。因此，在Mark发送他的代码更改以供审阅之前，他使用该工具最后一次查看代码。
谷歌的内部代码审查工具Critique提供了一些差异化功能，使Mark能够轻松发现错误并查看新版本代码中的变化。
在发送代码进行审核之前，Mark需要执行另一个步骤。通过静态分析工具运行代码，例如，在Google广泛使用的工具Tricorder，并审查静态分析工具的结果。当他对自己的变化感到满意时，他会将更改发送给至少一位代码审核人员。
2. 评审者提供反馈
代码评审员仔细查看代码，如果她发现问题或需要澄清，则留下评论。Mark然后通过更改代码或回复评论来处理每个评论。如果Mark对正在审核的代码进行了一些更改，他会上传新版本供审阅者再次检查。如果评审者满意，她可以通过将其标记为“LGTM”来批准更改（对我来说看起来不错）。为了能够将代码提交到共享代码库，至少一个评审者必须批准代码。
从远处看这段代码审查生命周期，它看起来像是Microsoft的代码审查的副本。但是，我现在会向你们展示一些深刻的分歧。
3. 公司范围的批准政策
首先，Google要求对每个代码更改进行审核。没有例外。
另一方面，在Microsoft，代码审查以及需要审查的方式和内容由各部门或团队自行决定。例如，一些团队跳过代码审查，以进行小规模和微不足道的更改。一般而言，代码审查没有任何公司范围的政策。团队和部门决定需要多少代码审查员，或者代码审查如何与测试和静态分析活动等相关联。
4. Google特有的所有权和可读性的代码审核
与微软相反，谷歌还有一些公司范围的要求，代码审查员必须满足这些要求才能批准代码更改。一个与谷歌强大的代码所有权有关。代码库的每个目录都由一组人明确拥有。为了能够获得批准的代码更改，至少有一位审阅者必须是所审查代码的所有者。那个人充当守门人。只有当这个人给他或她好的时候，才能签入上传代码。
另一个严格的要求是，评审中至少有一个人必须接受代码“可读性”的培训。这意味着此人必须已获得可读性认证。此认证表明他们已经证明他们知道代码的可读性和可维护性。 必须按语言获得可读性认证。拥有这样的标准是确保风格和设计一致性的一种很好的做法。
5. 评审人的要求不是关注资历或地位
虽然许多其他公司，包括微软的几个部门，而不是审视审查人员的资历，专业领域或授予决策权的等级，但Google会考虑所有权和可读性认证。
这解决了一些常见的代码审查陷阱。要求高级开发人员批准代码很容易导致工作超载，反过来又会造成瓶颈。
另一方面，足够的人拥有这样的可读性证书也很重要。否则，它也会产生评论瓶颈。众所周知，等待代码审查反馈是代码审查过程中的主要缺陷之一。但是，虽然获得可读性认证需要相当多的努力，但它比更改层次结构或资历更容易。
6. 如何获得可读性认证
为了展示他们审核代码的可读性，Google的开发人员将对其“代码审核实践进行审核 ”进行审核。因此，开发人员将代码更改提交给可读性专家团队。那些人会检查代码。但这次检查不像普通的代码审查。
可读性专家会仔细研究这些代码。这种评论的目的是指出每一个小错误和每一个改进的潜力，特别是在编码惯例和编码风格方面。此外，诸如缩进或额外空格之类的挑剔问题也是学习过程的一部分。有兴趣的话，您可以在这里找到各种语言的Google风格指南。
一旦专家确信开发人员已经学会并且能够应用Google的编码风格和惯例，他们就会颁发可读性认证。
7.如何获得代码批准
因此，回顾一下，要让您的代码在Google上获得批准，您需要至少一个代码审核人员拥有代码所有权以及所使用语言的正确可读性认证。如果满足这两个标准，那么你很高兴。
没有例外的规则。此外，在Google团队中，有多个开发人员必须批准，或者执行不同的审阅者标准。但是，一般规则是开发人员的批准就足够了。
Google的代码评审重量轻，速度快
谷歌明确希望其代码审查实践轻量且快速。即使Google强制执行所有权和可读性标准以进行审批，代码审核流程 - 平均需要4个小时 - 非常快。小的变化在1小时内审查，较大的变化在5小时内审查。其他公司报告的平均周转时间超过15小时。
那么，谷歌是如何做到的呢？
那么，看看报告的数据，我们可以看到有两个重要因素：审核参与者的数量和变化规模。
1. 只需要一位评审员就可以加快代码审核时间
该研究最有趣的发现之一是超过75％的代码评论只有一个评审者。这很不寻常。特别是因为研究表明两位评审者倾向于提供更有价值的反馈。
要求只有一位评审员似乎是Goggle的一个有意识的决定，并且对速度进行严格的评审。只有这样，谷歌才能实现快速周转时间。跳过等待另一个人的需要降低了很多复杂性。但它也严重损害了评审的严谨性，研究也提到了这一点。这种质量成本是多少未知。尽管如此，谷歌似乎在这种设置方面取得了很好的成果。
2. 小的更改大小对于快速和高质量的代码审查至关重要
这项研究的另一个重要见解是变化的规模。你能想象，90％的代码评论改变了少于10个文件？这真是令人印象深刻，也解释了为什么谷歌的代码审查是闪电般快速的。大多数更改也只有大约24行代码更改。这比其他公司（包括微软）的研究报告的变化幅度要小得多。
审查小而连贯的更改是经过验证的代码审查最佳实践。首先，它提高了审核速度。但是，正如我们在有价值的代码审查反馈研究中所看到的那样，它也提高了代码审查反馈的价值。随着代码审查的大小增加，代码审查反馈的有用性降低。Google员工知道这一点，并经常提交小代码更改。多么聪明！
谷歌的代码评论速度快，主要有两个原因。首先，Google上90％的代码审核包含的文件少于10个。其次，75％的评论只有一位评论者
谷歌的代码审查工具
在谷歌，代码审查是在工具的帮助下完成的。两个主要的代码审查系统在Google上占主导地位。对于与Go，Chromium等外部协作者共享的开源代码和代码，Android Google员工使用Gerrit代码审核工具。Gerrit是一个与Git集成的开源代码审查工具。
另一方面，对于内部代码，Google员工使用名为Critique的内部代码审查工具。
Microsoft的许多代码审查也通过工具进行。但在微软，其他形式的代码审查，例如并肩审查，都有其公平合理的保证。有时，没有什么可以打败面对面的谈话。
Google的统一流程针对速度进行了优化
总而言之，Google已明确指出如何批准代码审核。您与共享代码库的提交之间的区别在于至少一个拥有代码所有权和可读性认证的人的审核批准。大多数评论只有一个评论者在代码审查过程中也需要很多复杂性。公司范围内的代码样式，清晰明了可读代码的外观。结合较小的代码更改大小，Google员工可以在1-5小时内获得代码审核反馈。
与Microsofties类似，Google员工对代码审查流程非常满意，并认为它是一种有价值的工程实践。