现代代码审查中 AI 辅助的编码实践评估

Manushree Vijayvergiya manushree@google.com Google Zurich, Switzerland

Pascal Lamblin lamblinp@google.com Google Montreal, Canada

Jovan Andonov jandonov@google.com Google Zurich, Switzerland

Małgorzata Salawa magorzata@google.com Google Zurich, Switzerland

Marko Ivanković markoi@google.com Google Zurich, Switzerland

Goran Petrović goranpetrovic@google.com Google Zurich, Switzerland

Ivan Budiselić ibudiselic@google.com Google Zurich, Switzerland

Dan Zheng danielzheng@google.com Google Mountain View, USA

Juanjo Carin juanjocarin@google.com Google Sunnyvale, USA

Mateusz Lewko mlewko@google.com Google Zurich, Switzerland

Daniel Tarlow dtarlow@google.com Google Montreal, Canada

Petros Maniatis maniatis@google.com Google Mountain View, USA

René Just^∗ rjust@cs.washington.edu University of Washington Seattle, USA

摘要

现代代码审查是代码作者提交的增量代码贡献在提交到版本控制系统之前由一个或多个同行审查的过程。现代代码审查的一个重要元素是验证代码贡献是否遵循最佳实践。虽然其中一些最佳实践可以自动验证，但验证其他最佳实践通常由人工审查员完成。本文报告了 AutoCommenter 的开发、部署和评估，这是一个由大语言模型支持的系统，用于自动学习和执行编码最佳实践。我们为四种编程语言（C++、Java、Python 和 Go）实现了 AutoCommenter，并在大型工业环境中评估了其性能和采用情况。我们的评估表明，一个用于学习和执行编码最佳实践的端到端系统是可行的，并且对开发人员工作流程有积极影响。此外，本文还报告了将这样的系统部署到数万名开发人员所面临的挑战以及相应的经验教训。

CCS 概念

• 软件及其工程 → 软件验证与确认。

∗在 Google 完成的工作。

允许免费制作本作品全部或部分的数字或硬拷贝，用于个人或课堂用途，前提是拷贝不以盈利或商业优势制作或分发，并且拷贝在第一页上带有本通知和完整引用。必须尊重本作品第三方组件的版权。对于所有其他用途，请联系所有者/作者。AIware '24，2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas © 2024 版权由所有者/作者持有。ACM ISBN 979-8-4007-0685-1/24/07 https://doi.org/10.1145/3664646.3665664

关键词

人工智能，代码审查，编码最佳实践

ACM 引用格式：

