Page 58 - 《软件学报》2021年第11期

3384 Journal of Software 软件学报 Vol.32, No.11, November 2021

值,t thres 取值 7d、15d 和 30d 时,Top-3 准确率小幅下降,降幅小于 5%.我们认为,一般来说,当 t thres 设置较大值时,
能够潜在地将更多可能的人员包含进来,但同时也引入噪声,可能会影响推荐效果;而当 t thres 设置较小值时,能够
过滤掉噪声对于推荐效果的影响,得到较好的推荐效果.对于 6 个项目中贡献者活跃性最小的 ohmyzsh/
ohmyzsh,较长时间的活跃性时间范围 t thres 反而能够更加准确地帮助我们推荐合适的代码评审人.

5 讨 论

特定算法的性能因项目而异.如表 3 和表 4 所示,MOC2R 在不同的项目中具有不同的 Top-k 准确度和不同
的 MRR 表现,其他算法也是如此.我们仔细地分析了 6 个开源项目的数据和其在 GitHub 上的组织管理方式,除
平均响应时间最慢的 ohmyzsh/ohmyzsh 项目外,其他 5 个开源项目均配置了 Facebook 的机器人 Robot
(https://github.com/facebookarchive/mention-bot),项目中所有的合并请求都会在第一时间被 Robot 进行统一处
理,分配一个或多个标签进行分类,比如缺陷、改进、新特性、新版本等标签.并且在执行了自动化测试和静态
检查的项目中,Robot 还会根据自动化测试与静态检查结果判断是否提醒核心开发人员关注该合并请求状态.
在此基础上,我们对 flutter/flutter 项目进行了统计.该项目未使用 Robot 预处理合并请求之前,其合并请求的平均
最快响应时间约为 7.5h;而在使用了 Robot 之后,最近一年的合并请求的平均最快响应时间保持在 4h 以
内.Robot 的使用,可以帮助贡献者和核心开发人员更好地理解合并请求,并帮助他们选择要查看的合并请求,缩
短了响应时间.但现有的 Robot 背后的机制是基于贡献者提交的变更代码行寻找潜在的评审人,如果 Robot 可以
使用本文提出的 MOC2R 方法自动为合并请求推荐评审人,那么对提升代码评审效率、提高开源社区的活跃性
将会起到很好的促进作用.
另一方面,代码评审人推荐准确率越高,并不代表推荐的评审人越能够找到更多的问题.针对代码评审质量
的判别方法、判断依据的相关研究还比较少.因为我们进行代码评审的直接目的还是希望能够进一步提升软件
产品的质量,那么如何评估一次代码评审做的好不好、什么样的代码评审人在评审过程中能够发现更多的问
题,也将会成为我们下一个阶段的研究方向.

6 相关工作

近年来,国内外出现了许多关于代码评审人推荐的研究和算法.根据它们考虑的主要特征和用于推荐代码
评审人的主要技术,我们将其分为 4 组:i) 启发式方法;ii) 基于机器学习的方法;iii) 基于社交网络的方法;iv) 混
合方法.
6.1 启发式方法
传统的推荐方法分析以往的提交和评审信息,如文件修改历史记录、文件路径历史信息、代码行修改历史、
历史评审中评审人评论次数等,并基于评审人的修改经验或评审经验来寻找最相关的代码评审人员.主要的算
法有 ReviewBot、RevFinder、WRC 和 CORRECT 等.ReviewBot 是 Balachandrany 于 2013 年提出并实现的一
[6]
款工具 ,被广泛认为是最早的代码评审人推荐研究之一.其推荐依据是基于如下假设:在合并请求中更改的代
码行,应该由先前讨论或修改过相同代码行的代码评审人来评审.Thongtanunam 等人于 2015 年提出了
[5]
ReviewFinder ,也是目前被广泛引用的推荐算法.该方法采用的是合并请求中包含的文件路径相似度的计算与
[7]
排序的方法 FPS(file path similarity).Hannebauer 等人于 2016 年提出了 FPS 的优化算法 WRC .该方法在 FPS
的基础上增加了前置步骤,通过加权评论数的方式将评审经验引入 FPS 的计算过程中,以便得到更精确的推荐
结果.Rahman 等人于 2016 年提出了代码评审人推荐算法 CORRECT [16] ,使用过相似技术或引用过相似的代码
库的评审人是合适的候补代码评审人.
6.2 基于机器学习和信息检索的方法

这组方法使用不同的机器学习算法或者信息检索方法来推荐代码评审人员,它们不同于前一组的主要区
[8]
别在于,它们首先需要建立一个基于训练集的模型.“Pred.Rev.”是 Jeoung 等人于 2009 年提出来的 ,基于补丁元