开发者满意度高达 97%,Google 如何摆脱代码审查的痛苦?

代码审查是软件开发流程中的重要部分，这一环节可以有效提升代码质量，减少 Bug 存在。然而，对于很多程序员而言，进行代码审查无疑是痛苦的，甚至有人认为它拖慢了进度、不利于快速上线......那么，代码审查是否有必要？

本文将以科技大厂 Google 为例，分享 Google 内部的做法以及代码审查工具，希望我们可以从中吸取一些有益的经验。

原文地址：https://read.engineerscodex.com/p/how-google-takes-the-pain-out-of

作者 | engineerscodex 译者 | 弯月     责编 | 苏宓
出品 | CSDN（ID：CSDNnews）

以下为译文：

许多前 Google 工程师都提到他们非常怀念 Critique。这是 Google 自己的代码审查工具，也是他们最恋恋不舍的一款 Google 内部工具。

https://twitter.com/nsthorat/status/1728211545165828162

有人在 Reddit 的一篇文章中列举了他们非常看好的功能，比如“attention set”等。

这与 Google 的调查结果相符，Google 内部 97% 软件工程师都很满意 Critique。

那么，Critique 究竟是什么，它有何优点？又如何与 Google 的代码审查流程配合使用呢？

在本文中，我将探讨：

• Google 的高效代码审查准则。

• Critique：Google的代码审查工具，以及基于 AI 的改进。

• Google代码审查的内部统计数据

• 为什么Critique在Google内部备受推崇？我们可以从这学到什么？

Google的代码审查准则

Google的代码审查准则包括：

• 不求完美，但要持续改进 ：尽管经验丰富的开发者可能觉得经验较少的开发者的代码达不到他们的个人标准，但Google鼓励持续改进，而非追求完美。开发者需要不断进步，过于苛刻的审查不利于将来的提升。

• 保持或提高代码库的健康度。

• 遵循代码指南 ：在涉及代码风格的问题上，必须严格遵循和参考Google风格指南（ https://go ogle.github.io/styleguide/ ）。

• 分享知识： 鼓励审查者通过代码审查分享有关语言特性、代码库以及其他相关的知识。通常，这些准则会附上“支持文档”，比如链接到Google/Abseil的C++每周技巧。

  Google内部高度强调代码审查的教育。

• 小范围的变更： 尽量将变更限制在约200行代码以内。

• 严格的标准，但保持轻量级： Google希望审查者在24小时以内审查代码变更，并鼓励只有一名审查者，目的是节省所有相关 人员的时间。 在Google，大多数代码变更都很小，且只有一名审查者， 除了授权提交的确认外，没有其他评论。一周内，70%的变更都会在初次审核申请后的24小时内确认提交。

• 礼貌和职业操守： 信任和尊重的文化至关重要。反馈应专业，避免个人批评。审查者应该对作者的方法持开放态度，仅在必要时提供替代方案，并将每条评论视为学习的机会。

  我想特别说一说这一点，虽然看似很明显，但在实践中并不容易做到。人们往往对自己编写的代码有特殊的感情，而审查者的严厉程度也有可能超过自己的预期。与面对面交流相比，书面文字可以减少沟通的语气带来的影响。

• Google针对代码评论对开发者的生产力和动力的影响做了大量研究。

  - 预测开发者对代码审查的负面感受 （https://storage.googleapis.com/pub-tools-public-publication-data/pdf/7ac08fa960dfe10561c1f5953419a0c945279faa.pdf）

  -  代码审查中的破坏性批评影响包容性 （https://research.google/pubs/pub51232/）

  -  检测问题和代码审查中的人际冲突： 跨开源和闭源方法的交叉汇流 （https://research.google/pubs/pub51204/）

  - 使代码审查更加公平的研究 （https://developers.googleblog.com/2022/06/Using-research-to-make-code-review-more-equitable.html）

