代码审查是大规模软件开发过程中的一个重要部分，占用了代码提交人员和代码审查员的大量时间。在这个过程中，审查员会审查代码中的问题，并编写的评论要求作者进行代码更改。在 Google，我们每年看到数百万条审查员的评论，作者们需要花费大约 60 分钟的时间来应对这些评论，并根据评论的文本提出代码更改。我们研究发现，代码作者为解决审查员评论必须付出的工作时间几乎随评论数量线性增长。然而，借助机器学习（ML），我们可以自动化并简化代码审查过程，例如，根据代码审查评论自动给出对应的代码变更。
今天，我们采用了最近在序列模型中的先进技术，以自动解决 Google 日常开发工作流程中的代码审查评论（即将发布）。截止今天，Google 的工程师已经可以通过应用 ML 建议的修改来处理大量的代码审查员评审建议。我们预计这将每年为 Google 节省数十万小时的代码审查时间。我们收到了很多非常积极的反馈，说明了机器学习建议的代码修改确实提高了 Google 开发人员的生产力, 能够让他们专注于更有创造力和复杂的任务。
预测代码修改
我们首先训练了一个模型来预测解决评论所需的代码修改。该模型在各种编码任务和相关的开发者活动 (例如,重命名一个变量, 解决构建过程中的错误, 编辑一个文件) 上进行了预训练。然后，使用审查过的代码修改、审查员的评论以及作者执行的解决这些评论的修改，对该模型进行特定任务的微调。
这是一个基于 ML 建议进行代码重构的一个实例。
Google 使用一个 单体仓库（monorepo），这是一种源代码管理策略，所有的代码和资源都存储在同一个仓库中，而不是分散在多个仓库中。这种策略有许多优点，包括代码共享和重用、大规模重构、协作和依赖管理等。这使得我们的训练数据集能够包含用于构建 Google 最新软件及其之前版本的海量代码。
为了改进模型质量，我们不断迭代训练数据集。例如，我们比较了包含每个文件的单个审查员评论的数据集与每个文件的多个评论的数据集的模型性能，并使用分类器根据一个小型、精心策划的数据集来清理训练数据，以选择具有最佳离线精度和召回率指标的模型。
服务基础设施和用户体验
我们在训练好的模型的基础上设计和实现了这个功能，重点关注整体用户体验和开发者效率。作为其中一部分，我们通过一系列用户研究，探索了不同的用户体验（UX）替代方案。然后，我们根据来自内部测试版（即，开发中的功能测试）的洞察，包括用户反馈（例如，在建议的编辑旁边 加入 “这有帮助吗？（Was this helpful）”按钮），对功能进行了优化。
最终的模型被校准为目标 准确率 为 50%。也就是说，我们调整了模型和建议过滤，以使我们的评估数据集中 50% 的建议修改是正确的。一般来说，提高目标准确率会减少显示的建议编辑的数量，降低目标准确率会导致更多的错误建议编辑。错误的建议编辑会占用开发者的时间，降低开发者对该功能的信任。我们发现，目标准确率为 50% 提供了一个良好的平衡。
在较高层次上，对于每个新的审查员评论，我们以与训练相同的格式生成模型输入，查询模型，并生成建议的代码修改。如果模型对预测有信心，并且满足了一些额外的启发式规则，我们就会将建议的修改发送到下游系统。下游系统，即代码审查前端和集成开发环境（IDE），向用户展示建议的编辑，并记录用户交互，如预览和应用事件。一个专门的管道收集这些日志，并生成汇总洞察，例如，本博客文章中报告的总体接受率。
ML 建议编辑（ML-suggested edits）基础设施的架构。我们处理来自多个服务的代码和基础设施，获取模型预测并在代码审查工具和 IDE 中显示预测结果。
开发者在代码审查工具和 IDE 中与 ML 建议的编辑进行交互。根据用户研究的洞察，集成到代码审查工具中最适合于流线型的审查体验。IDE 集成提供了额外的功能，并支持在审查过的代码状态（右图）上有冲突的本地更改情况下，对 ML 建议的编辑（左图）进行三方合并，合并到合并结果（中图）。
IDE 中的三向合并的演示
结果
离线评估表明，模型以 50% 的目标精确度解决了 52% 的评论。测试版和完整内部发布的在线指标确认了这些离线指标，也就是说，我们看到约 50% 的所有相关审查员评论上，模型建议的信心超过了我们的目标模型信心。代码作者应用了所有预览过的建议编辑的 40% 到 50%。
在测试版期间，我们利用 “没有帮助（not helpful）” 的反馈来识别模型的常见失败模式。我们实施了服务时间启发式规则来过滤这些，并因此减少了显示的错误预测的数量。通过这些更改，我们用质量换取了数量，并观察到现实世界接受率的增加。我们的测试版推出显示出一个潜在的问题：代码作者只预览了约所有生成的建议编辑的 20%。我们优化了用户体验，在审查员评论旁边引入了一个显眼的 “显示 ML 编辑（Show ML-edit）” 按钮（参见上图），在发布时的总预览率约提升到了 40%。我们还发现，由于作者在审查过程中进行了冲突的更改，代码审查工具中的建议编辑经常不适用。我们用一个按钮解决了这个问题，这个按钮在代码审查工具中打开了一个合并视图，用于建议的编辑。我们现在观察到，这些中有超过 70% 的在代码审查工具中应用，不到 30% 的在 IDE 中应用。所有这些改变使我们能够将采用 ML 建议编辑解决的审查员评论的总体比例增加了两倍，从测试版到完全内部发布。在 Google 可以帮助我们每年自动解决几十万条评论。
建议过滤漏斗
我们看到 ML 建议的编辑在生产中解决了审查员评论的广泛范围。这包括简单的局部重构和在代码中分散的重构，如上述博客文章中的示例所示。该功能解决了需要代码生成、重构和导入的较长和非正式措辞的评论。
一个需要代码生成、重构和导入的较长且代码评审建议的示例
模型也可以回应复杂的评论并产生较大范围的代码修改（如下所示）。生成的测试案例遵循现有的单元测试模式，同时更改评论中描述的细节。此外，编辑建议了一个全面的测试名称，反映了测试的语义。
模型回应复杂评论并生成大量代码修改的能力的示例
结论和未来工作
在这篇文章中，我们介绍了一个机器学习（ ML）辅助功能，以减少在代码审查相关修改上花费的时间。目前，在 Google 使用的编程语言中，大量的所有可操作的代码审查评论都可以通过应用 ML 建议的编辑来解决。我们将在所有 Google 开发人员中进行的为期 12 周的 A/B 实验将进一步衡量该功能对整体开发者生产力的影响。
我们正在全面优化整个技术栈。这包括提高模型的质量和召回率，给开发者提供更流畅的使用体验，通过改进发现性（提供清晰的界面和导航，以帮助用户快速找到他们所需的功能，而无需花费过多的时间和精力）来提升整个审查过程的体验。作为其中的一部分，我们正在研究在审查员草拟评论时显示 ML 建议的编辑的功能，并将功能集成到 IDE 中，以便代码变更的作者能够在获取审查人员的描述时就可以获得 ML 的代码修改建议。
致谢
这是 Google 核心系统和体验团队、Google Research 和 DeepMind 的许多人的共同研究成果。我们特别感谢 Peter Choy 为我们的合作提供支持，以及我们团队所有成员的关键贡献和有益建议，包括 Marcus Revaj、Gabriela Surita、Maxim Tabachnyk、Jacob Austin、Nimesh Ghelani、Dan Zheng、Peter Josling、Mariana Stariolo、Chris Gorgolewski、Sascha Varkevisser、Katja Grünwedel、Alberto Elizondo、Tobias Welp、Paige Bailey、Pierre-Antoine Manzagol、Pascal Lamblin、Chenjie Gu、Petros Maniatis、Henryk Michalewski、Sara Wiltberger、Ambar Murillo、Satish Chandra、Madhura Dudhgaonkar、Niranjan Tulpule、Zoubin Ghahramani、Juanjo Carin、Danny Tarlow、Kevin Villela、Stoyan Nikolov、David Tattersall、Boris Bokowski、Kathy Nix、Mehdi Ghissassi、Luis C. Cobo、Yujia Li、David Choi、Kristóf Molnár、Vahid Meimand、Amit Patel、Brett Wiltshire、Laurent Le Brun、Mingpan Guo、Hermann Loose、Jonas Mattes、Savinee Dancs。
原文链接：https://ai.googleblog.com/2023/05/resolving-code-review-comments-with-ml.html