Manushree Vijayvergiya, Małgorzata Salawa, Ivan Budiselić, Dan Zheng, Pascal Lamblin, Marko Ivanković, Juanjo Carin, Mateusz Lewko, Jovan Andonov, Goran Petrović, Daniel Tarlow, Petros Maniatis, and René Just. 2024. AI-Assisted Assessment of Coding Practices in Modern Code Review. In Proceedings of the 1st ACM International Conference on AI-Powered Software (AIware '24), July 15–16, 2024, Porto de Galinhas, Brazil. ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/3664646.3665664

1 引言

现代代码审查 [21, 23]（相对于整体代码审查 [8]）在开源和工业环境中多年来有机发展。已经出现了一套常见的同行审查标准 [5, 20, 21]，其中包括编码最佳实践。许多公司、项目甚至编程语言都以"风格指南"[1-4] 的形式正式定义它们，通常涵盖以下方面：

• 格式化：行数限制、空格和缩进的使用、括号和方括号的放置等；
• 命名：大小写、简洁性、描述性等；
• 文档：文件级、函数级和其他注释的预期位置和内容；
• 语言特性：在不同（代码）上下文中使用特定语言特性；
• 代码习语：使用代码习语来提高代码清晰度、模块化和可维护性。

开发人员通常报告对现代代码审查流程的高度满意度 [23, 28]。其主要好处之一是为不熟悉代码库、特定语言特性或常见代码习语的代码作者提供学习体验。在审查过程中，经验丰富的开发人员会教育代码作者关于最佳实践，

def test file url not allowed(self): fake file url = " fake_image.png" with self.assertRaises(ValueError) as ve: with self.assertRaisesRegex( ValueError, f"File URL not explicitly allowed: {fakefile url}" ds web utils.get url to bytes( fake file url, colab debug=False, allow file url=False ) Self.assertEqual( str(ve.exception), "File URL not explicitly allowed: " + str(fakefile url), ) Reviewer anonymized Consider using self.assertRaisesRegex here insteadof "~ Mar 6, 9:01 PM self.assertRaises + self.assertEqual on the exception, as it has the same effect. Note that you can also use partial string matching here if desired. python-style-advice#common_exception_message Author anonymized Done. Good idea! a Mar 7, 10:53 PM

AIware '24, 2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas

现代代码审查中的 AI 辅助编码实践评估

大规模预处理（定期） 数据集管理（按需） 训练和微调（按需） 注释源 输入/目标 Tensorboard 格式 存储库 调度器 工作器 工作器 工作器 相关代码 工作器 工作器 工作器（时间 示例 TPU 节点 工作器 工作器 模型 分割） 检查点

图 2：模型训练流程的架构。

可读性流程有一些缺点。对于作者来说，由于额外的审查轮次，它增加了开发时间。对于可读性导师来说，这可能成为一项单调且耗时的任务。它需要掌握数百个不断发展的最佳实践，包括识别和弃用过时的规则，并在代码审查系统中记录它们（带相关链接）。此外，它需要有时通过多次迭代来跟踪，确保所有违规行为都得到纠正。

3 方法

为了应对第 2.1 和 2.2 节中描述的挑战，我们开发了 AutoCommenter，这是一种自动检测最佳实践违规的代码分析工具。它旨在为代码作者提供及时的反馈，并减轻手动最佳实践审查的需要，从而使审查员能够专注于代码功能。

3.1 模型和任务定义

自动化最佳实践分析需要一个能够表示源代码、精确定位违规位置并识别违反的最佳实践的模型。我们使用基于 T5 的传统 transformer 方法，使用 T5X [22] 来实现文本到文本转换。

最佳实践分析是多任务大序列模型中的一个任务。除了 T5 的标准预训练任务、跨度去噪（预测掩码标记）之外，用于训练此模型的其他任务还包括代码审查注释解决、下一次编辑预测、变量重命名和构建错误修复 [9]。训练语料库包含超过 30 亿个示例，其中最佳实践分析数据集贡献了约 80 万个示例。使用此类模型典型的标准交叉熵损失进行训练，并进行调整以最大化序列准确度指标，预测每个示例的确切目标文本。

对于最佳实践分析，模型的输入是任务提示和源代码，目标是源代码位置和最佳实践违规的 URL。任务提示格式化为固定文本代码注释，使用编程语言的适当注释样式。它用自然语言描述任务，并位于源代码之前，源代码是一个文件的直接文本表示。如果输入超过模型上下文窗口，它会被截断。位置是源代码中的字节偏移量，URL 引用违反的最佳实践。领域特定语言定义目标格式，如果没有违规，特殊情况是"空"目标。除目标外，模型输出 0 到 1 之间的置信度分数。

考虑以下 Go 语言的输入/目标示例。

输入

// [*] 任务：检查语言最佳实践。// Package addition 提供 Add package addition

// 返回一个和 func Add ( value1 , value2 int ) int { return value1 + value2 }

目标

INSERT 153 COMMENT https : // go . dev / doc / comment # func

输入的第一行是固定文本任务提示；其余是源代码。目标给出位置（字节偏移 153 对应于 Add 函数的开始）和 go.dev URL，指向 Go 语言风格指南中函数注释违反的确切部分（在这种情况下，通常的做法是用函数名开始注释）。请注意，目标可能包含零个、一个或多个（连接的）位置-URL 对，具体取决于源代码中违规的数量。

3.2 模型训练

图 2 显示了模型训练流程的架构，它由三部分组成。我们将数据集创建分为两个步骤（预处理和管理），因为第一步成本高得多，因为它处理大量数据。预处理步骤的输出与模型的输入/目标表示无关。这种分离通过实现示例表示和其他示例级别调整的快速迭代来提高功能速度。预处理步骤使用容错调度系统，并定期提取相关代码注释以确保新数据随时可用。

3.2.1 大规模预处理。 训练示例从真实代码审查数据创建，但并非所有代码注释都适合模型训练。因此，预处理步骤识别_相关代码注释_ - 包含指向最佳实践文档的 URL 的人工撰写评论。对于每个注释，预处理步骤然后收集相应的源代码和相关元数据，包括注释在源代码中的位置及其创建时间。此步骤的输出是一组相关代码注释，每个注释都包含管理模型训练示例所需的所有数据。

AIware '24, 2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas

Manushree Vijayvergiya 等人

3.2.2 数据集管理。 数据集管理是一个单一的按需处理步骤，实现为 Beam¹ 管道。它根据第 3.1 节中描述的输入/目标格式将每个相关代码注释转换为标准 TensorFlow Example 数据结构。

3.2.3 训练和微调。 管理的示例直接用于模型训练和评估。我们在 TPU 集群上使用 T5X 框架 [22]，每 1000 步存储模型检查点，并使用 Tensorboard 监控训练。

3.3 模型选择

对历史数据的两个内在评估为我们选择模型检查点、置信度阈值和解码策略提供了信息。首先，对验证和测试数据集的评估提供了每文件基础上的精确度和召回率估计。其次，对完整历史代码审查的评估提供了每次代码审查的评论总数估计，表明开发人员与 AutoCommenter 交互的频率。

3.3.1 验证和测试数据集的评估。 我们按时间分割数据集，以确保模型没有在验证和测试数据集中代码评论的未来代码审查快照上进行训练。在我们的数据集中，85% 的文件正好有一个相关代码注释，11% 有两个，4% 有三个或更多。我们将预测定义为_正确_，如果预测的代码位置和 URL 与预期值匹配，无论顺序如何。

回想一下，模型为每个预测提供置信度分数，这引入了另一个参数：如果预测的置信度分数低于某个阈值_𝑡_，则可以抑制预测。我们将_𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 𝑡_定义为置信度分数大于_𝑡_的正确预测数除以置信度分数大于_𝑡_的所有预测数；我们类似地定义_𝑅𝑒𝑐𝑎𝑙𝑙 𝑡_。这些定义使我们能够估计，作为_𝑡_的函数，将向用户显示多少（不）正确的结果。_𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 𝑡_和_𝑅𝑒𝑐𝑎𝑙𝑙 𝑡_用于训练期间的模型检查点比较。

虽然此评估避免了数据泄漏，并允许我们自动评估模型性能，但它有一个局限性：虽然假设给定代码审查快照的人工注释是合理的，但它们并不详尽。换句话说，给定代码审查快照中的代码可能根据多种最佳实践进行改进，但人工审查员没有为所有这些最佳实践发布评论（带 URL）。这可能由于几个原因发生：

• 缺少参考：审查员可能对问题发表评论，但未包含 URL 作为参考。
• 选择性评论：审查员可能对问题发表一次评论，期望作者在整个过程中应用修复。
• 不同的专业知识或重点：审查员可能不熟悉所有最佳实践，或者只是选择不在给定代码审查的上下文中对问题发表评论（例如，仅关注更改的代码）。

虽然我们数据集中的大多数文件只有一个相关注释，但基于手动检查"不正确"预测的轶事证据表明，由于上述原因，通常可能存在多个最佳实践评论。鉴于我们的真实数据不完整，我们的精确度和召回率指标是有噪声的。

1https://beam.apache.org/

因此，我们采用了下一节描述的补充评估，以增加对整体模型性能的信心。

3.3.2 完整历史代码审查的评估。 为了准确衡量实时设置中的潜在评论量，我们使用特定的模型检查点和阈值在一组历史代码审查上评估 AutoCommenter。预测的评论不会追溯发布在代码审查系统中，而是记录在数据库中进行分析。这使我们能够估计预期的发布频率 - 在每文件和每代码审查粒度上。因为开发人员与 AutoCommenter 交互以进行整个代码更改集的代码审查，所以此评估是生产部署之前的重要步骤。作为额外的好处，此步骤允许进一步优化和评估不同用户组、编程语言等的发布频率。

3.4 推理基础设施

AutoCommenter 的核心是一个中央最佳实践分析服务。此服务将一个或多个源文件作为输入进行分析。对于每个文件，它构建模型输入（第 3.1 节），将其编码为标准 TensorFlow Example 数据结构，并查询模型。模型本身由模型服务提供，该服务使用 TensorFlow 的 Example 数据结构作为域不可知的输入输出格式。最后，最佳实践分析服务执行一系列过滤步骤（第 4 节），抑制低质量预测，并返回剩余的预测。

3.5 IDE 和代码审查集成

开发人员以两种方式与 AutoCommenter 的分析服务交互 - 直接通过 IDE 插件，或间接通过代码审查系统。代码审查系统被 Google 的所有开发人员使用，IDE 被几乎所有开发人员使用。

AutoCommenter 的评论在 IDE 中显示为带有蓝色波浪下划线的诊断，跨越相关的代码片段。将鼠标悬停在带下划线的代码上会显示完整评论，其中包含最佳实践的简明摘要，包括指向相关最佳实践文档的可点击链接。这种嵌入式信息消除了开发人员在 IDE 和 Web 浏览器之间切换以了解不熟悉的最佳实践的需要，从而简化了工作流程。由于 IDE 中的评论需要实时生成，我们的目标是亚秒级延迟生成评论。

在代码审查系统中，AutoCommenter 在每次更新后运行（即，在每个新的代码审查快照上），如果检测到任何违规，自动发布评论。自动化工具生成的评论在视觉上与人类生成的评论相似，但具有不同颜色的背景。

图 3 显示了由 AutoCommenter 在代码审查系统中生成和发布的示例评论。请注意点赞和点踩按钮（右侧），作者和审查员可以点击这些按钮，如果他们认为评论特别有用或不有用。另请注意"请修复"按钮（左侧），该按钮对审查员可见。如果单击，将生成一个新评论，表明审查员认为该评论很重要，必须在代码合并到代码库之前解决。这些反馈按钮是代码审查系统中的标准配置，存在于自动化工具生成的所有评论中（例如，[7, 13]），并为工具的用户接受度提供信号。IDE 提供类似的反馈机制。

13 std::pair<int32_t, int32_t> GetMinAndMaxSnippetLength( Automated comment @ w 12 Mar, ar, 19:06 Revisi C++ style guide: de: Structs vs. Tuples--i it may improve i this i code: Prefer to use a 'struct' instead of a pair or a tuple whenever the elements can have meaningful names. While using pairs and tuples can avoid the need to define a custom type, name potentially will almost saving always work be much when clearer_writing_ when code, reading a meaningful code than field 'first', .second', or "std::get<X>*. While C++14's introduction of "std::get<Type> to access a tuple element by type rather than index (when the type is unique) can sometimes partially mitigate this, a field name is usually substantially clearer and more informative than a type. Please fix Was this helpful? (9 GJ 14 EEEconst config::proto::Options& options, 15 gtl::AnySpan<const std::string> allowed languages) ;

0.9 . : : vey Negative : : » _ 0.8 Positive ye :i :i 1 \| 3o : : 1 5 0.7 i: :: 'oD !i rs}a Ss : 2 / = a] 0.6 is 2 io 1 2 ss © _ 3 :o 7DRet Fay2 !1 £cL Yost 2 Er 16 / vo 'Ss ES] Be) 2 1 g 2 go = 3 ! g ic 0.4 = : is 1 2 in i s! 3 0.3\; rh So, a : ; S i ae 2 0.2 :: 1 1 '\ _ :2 Poaot 83 : 1 ae : ~ : 0.1 atte U : : ot ot 9 9? oP A9? a0? a9 40% 400" okv WoRw erat WE2 WA v PO\v cee"v WoRW verat wo!«P Date

AIware '24, 2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas

Manushree Vijayvergiya 等人

4.2 抑制过时的最佳实践

在向大约 3000 名自愿的首批采用者推出 AutoCommenter 后，我们注意到几天内用户提交了大量问题。其中许多对应于单个 URL²，该 URL 描述了与 Python 导入相关的最佳实践。然而，某些类型名称的规范来源在 Python 3.9 中发生了变化，最佳实践在 2022 年初也发生了变化。由于我们的训练数据早于 2022 年，它包含了许多不再适用的最佳实践评论。我们意识到这是一种反复出现的模式：随着语言的发展，或者新库的引入，最佳实践也会发展。缓解该问题的一种方法是过滤掉此类数据（每当规则更改时）并重新训练模型。然而，这既费时又消耗资源：它需要完整的数据再生、模型训练、评估和推出。同时，"过时"的模型需要要么关闭，导致系统停机，要么受影响的预测需要被抑制。否则，系统可能很快失去开发人员的信任。我们选择抑制特定的最佳实践预测，使用条件过滤（匹配源代码上的正则表达式），原因有两个。首先，它可以动态部署并立即应用。其次，它允许对预测进行粒度过滤。

4.3 选定评论的独立评级

经过几个月的早期使用，我们观察到有用率稳定在 54% 左右。为了理解原因，确定改进领域，并为更广泛的部署做准备，我们在 2023 年 4 月进行了一项独立的人类评级研究，分析了约 370 条在首批采用者部署期间收到开发人员反馈的已发布评论样本。

为了收集对评论有用性的不同观点，我们招募了 15 名评级员 - 来自合作团队的开发人员。我们要求他们对收到明确用户反馈的 AutoCommenter 评论进行评级。我们没有向评级员显示原始用户反馈，以避免他们的评估产生偏差。评级员根据链接的最佳实践和周围代码评估每条评论的有用性。我们指示他们关注评论的正确性，还要关注评论对他们作为作者是否可操作（例如，他们是否会解决技术上正确但在特定情况下似乎不值得解决的评论）。鼓励他们对每条评论提供自由形式的反馈。

评级员评估的有用率为 60%，略高于对相同评论的开发人员反馈的 54%，但远低于我们更广泛部署的 80% 的目标。这项研究最有趣的发现是，有明确的无用评论模式。以下是一些示例：

多个主题或复杂主题： 例如，一个 URL 指向一个部分，该部分描述了与 Python linter 交互的多个指南，包括它经常触发的情况以及抑制它的方法。作者可能难以理解发布的评论指的是哪个具体指南以及如何解决它。同样，关于用 C++ 编写好的函数文档的指南是一整页的密集文本。评级员经常注意到，最佳实践（以及 AutoCommenter 的简明摘要）与实际代码之间存在脱节，即使它包含相关违规。

2https://github.com/google/styleguide/blob/gh-pages/pyguide.md#22-imports

高质量摘要的重要性： 评级员经常发现，AutoCommenter 的摘要是通过抓取文档源生成的，有时会丢失，未能充分解释引用的指南与评论/代码的相关性。

主观和可能有争议的主题： 一个例子是在库代码中避免使用标志。标志在库中使用时可能会导致问题，但有些库专门设计为通过标志配置许多功能。此外，遗留代码可能不遵守此指南，审查员也不会强制执行。模型没有学习这些细微差别，有时会在作者向现有库添加新标志时预测违规。

某些指南的系统模型错误： 一个有趣的例子是，当两个函数可以使用相同的参数来实现相同的效果时，C++ 向量的准则提倡使用成员函数_push_back_而不是_emplace_back_。模型已经学会了预测这一点，但它也会在_emplace_back_是合理的情况下，以及当不相关类型有一个名为_push_back_的成员函数时预测它。

正确但低价值的评论： 代码注释中句子末尾缺少句号通常是人类审查员允许的。虽然技术上是正确的，但要求作者回到他们的 IDE 并修复问题可能会提供净负面价值。

评级员研究的见解促成了对 AutoCommenter 的两项更改。首先，评级员研究确定了 17 个不可操作的 URL，它们的抑制使历史有用率从开发人员反馈的 54% 增加到 66%，从评级员反馈的 60% 增加到 74%。我们进一步分析了链接到类似、未评级 URL 的评论，并又抑制了 5 个。其次，我们审查并手动更新了所有频繁发布的 URL 的摘要。总之，这些更改足以使下一阶段部署的目标有用率达到 80%。

4.4 A/B 实验

2023 年 7 月，我们在 A/B 实验的背景下将 AutoCommenter 部署到大约一半的开发人员。我们随机将开发人员分配到实验组（启用 AutoCommenter）和控制组（禁用 AutoCommenter）。我们根据开发人员电子邮件地址的 SHA256 哈希的最后几位进行随机化，并验证了两组在规模和组成方面没有差异，包括任期、资历、编程语言和业务单位的分布。我们还确认，在实验开始之前，实验期间测量的变量在控制组和实验组之间没有差异。实验期间的评论发布频率符合预期（第 4.1 节）。

我们没有检测到以下任何一项的统计显著变化：代码审查的总持续时间、开发人员在代码审查上积极花费的时间、作者和审查员之间的评论-响应迭代次数。然而，我们确实检测到编码速度略有提高。我们推测，减少到文档的上下文切换导致了这种积极影响。我们将更深入的调查留给未来的工作。基于结果，我们得出结论，没有不利影响，并于 2023 年 10 月将 AutoCommenter 部署到所有开发人员。

2 Cc : : g €08 : : of fo}o2 0.6 : :: :: chur ee - Ke) : ven? : o : Pai : © Lot : vu a7 : 2 --7 : : ic ae : F oar bliss —— Automated comments 3 0.0 fac : ::1 -- Human comments (training data) 0 50 100 150 200 250 300 350 URL rank by frequency in automated comments