一个变更列表（变更列表是Google的拉取请求，相当于PR）要想通过审查，就不能有残留的未解决评论，而且至少有一名审查者给出“我觉得没问题”的意见，并获得两种类型的审核批准：

• 文件所属代码库部分的“拥有者”的批准。

• 可读性批准，负责批准代码的“可读性”和风格。

一个人可以同时负责以上三种审核工作。

Critique：Google的代码审核工具

Critique是Google的代码审核工具，可帮助工程师高效地审核和提交代码变更。

另外，Critique还提供了当前代码库和建议变更之间的差异视图。

重要的是，2023年Google最新发布的消息显示，他们内部拥有全面的人工智能驱动的代码审查工具（如上图所示）。

当审查者在代码上留下评论时，Critique将显示一些建议，而这些建议都来自机器学习，这意味着代码的作者只需点击一个按钮就可以解决评论。

根据Google的研究论文，最近的进展表明Google正在尽可能地通过人工智能驱动的代码审查工具提高开发人员的生产力。

代码审核流程 我总结了Critique的一些关键要点，原文请点击这里 （https://abseil.io/resources/swe-book/html/ch19.html）。 阶段1：创建变更 在Google的内部代码编辑器Cider中创建一个CL（变更列表，即PR），该编辑器“紧密集成”了Critique以及其他Google内部工具，从而提高了开发人员的生产力。

• 预审工具：在审核开始之前，在Critique的帮助下最后一次打磨代码，然后显示差异、构建和测试结果，并进行风格检查。
• 差分比较和可视化：比较结果带有高亮显示语法、交叉引用、行内差异、忽略空白，以及检测并隐藏了被移动的代码。
• 分析结果：显示静态分析器的结果，突出显示重要发现并提供修复建议。包括“预提交”，即Critique中运行的自动化测试，可强制执行项目特定的不变量。

Critique整合了分析作者的反馈渠道。 审核者可以点击分析生成的评论上的“请修复”，表示作者应该解决这个问题。 代码的作者和审核者都可以点击“没有帮助”，用于标记对审查过程没有提供实质性帮助的分析结果。

阶段2：请求审查 当PR准备好，可以开始审核时，代码的作者会添加审查者，并正式将代码发送给他们进行审查。 当PR或变更列表已送审核时，如果尚未在当前代码快照上运行“预提交”，则运行这些测试。这意味着，参与审查的所有人都能知道代码是否有问题。

代码审查也可以匿名，即代码作者的身份对审查者保持匿名。然而，Google并未发现匿名审查和“真实”的审查之间有太大的差异。

阶段3~4：理解代码变更，并给予评论

任何人都可以针对代码变更发表评论，并且有跟踪审查进度和解决评论的功能。

未解决的评论表示代码的作者必须解决的问题。代码变更作者在回复评论时，可以将其标记为“已解决”。

已解决的评论包括可选或信息性的评论，表示可能不需要变更作者采取任何行动。

此外，还有一个审查状态的仪表板和一个attention set，可以让代码审查者知道当前正在等待谁的回复。

attention set是Google工程师非常喜欢的一个功能。

阶段5：变更批准

如上所述，Google的代码审查至少需要一名审核者给出“我觉得没问题”的意见。此外，代码变更不能有残留的未解解决评论，但代码作者可以在回复时自行将评论标记为已解决。最后，还需要相关代码库部分所有者的批准，以及可读性批准。

如前所述，所有这些都可以由一名审核者完成。

阶段6：提交变更

在Critique中提交代码并确认提交。

在提交变更后，Critique还能发挥作用。

“Google研究人员发现，Critique的用途不仅限于代码审查。代码变更的作者使用Critique来检查代码的差分，并浏览分析工具的结果。在有些情况下，代码审查是变更开发过程的一部分：审核者可能会发送未完成的变更，以决定如何完成实现。此外，在代码变更被批准很久之后，开发人员还会使用Critique来检查提交的变更历史。”

Google的现代代码审查统计数据

Google特意针对公司的代码审查进行了一项研究。下面是他们的论文中一些有趣的统计数据。

