Page 201 - 《软件学报》2024年第6期

杨岚心 等: 基于多标签学习的代码评审意见质量评价 2777

属性来综合评价其质量等级 (优/良/中/差), 旨在缓解实施评价时可能面临的争议.
(2) 提出了一种基于多标签学习的代码评审意见质量评价方法. 该方法提供了可解释的、自动化的质量评价,
旨在帮助规范和提升代码评审质量.
(3) 提供了若干建模经验, 如针对代码评审意见的标注和校验等, 旨在帮助那些受代码评审困扰的软件组织更
好地实施本文提出的方法.
本文第 1 节介绍背景和相关工作. 第 2 节介绍研究目标和科学挑战. 第 3 节介绍本文提出的基于多标签学习
的代码评审意见质量评价方法. 第 4 节报告实验设计与结果分析. 第 5 节讨论与代码评审意见标签相关的经验.
第 6 节讨论实验的效度威胁. 最后, 第 7 节总结全文并提出未来工作方向.
1 背景和相关工作

1.1 代码评审
代码评审指通过阅读源代码以检查其是否实现预定义功能和满足质量要求的软件工程实践 [1] . 与其他软件质
量保证活动相比, 代码评审长期以来缺少系统化理论指导和智能工具支持, 其质量更多依赖于代码作者和评审者

的技能、经验、参与和投入程度等 [24,25] . 因此, 代码评审一方面发挥着质量保证、知识分享等作用; 另一方面又存
在着效率低、质量差等挑战 [18,19] . 近年来, 越来越多的软件组织开始重视代码评审, 并逐步建立和完善正式的代码
评审指南. 作为 Google 工程实践文档的重要组成部分之一, 其代码评审指南 (https://google.github.io/eng-
practices/review/) 由 (1) 代码评审者指南和 (2) 代码作者指南两部分组成. 其中, 前者包括评审标准/规范、关注重
点、如何书写评审意见和处理争议等; 后者包括如何准备评审和如何处理评审意见等. 代码托管平台 GitLab 不仅
提供了方便的代码评审支持工具, 而且提供了详尽的评审指南 (https://docs.gitlab.com/ee/development/code_
review.html), 包括评审流程、检查表、不同角色 (代码作者、评审者和项目管理者) 职责和最佳实践等. 此外, 相
当多的研究工作 [26−28] 旨在通过推荐评审者来提升代码评审质量.
1.2 代码评审意见挖掘
代码评审意见挖掘作为代码评审分析、评价和改进的重要证据支持, 近年来受到了来自研究社区和业界越来
越多的关注. Li 等人 [29] 发现开源软件社区中的代码评审意见按照其作用可以归纳为 4 大类, 分别是“更正”“决策”
“管理”和“沟通”. 其中, 每一大类包含 2–3 个小类, 如“决策”又可细分为“接受”“拒绝”和“疑问”. 在 Li 等人的模型
中, 开源软件社区中的代码评审意见共被细分为 11 小类. Bosu 等人 [10] 发现评审意见关注广泛的内容, 包括“文档”
“组织”“逻辑”“资源”“缺陷”和“验证”等 13 类. Hasan 等人 [20] 总结了评审意见的 18 类主要关注点. 评审意见在关注
缺陷的同时也经常传递出评审者的情绪. Ortu 等人 [30] 发现 Jira 社区中, 在评审意见中传递负面情绪的评审者通常
需要花费更长的时间来修复缺陷. El Asri 等人 [15] 指出开源软件社区中: (1) 评审者经常表达积极的或消极的情绪;
(2) 各类别情绪的评审意见的比例在核心评审者和边缘评审者之间存在明显差异; (3) 边缘评审者在成长为核心评
审者的过程中, 其评审意见的情绪通常是中性的; (4) 表达消极情绪的评审者通常会花费更长的时间完成评审; (5) 表
达消极情绪的评审者通常会长时间地持续参与到项目维护当中.
关于代码评审意见质量评价, 仅有的少数研究均将其形式化为一个判断“有用性”的二分类问题. Bosu 等人 [10]
调研了 Microsoft 开发者关于评审意见有用性的看法, 结果表明: (1) “有用”的评审意见通常指出功能性缺陷、提
供与验证相关的指导、(对新人而言) 编码规范和可利用的工具等; (2) “部分有用”, 即在受访者中未达成一致认可
的评审意见通常指出注释、风格、命名等问题, 或是建议代码作者寻求替代实现方案; (3) “无用”的评审意见通常
未指出任何缺陷, 相反地, 而是提出疑问、表示赞赏、要求在未来做出改进等. 然而, Bosu 等人并未基于上述经验
构建预测模型. Bosu 等人注意到“有用”的评审意见通常会触发其相邻代码片段的针对性修改 (该类型评审意见被
称为“change trigger”). 因此, 在 Bosu 等人构建的决策树模型中, “change trigger”被设置为评价意见有用性的核心
标准, 即被设置为决策树的第一层条件判断. 其他层的条件判断 (标准) 还包括“评审意见数量”“评审次数”和“情感
倾向”等. Bosu 等人的评价方法属于“离线评价”, 即必须依赖代码经过评审后的变更状态. Rahman 等人 [22] 同样将
“change trigger”作为评价评审意见有用性的核心标准. 为了实现“实时评价”, Rahman 等人构建了若干预测模型. 这