nm 6d

AIware '24, 2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas

Manushree Vijayvergiya 等人

URL，我们检查了其最佳实践文档，并确定了（1）最佳实践类型（第 1 节）和（2）是否存在或可以轻松构建检测相应违规的 linter。具体来说，三位作者，每个人都有超过 10 年的构建静态分析工具的经验，阅读了文档并独立对 URL 进行了分类。对于最佳实践类型没有分歧，但对于大约 15% 的 URL 是否可以轻松构建 linter 存在分歧。三位作者通过多数投票和讨论解决了这些分歧。分歧源于模糊的最佳实践以及具有多个指南的最佳实践。例如，虽然检查代码文档的存在相对简单，但对合理的例外和内容清晰性的推理可能并不简单。

图 6 显示了 50 个采样 URL 的分布，按类型和是否可以通过 linter 检测违规进行细分。对于这些最佳实践中的 33/50（66%），违规检测超出了传统静态分析的范围。

6 经验教训

基于我们开发和部署 AutoCommenter 的经验，我们总结了几个关键的经验教训：

• 补充传统分析：AutoCommenter 的 LLM 支持方法为人类审查员经常引用的 68% 的最佳实践生成评论。其中许多是传统静态分析的范围之外的。
• 内在评估与实际性能：内在评估和实际性能可能显著分歧：我们的内在评估使用真实人类评论数据集以及最先进的模型架构和训练过程，表明了一个有前途的模型，但我们的外在评估和系统改进对于成功部署至关重要。
• 监控用户接受度至关重要：即使是少数负面用户体验也会侵蚀对自动化系统的信任。持续监控和分析实际反馈对于检测此类实例和确定补救措施至关重要。在 AutoCommenter 的情况下，简单的抑制机制足以在不显著牺牲功效的情况下将用户接受度大幅提高到 80% 以上。