变更作者频率：

• 中位数：每周3次变更。

• 80％的作者每周的变更次数少于7次。

审查频率：

• 中位数：每周4次变更审查。

• 80％的审查者每周处理的变更审查少于10次。

代码审查每周所花费的时间：

• 平均：每周3.2小时

• 中位数：每周2.6小时

初始反馈的等待时间：

• 小变更：中位数小于1小时。

• 非常大的变更：约5小时。

审查流程整体的时间：

• 审查的延迟中位数（包括所有规模的代码）：低于4小时。

• 与其他公司的比较：

  AMD：17.5小时（批准时间中位数）。

  Chrome OS：15.7小时。

  微软项目：14.7小时、19.8小时和18.9小时。

  微软（另一项研究）：24小时。

“先前的研究发现，随着变更规模的增加，有帮助的评论数量会减少，审查延迟将增加。变更的大小还会影响开发人员对代码审查过程的看法。Mozilla贡献者的一项调查发现，开发人员认为与代码规模相关的因素对审查延迟的影响最大。”

此外，每次变更收到的评论数量会随着资历的增加而减少。

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/80735342aebcbfc8af4878373f842c25323cb985.pdf

为什么Critique在Google内部备受青睐？

大多数Google员工以及前员工都是Critique的忠实用户。

在Google内部，对Critique感到满意的软件工程师数量高达97%。

我询问了7名Google员工，为什么相较于过去使用过的工具（比如GitHub），他们更喜欢Critique。

他们指出：

• 静态分析 ：Google拥有一套功能完备的静态分析工具，可自动为代码提供可操作的反馈。这为代码作者和审查者节约了很多时间，因为审查者不必在显而易见的问题吹毛求疵。

• 仅关注最新变更的文件 ：只关注代码的最新“快照”。不关心以前的快照、提交和代码变更，这样用户界面更清晰。

• 熟悉的、并排显示差分的界面 ：默认显示“与上次审核相比的差异”。

• 机器学习提供建议 ：Google最新的机器学习提供支持的建议极大地加快了代码审查的速度。

• 与Google其他工具的紧密集成 ：Critique与Google的IDE以及其他内部工具（如bug跟踪器） 的集成非常好，能够提高生产力。包括代码、评论以及任务票的链接。

• “行动集”跟踪 ：让人们知道谁应该采取下一步的行动。

• 令人满意的游戏机制 ：虽然Critique不是为了游戏化而构建的，但有的Google员工报告说，他们很喜欢看到Critique“变绿” ，因为这意味着PR已准备好提交了，即通过了所有测试，且得到了审核者的批准。

引用关于静态分析的一个调查报告：

一项针对88名Mozilla开发人员的定性研究发现，静态分析集成是代码审查中最常请求的功能。

有了自动分析，审查者就可以专注于代码变更的可理解性和可维护性，而不会因琐碎的评论（例如格式）分心。

思考和收获

虽然如今许多工具都具备这些功能，但我认为正是因为与各种工具的紧密集成，以及Google的特定工作流和代码库的极端“个性化”，使Critique备受喜爱。

与此同时，这也意味着并不是每家公司都能完整地复制Critique以及其他相关工具。例如，他们的一些工具主要是为了解决单一代码库结构带来的挑战。

虽然Critique永远不会成为开源项目，但Gerrit（ https://gerrit.googlesource.com/gerrit/ ）是一款类似于Critique的工具，这是由Google创建并维护的开源代码审查工具。

然而，我认为Google确实为提高开发者的生产力做了很多努力和思考。我们可以从中吸取很多有益的经验。

推荐阅读：

▶大模型时代程序员应有的正确姿势

▶ 在 Excel 中构建 16 位 CPU！国外大牛极限“整活”：128KB RAM、16 色显示，还有自定义汇编

▶“删不掉”的 AI 助手！开发者向 JetBrains 发出抗议：公司不让用 AI，代码可能会被泄露