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

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

对于评审人推荐的贡献,发现 3 个目标缺一不可,其中,约定时间内的响应概率目标对于人员推荐的贡献最大.
本文贡献在于:
1) 我们基于真实开源项目数据分析了当前代码评审响应时间的现状,提出了响应时间约束的代码评审
人推荐问题.
2) 我们提出了基于多目标优化的代码评审人推荐算法,可以最大化代码评审人经验、最大化在约定时
间内的响应概率、最大化人员最近时间内的活跃性.
3) 我们在 GitHub 的 6 个大型项目评估了方法的效果,并得到了很好结果.
本文第 1 节进行问题分析.第 2 节提出基于多目标优化的代码评审人推荐算法.第 3 节和第 4 节给出相关
实验的设计方法和实验结果分析.第 5 节作进一步讨论.第 6 节回顾代码评审人推荐的相关研究工作.最后,在第
7 节进行总结.

1 问题分析
本节基于真实的开源项目数据,分析当前代码评审响应时间的现状以及代码评审的人员属性.

1.1 合并请求响应时间分析
我们基于 GitHubd 的 6 个流行的开源项目(详见第 3.3 节),对历史合并请求的响应时间进行了统计,结果见
表 1.
Table 1 Pull request response time
表 1 合并请求响应时间
响应时间 响应时间 响应时间 响应时间 响应时间 响应时间
Project
大于 2h 大于 4h 大于 8h 大于 16h 大于 24h 大于 72h
Facebook/react 58.9% 51.7% 44.2% 35.4% 29.8% 20.2%
tensorflow/tensorflow 79.8% 72.8% 63.8% 52.7% 46.3% 32.1%
twbs/bootstrap 78.9% 68.5% 56.5% 44.4% 40.0% 26.8%
ohmyzsh/ohmyzsh 89.6% 85.9% 81.5% 75.8% 68.4% 63.2%
flutter/flutter 48.0% 42.3% 37.0% 30.4% 24.0% 15.3%
electron/electron 77.8% 69.8% 58.3% 44.0% 36.9% 20.7%
6 个项目中,平均有 15.3%~63.2%的合并请求在 72h 内没有响应,24%~68.4%的合并请求在 24h 内没有响应.
其中,flutter/flutter 是合并请求响应时间最快的项目,有 52%的合并请求在 2h 内得到响应.而 ohmyzsh/ohmyzsh
是合并请求响应时间最慢的项目,超过 60%的合并请求在 24h 内不能得到回复.进一步地,我们统计了
flutter/flutter 和 ohmyzsh/ohmyzsh 两个项目在 2015 年~2019 年中每年 3 月 1 日的文件个数(NOF)和代码行数
(LOC),见表 2.flutter/flutter 代码规模增长速度明显领先于 ohmyzsh/ohmyzsh.其在 2018 年 3 月~2019 年 3 月代
码规模增长了近 1 倍(33 万行代码增长至近 60 万行代码),而 ohmyzsh/ohmyzsh 在 5 年时间内代码规模增长不
足 1 倍(1.7 万行增长至 2.9 万行).
Table 2 Code size in flutter and ohmyzsh
表 2 Flutter 与 ohmyzsh 代码规模
2015.3 2016.3 2017.3 2018.3 2019.3
Project
NOF LOC NOF LOC NOF LOC NOF LOC NOF LOC
flutter/flutter 30 5 508 598 93 921 1 105 197 776 1 572 331 626 2235 599 059
ohmyzsh/ohmyzsh 244 17 518 283 21 676 356 25 881 381 26 591 476 29 566
根据谷歌工程实践文档,代码评审最长需要在一个工作日进行反馈 [15] .以上数据和分析说明,在开源社区的
代码评审实践中,存在很多的合并请求不能及时得到响应的情况.这种情况存在的原因有很多,例如,由于每日
提交的合并请求数量过多,导致部分请求难以得到及时处理 [16] ,像 flutter/flutter 项目平均每周接收到 85 个合并
请求;再如,由于不知道谁是合适的代码评审人,使得合并请求停留在评审人分派阶段,没有在预期的时间内处
[5]
理 ;或者即使已经分派给某个代码评审人后,由于不合适的分派导致的评审时间过长,例如评审人经验不匹