7 相关工作

Johnson [15] 大约 50 年前在 1977 年引入了 C linter。在这 50 年中，产生了大量关于自动化静态分析的研究：Heckman 和 Williams [10] 最近的文献综述确定了 17,571 篇论文。许多研究探讨了开发人员如何与静态分析交互。Johnson 等人 [14] 探讨了开发人员在尝试使用静态分析时面临的挑战。他们的研究结果强调了良好集成到现有开发人员工作流程的重要性以及开发和维护对工具信任的重要性。Vassallo 等人 [27] 探讨了开发人员在不同上下文中如何与静态分析交互，包括编码和代码审查。他们也发现，集成到现有工作流程在开发人员使用工具的意愿中起着重要作用，并且高质量的结果极其重要。Beller 等人 [6] 研究了大量开源项目中静态代码分析的使用。除其他发现外，他们强调自动化分析的使用方式和应如何使用因编程语言而异。

相比之下，使用机器学习进行代码分析是一个相对较新且理解较少的领域。许多近期出版物（例如，Hong 等人 [11]，Li 等人 [16]，Li 等人 [17]，Thongtanunam 等人 [24]，Tufano 等人 [25]，以及 Tufano 等人 [26]）报告了模型评估并提出了自动化代码审查工具。虽然这些模型和审查评论生成任务与本文中呈现的模型非常相似，但评估主要集中在历史数据集上。如第 3.3.1 节所讨论的，仅对历史评论的内在评估有些有限，有时可能无法预测实际性能。Frömmgen 等人 [9] 最近的另一篇出版物呈现了对实时系统的评估，但针对的是相反的任务：从评论创建代码而不是从代码创建评论。

