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

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

2.2 研究目标
针对代码评审意见质量评价任务, 本文旨在实现以下两个研究目标.
● 目标 1: 可解释性评价
本文首先期望提出一个可解释的、具有指导性的代码评审意见质量评价方法. 具体而言, 提出的方法不应该仅局
限于给出评价结果 (质量等级), 更重要的是, 告诉评审者什么样的意见是低质量的和什么样的意见是高质量的; 否则,
不透明的质量评价可能会引发信任危机等负面作用. 本文期望提出的方法能起到规范和引导代码评审意见书写的作用.
● 目标 2: 自动化评价
代码评审意见在表现形式和内容上具有广泛的多样性和复杂性. 人工评价一方面效率普遍非常低, 另一方面
容易出现评价结果不一致的情况. 不同的人对同一条意见的评价结果可能不一致, 同一人在不同时候对同一条意
见的评价结果也可能不一致. 此外, 人工评价还会出现误解和偏见等现象, 容易引发信任危机等负面作用. 因此本
文的另一关键研究目标是自动化评价过程.
2.3 科学挑战
质量属性(4)
实现两个研究目标需要重点解决以下两个科学挑战.
● 挑战 1: 质量评价标准
本文通过分析大量的代码评审意见实例发现, 相当一部分的评审意见, 尤其是那些提出可选方案、提出未来
改进建议或者提出疑问的评审意见通常不会立即触发代码变更. 如果将触发代码变更作为评审意见质量唯一的评
价标准, 势必会引起广泛的争议. 许多受访的软件工程师表示: “几乎不存在完全没有用的评审意见. 即使是意见仅
为一个问号, 至少说明该处代码可读性差, 不利于项目维护; 即使是一个“OK”, 至少说明该处代码变更得到了确
认”. 另一方面, 设想将评审意见长度、是否包含代码元素、是否包含关键字词和评审者信息等作为表示原始评审
意见的特征, 此时这些特征也可被视为“评价标准”. 即使自动化方法能够实现相当准确的预测效果, 其也很难被广
泛接受. 例如, 很难说服评审者其意见质量低是因为意见中未包含代码元素或关键术语. 否则, 评审意见将充斥大
量的“无用”信息, 即评审者有意识地在意见中加入代码元素、关键字词等, 而不论其是否必要.
● 挑战 2: 质量评价模型
Efstathiou 等人 [31] 指出代码评审意见具有丰富的语言学特征, 例如传递“因果”“转折”“示例”和“假设”等. 表 1
中展示的实例更形象地体现了评审意见的多样性和复杂性. 典型地, (1) 词法层面: 自然语言和程序语言/代码元素
混用, 如 C9、C10; 软件工程行业术语, 如 C6、C8. (2) 语法层面: 陈述, 如 C3; 疑问, 如 C5; 祈使, 如 C9. (3) 语义/语
用层面: 评价, 如 C2; 建议, 如 C6; 解释, 如 C10. 另外, 评审意见还经常包含指代, 如 C1; 和传递情绪, 如 C7. 综合
起来, 这些因素给代码评审意见质量评价任务建模带来了巨大挑战: 如何屏蔽评审意见在语言表达形式上的多样
性和复杂性, 直接面向更具有规范和指导作用的目标, 构建可解释的、自动化的评价 (预测) 模型?

3 代码评审意见质量评价方法

支持本文提出的代码评审意见质量评价方法的关键研究方法和研究过程如图 2 所示.

正式文件 (2) 系统文献综述 (2) 原始研究(182) 获益(22) ็ᅞ(35)
数据三角论证 概念模型
可解释 多标签
意见实例 映射规则(16) 学习
代码评审意见 质量等级
质量评价
自动化 自然语言处理 文本分类模型 自动化模型
任务 目标 研究方法 提出方法 结果

图 2 本文的研究方法和研究过程