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

胡渊喆 等:响应时间约束的代码评审人推荐 3377

员最近时间内的活跃性为优化目标,将代码评审人推荐问题建模成多目标优化问题,建立基于多目标优化的推
荐模型.MOC2R 方法框架如图 4 所示.

Fig.4 MOC2R method framework
图 4 MOC2R 方法框架
第 2.1 节定义了代码评审相关的基本元素.由于多目标优化方法最重要的是优化目标的度量,第 2.2 节给出
了优化目标的度量方法,第 2.3 节对 MOC2R 中如何使用多目标优化进行了介绍.
2.1 基本元素和定义

图 5 给出了评审历史、候选评审人、新代码评审的示意图.

Fig.5 Diagram for code review
图 5 代码评审示意图

在 GitHub 的开源项目中,贡献者(contributor)每一次提交代码都需要创建一个合并请求(pull request),每一
个合并请求的创建,就代表需要进行一次代码评审(code review).任何一个在合并请求中添加了评论信息
(comment)的贡献者,我们都视为是这次代码评审的评审人员(reviewer).
代码评审历史是指过去已经完成的一系列代码评审的合集,表示为 R={r 1 ,r 2 ,…,r n },其中,r i 表示已经完成的
第 i 次代码评审.
对于一次已完成的代码评审 r,包括其创建时间、一组被评审的变更文件以及所有参加过这次代码评审的
评审人,表示为 r={createTime(r),Files(r),Reviewer(r)},其中,createTime(r)表示代码评审 r 的创建时间,Files(r)=
{f 1 ,f 2 ,…,f n }表示被评审的变更文件列表,Reviewer(r)={(w 1 ,t 1 ),(w 2 ,t 2 ),…,(w n ,t n )}表示参加评审的评审人列表,w i 表
示代码评审人,t i 表示该评审人参加本次代码评审并留下第 1 条评论的时间.某个代码评审人可能会在一个代码
评审中有多次评论,本文只记录第 1 条评论的时间用于目标的建模.对于后续评论的发生时间对于建模和推荐