8 结论

验证代码是否遵循最佳实践是现代代码审查流程中的常见任务。虽然一些最佳实践可以使用传统工具（如 linters）自动验证，但许多最佳实践需要经验丰富的开发人员的知识和判断，这需要时间和精力。

本文报告了我们开发、部署和评估 AutoCommenter 的经验，AutoCommenter 是一个 LLM 支持的代码审查助手系统。具体而言，它列出了从任务和模型设计，到内在评估和系统校准，到分阶段推出和最终用户评估的整个过程。

评估结果表明，开发一个功能远超传统工具的端到端系统，同时实现高度的最终用户接受度是可行的。这些结果是部署复杂代码审查助手和自动化代码审查的有希望的第一步。

我们的首要任务是确保积极的开发人员体验，将 AutoCommenter 设计为具有非常高的精确度。虽然召回率不是主要关注点，但我们认识到它的重要性，并计划探索模型和系统架构中的哪些更改可以提高召回率。例如，我们在 2022 年使用的模型在当时是最先进的。然而，它有 2048 个标记的有限上下文窗口，仅足以覆盖大约 200 行代码。当前最先进的模型在训练期间有数十万个标记的上下文窗口，在推理期间有超过一百万个标记的上下文窗口。这一飞跃为新功能和现有功能的显著改进开辟了机会。

