开发人员满意度高达 97%： 谷歌是如何消除代码审查的痛苦的
很多前谷歌工程师都在谈论，在他们留下的所有内部工具中，他们是多么怀念谷歌的代码审查工具 Critique。
另一条 Reddit 评论感叹他们 “miss [Critique] so bad”, 并列举了他们怀念的各种功能，比如 “关注集”，下文将对此进行解释。
这与谷歌自己的调查结果不谋而合。在谷歌内部，97% 的软件工程师对 Critique 表示满意1。
但 Critique 究竟是什么，它为什么这么好？
它与谷歌实际的代码审查流程是如何配对的？
在本文中，我将深入探讨：
- 谷歌高效代码审查指南
- Critique、其代码审查工具和人工智能驱动的改进
- 有关 Google 代码审查的内部统计数据
- 为什么 Critique 深受 Googlers 的喜爱？
虽然 SWE 书籍涵盖了 Critique 的基础知识，但新的博客文章和 Google 的研究显示了其代码审查流程的新进展，例如使用人工智能对代码更改提出自动建议和改进。
谷歌代码审查指南
要了解 Google 如何编写简洁、可维护的代码，我曾在这里介绍过 Google 的可读性流程。
谷歌的良好代码审查准则包括：
- 持续改进胜于完美：经验丰富的开发人员可能会认为经验不足的开发人员的代码不符合他们的个人标准，但谷歌鼓励不断改进，而不是追求完美。开发人员需要不断进步；过于苛刻的审查会阻碍未来的改进。
- 维护或改善代码库的健康状况
- 遵循风格指南：当代码风格出现问题时，应严格遵循并参考 Google 的风格指南。
- 始终分享知识：我们鼓励审阅者通过代码审阅分享有关语言特点、代码库和其他相关工件的知识。通常，这些指南会与 “辅助文档 “一起发送，例如 Google/Abseil 的 “本周 C++ 技巧 “链接。
- –>在谷歌，代码审查的教育意义得到了高度重视。
- 编写小改动：尽可能将修改限制在 200 行代码以内。
- 严格的轻量级标准：谷歌希望审查员在 24 小时内审查代码变更，并鼓励审查尽可能只由一名审查员进行，从而为每个相关人员节省时间。
- “谷歌的大多数变更都很小，只有一个审核员，除了授权提交外没有其他评论。在一周内，70% 的变更在寄出进行初步审核后的 24 小时内提交。
- 礼貌和专业精神：保持信任和尊重的文化至关重要。反馈应当专业，避免个人批评。审稿人应对作者的方法持开放态度，只有在必要时才提供替代方案，并将每一条意见都视为学习的机会。
- 我想特别谈谈这一点，因为虽然它看起来显而易见，但在实践中却不那么容易做到。人们往往会对自己编写的代码情有独钟，或者审阅者会显得比他们的本意更苛刻。与面对面的交流相比，书面交流的细微差别较少。
- 谷歌对代码注释如何影响开发人员的工作效率和积极性进行了大量研究。
要通过变更列表（CL 是谷歌版本的拉取请求或 PR），它必须有 0 条未解决的评论、至少一位审阅者的 LGTM（对我来说看起来不错）以及 2 种类型的批准：
- 文件所在代码库的 “拥有者”
- 可读性审批人，他们审批代码的 “可读性 “和风格
一个人可以同时担任 LGTM 负责人和审批人。
Critique：谷歌代码审查工具
Critique 是 Google 的代码审查工具，允许工程师高效地审查和提交代码更改。
他们还可以查看当前代码库和建议修改之间的差异：
重要的是，谷歌最近2023年发表的文章显示，他们目前在内部拥有全面的人工智能驱动的代码审查工具（如上图所示）。
当审阅者在代码上留下评论时，Critique 会显示由人工智能驱动的编辑建议，这意味着代码审阅的作者只需点击一个按钮，就能完整地处理评论。
基于谷歌研究论文的最新进展告诉我们，谷歌正在尽可能利用人工智能驱动的代码审查工具提高开发人员的工作效率。
SWE 书籍详细介绍了Critique，篇幅超过 5000 字，但我在此总结了其中的要点，并为想要深入了解的读者提供了链接。
阶段 1：创建变更
在谷歌内部代码编辑器 Cider 中创建 CL（或 Pull Request），该编辑器 “与 Critique 和其他谷歌内部工具紧密集成”，可提高开发人员的工作效率。
- 预览工具：Critique 可在审核前帮助完善变更，显示差异、构建和测试结果以及样式检查。
- 差异化和可视化：通过语法高亮显示、交叉引用、内部差异、忽略空白和移动检测等功能得到增强。
- 分析结果：显示来自静态分析器的结果，突出显示重要发现并提供修复建议。其中包括 “预提交”（presubmits），即在 Critique 中运行的自动测试，可强制执行特定于项目的不变式。
Critique 集成了分析作者的反馈渠道。
审阅者可以选择在分析生成的评论上点击 “Please fix”（请修复），作为作者应修复问题的信号。
作者或审阅者都可以点击 “无用”，以标记对审阅过程无益的分析结果。(资料来源）
阶段 2：请求审核
当拉取请求准备好接受审查时，代码作者会添加审查员，并将其正式发送给他们进行审查。
当 PR/CL 被送审时，如果 “预提交 “尚未在当前代码快照上运行，则会运行 “预提交”。这意味着参与审核的每个人都知道代码是否有任何缺陷。
摘自 SWE 手册
代码审查也可以匿名化，即代码作者可以对审查者匿名。不过，谷歌并未发现匿名代码审查与 “真正的 “代码审查之间有多大区别。
第 3 和第 4 阶段：了解变更并提出意见
任何人都可以对变更发表评论，而且还有跟踪审查进度和解决评论的功能。
- 未解决的注释表示变更作者必须解决的行动项目。代码作者可以在回复评论时将其标记为 “已解决”。
- 已解决的注释包括可选注释或信息性注释，可能不需要变更作者采取任何行动
有一个审查状态仪表板和一个 “关注集”，它可以让参与某个代码审查的人知道谁是当前被等待的人。
关注集通常是谷歌工程师高度关注的功能。
第 5 阶段：变更批准
如上所述，要提交审核，至少需要一名审核员的 LGTM。它需要 0 条未解决的评论，不过代码作者可以在回复时自行标记已解决的评论。此外，还需要代码所在代码库所有者的批准以及可读性批准。
如前所述，所有这些都可以由一名审核员完成。
阶段 6：提交修改
在 Critique 中提交和提交修改。
即使在提交修改后，Critique 仍有价值。
“谷歌的研究人员发现了强有力的证据，证明 Critique 的用途超出了审查代码。变更作者使用 Critique 来检查差异和浏览分析工具的结果。在某些情况下，代码审查是变更开发过程的一部分：审查者可能会发送一个未完成的变更，以便决定如何完成实施。此外，开发人员还可以在提交的变更被批准后很长时间内使用 Critique 来检查这些变更的历史记录”。
谷歌的现代代码审查统计
谷歌专门对公司的代码审查进行了研究。我从他们的论文中列出了一些有趣的统计数据。
更改编写频率：
- 中位数：每周更改 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 贡献者的调查发现，开发人员认为与大小相关的因素对审核延迟的影响最大。(资料来源）
此外，每项变更收到的评论数量会随着资历的增加而减少。
为什么 Critique 深受 Googler 的喜爱？
大多数 Googler 和前 Googler 都是 Critique 的忠实粉丝。
在谷歌内部，97% 的软件工程师对 Critique 感到满意。
我询问了 7 位谷歌人，为什么他们更喜欢 Critique，而不是他们过去可能用过的工具，比如 GitHub。
他们指出:
- 静态分析：谷歌拥有一套功能齐全的静态分析工具，可自动提供可操作的代码反馈。这可以节省代码作者和审核人员的时间，因为审核人员无需对明显的项目吹毛求疵。
- 只关注最新更改的文件：只关注代码的最新 “快照”。之前的快照、提交和代码更改都不是重点，这样用户界面就会更简洁。
- 熟悉的并排 diffing 界面：它默认显示 “上次审查的差异”。
- 由 ML 支持的建议：谷歌全新的 ML 建议大大加快了代码审核速度。
- 与其他 Google 工具紧密集成：Critique 与 Google 的集成开发环境和其他内部工具（如错误跟踪器）集成得非常好。当一切都连接在一起时，工作效率就会更高。
- 这包括轻松链接代码、注释和票据。
- “行动集 “跟踪：这可以让人们知道谁应该采取下一步行动。
- 令人满意的游戏化：虽然 Critique 并不是为了游戏化而设计的，但 Googler 报告说，他们很享受 Critique “变绿 “的感觉，这意味着 PR 可以提交了（所有测试都通过了，审阅人 LGTM 编辑并批准了）。
- 令人惊叹的键盘快捷键，让您高效查看大量代码
- 默认显示 “与上次审查的差异”
- 它具有 “代码移动检测 “功能，因此审阅者可以专注于代码的变化，而不是无用的移动
- 它能很好地跟踪应该由谁采取行动，无论是审阅者还是作者
- 还有一个配套的 Chrome 浏览器扩展，可以轻松获取通知并查看你的审阅队列
- 任何内部人员都可以针对代码审核数据运行查询，以收集洞察力并做出决策。
- 自动链接代码和评论（包括tickets 和 go/ 链接）
- 以表格形式查看 PR 的分析、历史和注释，从而更容易了解包含多轮代码的 PR 的进展情况
还有一些他们没有提到的社交功能：
- 可选、仅供参考等注释的术语/标记非常一致
- 审稿人经常链接文档和风格指南
编辑：他们还有一个能进行代码突变测试的静态分析工具，这对捕捉遗漏的测试覆盖率非常有用。
Source: I miss it so bad
一项针对 88 名 Mozilla 开发人员的定性研究发现，静态分析集成是代码审查中最常被要求的功能。
自动分析可以让审核人员专注于变更的可理解性和可维护性，而不是被琐碎的评论（如格式）所干扰。
感想和收获
虽然这些功能中的许多在今天的其他工具中也有，但我相信，正是因为这些工具的紧密集成和极度 “个性化”，使其成为谷歌特有的工作流程和代码库，才会受到如此的喜爱。
同时，这也意味着每家公司都想完全复制 Critique 和相关工具是不现实的。例如，他们的一些工具似乎是专门针对其 monorepo 结构所带来的挑战而设计的。
虽然 Critique 本身永远不会开源，但 Gerrit 是与 Critique 类似的工具。它是一款开源代码审查工具，同样由 Google 创建和维护。
不过，我认为谷歌确实在开发人员的工作效率方面投入了大量精力和心血。他们免费发布了自己的研究成果，并从中获得了有益的启示。
本文文字及图片出自 How Google takes the pain out of code reviews, with 97% dev satisfaction
