Page 36 - 《软件学报》2021年第12期
P. 36
3700 Journal of Software 软件学报 Vol.32, No.12, December 2021
请求.这些提交了贡献请求的开发人员被称为改动者;
(2) 这种贡献请求是公开的,任何人都可以对贡献请求发表评论.发表评论的人员被称作评论者;
(3) 决策者是可以评审代码、修改项目代码库的核心开发人员.决策者对贡献请求进行检查,并且可以参
考评论里的意见,对贡献请求的质量进行评估.如果通过,则这段代码可以提交到源代码.在评审结束
后,决策者关闭贡献请求.
提交
贡献请求
决策者
改动者 接受,合并
评审
发表
评论
拒绝 源代码库
源代码库 评论者
关闭
Fig.1 GitHub review process
图 1 GitHub 评审流程
从 Github 的评审流程可以看出:代码评审能够对提交的代码进行评估和改进,发现提交代码的缺陷.因此,
代码评审对软件质量有着直接的影响.研究代码评审过程,能够更好地管理开源软件质量,减少软件缺陷.以往
的研究 [2,3] 都没有考虑评审过程中决策者的作用,然而在评审过程中,决策者是代码评审的关键人物,只有经过
决策者审核通过的代码才能加入到源代码库里.因此,本文的开源社区评审过程度量体系会考虑决策者因素.
2 相关研究
[2]
为了解软件开发情况,研究人员提出了过程度量方法.首先,Bird 等人 提出了一种基于软件开发的过程度
量体系,通过计算开发人员在文件内编写的代码更改的比例,计算文件内开发人员的代码贡献量,来度量开发人
员的软件开发过程.然后,根据过程度量体系的指标分析开发过程与软件缺陷的关系.然而,他们的工作只针对
[3]
了开发人员在软件开发过程中的表现,并没有考虑评审过程对于软件缺陷的影响.其次,Thongtanunam 等人 研
究了 QT 和 OpenStack 平台里改动者和评论者在评审过程中的贡献与分布.他们发现:许多评论者在传统指标里
被定义为次要贡献者,但是在考虑了评论因素的指标里却被定义为主要贡献者.在无缺陷的文件里,有着相当大
比例的开发者在传统指标里的贡献量比较低,而在引入评论因素的指标里贡献量比较高.他们的研究表明:传统
的贡献量指标会忽略评论贡献,然而无缺陷的软件却拥有更多的高评论贡献量开发人员,说明传统的贡献量指
标不足够.但是 Thongtanunam 等人只计算了评论者和改动者对于软件缺陷的影响,缺乏考虑评审过程的重要角
色决策者.在开源软件开发过程中,决策者发挥重要作用,决定代码改动是否能否集成到开源项目.现有文献 [2,3]
缺乏考虑决策者,难以充分度量评审过程.本文引入决策者因素,分析度量指标与软件缺陷数量的关系.
贡献请求的代码评审近年来得到了广泛的关注.首先,一些学者研究贡献请求的决策者或者评论者推荐方
法.莫纳什大学夏鑫等人提出了一种结合文件路径和文本描述的决策者推荐方法 [13] .Kim 等人提出了基于主题
模型的决策者推荐方法.Thongtanunam 等人提出了基于文件路径的决策者推荐方法 [14] .国防科技大学的余跃、
王怀民等人分析了开源软件平台的历史数据,建立了评论关系网络,对贡献请求推荐合适的评论者 [15−17] .中国科
学院的卢松等人提出了基于时间和影响力因子的评论者推荐方法 [18] .其次,一些研究人员对大众贡献评审结果
展开研究.Weigerber 等人发现,修改量小的代码更容易通过评审 [19] .Bosu 等人发现,项目核心人员提交的代码质
量更高,更容易通过评审 [20] .Gousios 等人提出一种基于随机森林的贡献结果预测方法 [21] .Tsay 等人结合社交因
素和技术因素预测评审结果 [22] .虽然这些论文研究问题和本文不同,但是都关注代码评审的贡献请求,研究思路