9 致谢

这项工作是 Google 核心系统团队与 Google DeepMind 多年合作的结果。我们感谢所有团队成员和领导层的支持和建议，包括 Alberto Elizondo, Alexander Frömmgen, Ballie Sandhu, Chandu Thekkath, Chris Gorgolewski, David Tattersall, Ilya Cherny, Jacob Austin, Katja Grünwedel, Kristóf Molnár, Lera Kharatyan, Luka Rimanić, Madhura Dudhgaonkar, Marc Brockschmidt, Marcus Revaj, Maxim Tabachnyk, Nina Chen, Niranjan Tulpule, Nitya Ramani, Paige Bailey, Pavel Sychev, Pierre-Antoine Manzagol, Quinn Madison, Roger Fleig, Satish Chandra, Savinee Dancs, Stoyan Nikolov, Subhodeep Moitra, 和 Vaibhav Tulsyan。

AIware '24, 2024 年 7 月 15 日至 16 日，巴西 Porto de Galinhas

现代代码审查中的 AI 辅助编码实践评估

参考文献

• [1] 2024. Google Style Guides. https://google.github.io/styleguide/. 访问：2024-03-15。
• [2] 2024. Linux kernel coding style. https://www.kernel.org/doc/html/v4.10/process/ coding-style.html. 访问：2024-03-15。
• [3] 2024. PEP 8 – Style Guide for Python Code. https://peps.python.org/pep-0008/. 访问：2024-03-15。
• [4] 2024. Rust Style Guide. https://doc.rust-lang.org/nightly/style-guide/. 访问：2024-03-15。
• [5] Alberto Bacchelli and Christian Bird. 2013. Expectations, outcomes, and challenges of modern code review. In 2013 35th International Conference on Software Engineering (ICSE) . 712–721. https://doi.org/10.1109/ICSE.2013.6606617
• [6] Moritz Beller, Radjino Bholanath, Shane McIntosh, and Andy Zaidman. 2016. Analyzing the state of static analysis: A large-scale evaluation in open source software. In 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER) , Vol. 1. IEEE, 470–481.
• [7] Zimin Chen, Małgorzata Salawa, Manushree Vijayvergiya, Goran Petrović, Marko Ivanković, and René Just. 2023. MuRS: Mutant Ranking and Suppression using Identifier Templates. In Proceedings of the Symposium on the Foundations of Software Engineering (FSE) . 1798–1808.
• [8] M. E. Fagan. 1976. Design and code inspections to reduce errors in program development. IBM Systems Journal 15, 3 (1976), 182–211. https://doi.org/10.1147/ sj.153.0182
• [9] Alexander Frömmgen, Jacob Austin, Peter Choy, Nimesh Ghelani, Lera Kharatyan, Gabriela Surita, Elena Khrapko, Pascal Lamblin, Pierre-Antoine Manzagol, Marcus Revaj, Maxim Tabachnyk, Daniel Tarlow, Kevin Villela, Daniel Zheng, Satish Chandra, and Petros Maniatis. 2024. Resolving Code Review Comments with Machine Learning. In International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) .
• [10] Sarah Heckman and Laurie Williams. 2011. A systematic literature review of actionable alert identification techniques for automated static code analysis. Information and Software Technology 53, 4 (2011), 363–387. https://doi.org/10. 1016/j.infsof.2010.12.007 Special section: Software Engineering track of the 24th Annual Symposium on Applied Computing.
• [11] Yang Hong, Chakkrit Tantithamthavorn, Patanamon Thongtanunam, and Aldeida Aleti. 2022. Commentfinder: a simpler, faster, more accurate code review comments recommendation. In Proceedings of the Joint Meeting of the European Software Engineering Conference and the Symposium on the Foundations of Software Engineering (ESEC/FSE) . 507–519.
• [12] Marko Ivanković, Goran Petrović, René Just, and Gordon Fraser. 2019. Code Coverage at Google. In Proceedings of the Joint Meeting of the European Software Engineering Conference and the Symposium on the Foundations of Software Engineering (ESEC/FSE) . 955–963.
• [13] Marko Ivanković, Goran Petrović, Yana Kulizhskaya, Mateusz Lewko, Luka Kalinovčić, René Just, and Gordon Fraser. 2024. Productive Coverage: Improving the Actionability of Code Coverage. In International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) .
• [14] Brittany Johnson, Yoonki Song, Emerson Murphy-Hill, and Robert Bowdidge. 2013. Why don't software developers use static analysis tools to find bugs?. In 2013 35th International Conference on Software Engineering (ICSE) . IEEE, 672–681.
• [15] Stephen C Johnson. 1977. Lint, a C program checker . Bell Telephone Laboratories Murray Hill.
• [16] Lingwei Li, Li Yang, Huaxi Jiang, Jun Yan, Tiejian Luo, Zihan Hua, Geng Liang, and Chun Zuo. 2022. Auger: Automatically generating review comments with pre-training models. In Proceedings of the Joint Meeting of the European Software Engineering Conference and the Symposium on the Foundations of Software Engineering (ESEC/FSE) . 1009–1021.
• [17] Zhiyu Li, Shuai Lu, Daya Guo, Nan Duan, Shailesh Jannu, Grant Jenks, Deep Majumder, Jared Green, Alexey Svyatkovskiy, Shengyu Fu, and Neel Sundaresan. 2022. Automating code review activities by large-scale pre-training. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Singapore, Singapore) (ESEC/FSE 2022) . Association for Computing Machinery, New York, NY, USA, 1035–1047. https://doi.org/10.1145/ 3540250.3549081
• [18] Goran Petrović, Marko Ivanković, Gordon Fraser, and René Just. 2023. Please fix this mutant: How do developers resolve mutants surfaced during code review?. In International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) . 150–161.
• [19] Rachel Potvin and Josh Levenberg. 2016. Why Google Stores Billions of Lines of Code in a Single Repository. Communications of the ACM (CACM) 59 (2016), 78–87. http://dl.acm.org/citation.cfm?id=2854146
• [20] Peter Rigby, Brendan Cleary, Frederic Painchaud, Margaret-Anne Storey, and Daniel German. 2012. Contemporary Peer Review in Action: Lessons from Open Source Development. IEEE Software 29, 6 (2012), 56–61. https://doi.org/10.1109/ MS.2012.24
• [21] Peter C. Rigby and Christian Bird. 2013. Convergent contemporary software peer review practices. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (Saint Petersburg, Russia) (ESEC/FSE 2013) . Association for Computing Machinery, New York, NY, USA, 202–212. https://doi.org/10.1145/ 2491411.2491444
• [22] Adam Roberts, Hyung Won Chung, Gaurav Mishra, Anselm Levskaya, James Bradbury, Daniel Andor, Sharan Narang, Brian Lester, Colin Gaffney, Afroz Mohiuddin, et al. 2023. Scaling up models and data with t5x and seqio. Journal of Machine Learning Research 24, 377 (2023), 1–8.
• [23] Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli. 2018. Modern Code Review: A Case Study at Google. In International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) . 181–190.
• [24] Patanamon Thongtanunam, Chanathip Pornprasit, and Chakkrit Tantithamthavorn. 2022. Autotransform: Automated code transformation to support modern code review process. In Proceedings of the International Conference on Software Engineering (ICSE) . 237–248.
• [25] Rosalia Tufano, Ozren Dabić, Antonio Mastropaolo, Matteo Ciniselli, and Gabriele Bavota. 2024. Code Review Automation: Strengths and Weaknesses of the State of the Art. IEEE Transactions on Software Engineering (TSE) (2024).
• [26] Rosalia Tufano, Simone Masiero, Antonio Mastropaolo, Luca Pascarella, Denys Poshyvanyk, and Gabriele Bavota. 2022. Using pre-trained models to boost code review automation. In Proceedings of the International Conference on Software Engineering (ICSE) . 2291–2302.
• [27] Carmine Vassallo, Sebastiano Panichella, Fabio Palomba, Sebastian Proksch, Harald C Gall, and Andy Zaidman. 2020. How developers engage with static analysis tools in different contexts. Empirical Software Engineering 25 (2020), 1419–1457.
• [28] T. Winters, T. Manshreck, and H. Wright. 2020. Software Engineering at Google: Lessons Learned from Programming Over Time . O'Reilly Media. https://books. google.ch/books?id=TyIrywEACAAJ

收到 2024-04-05；接受 2024-05-04