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

2778 软件学报 2024 年第 35 卷第 6 期

些模型不依赖代码经过评审后的变更状态, 而是基于评审意见的文本特征 (如“可读性”“停用词比例”和“代码元素
比例”等) 和评审者相关特征 (如“评审次数”等). 基于上述研究经验, Hasan 等人 [20] 调研了 Samsung 开发者关于代
码评审意见是否有用的看法, 结果表明: (1) “有用”的评审意见通常指出缺陷、逻辑错误、冗余代码、帮助提升设
计和可读性等; (2) “部分有用”的评审意见通常提出疑问、表示赞赏、要求改进文档等; (3) “无用”的评审意见通
常指出能够被静态分析工具发现的问题、讨论已经被解决的问题、误解代码意图等. 同样地, 为了实现“实时评
价”, Hasan 等人基于代码评审意见的文本特征、评审上下文特性和评审者相关特征构建了若干预测模型.
总结来说, 目前尚无被一致认可的代码评审意见质量评价标准. 研究者在构建预测模型时, 通常将是否“触发
代码变更”作为评价评审意见有用性的标准. 该评价方式依赖代码作者对评审意见的接受与否, 受人的主观因素影
响较大, 因此其有效性仍存在争议. 本文针对上述问题开展了若干实证研究, 在此基础上提出了一种基于多标签学
习的代码评审意见质量评价方法, 现将关键研究方法、过程和结果报告如下.
2 准备工作

2.1 实例分析
Git 版本控制系统提供了方便的代码变更比对功能 (通常以不同颜色作为区分), 评审者可以更加专注代码变
更, 而无需逐行检视提交的所有代码. 评审者一旦发现问题, 即可选中任意行代码并提出针对性的意见. 图 1 展示
了一个典型的代码评审实例 (https://gitee.com/mindspore/mindspore/pulls/30478). 评审者“zhangxx”针对代码作者
“徐 xx”提交的代码合入请求中的新增加 (+) 的行 (366) 提出了评审和修改意见“这里建议直接用 auto iter =
counter_handlers_.find(name); if (iter == end || !(iter->first_count_handler)){}减少查询次数, iter 可以重复使用”, 代码
作者接受了该意见并回复“应该这样做, 这几天 pclint 清理时候带上”. 事实上, 并非每条评审意见都会被代码作者
回复和触发代码变更. 表 1 中展示了更多、更复杂的代码评审意见实例.
C4

图 1 代码评审实例

表 1 代码评审意见实例

ID 代码评审意见
C1 同上
C2 逻辑不对
C3 魔鬼数字
info日志打印太多
C5 −1具体含义是什么?
C6 冗余代码, 抽成一个函数
C7 什么鬼啊!!!英文是不是有些太不通顺了
C8 是否有emui标准控件? 有的话用标准控件
C9 MAXBUFLENGTH改为MAX_BUF_LENGTH
这样写不对, 假设第1个关闭时抛异常了, 会导致2, 3不去关闭. 每个需要独立的try-catch; 其中, 文件的输入输出流可
C10
以直接使用IoUtils里的方法