代码评审记录_CORRECT：为Github中的Vendasta项目推荐代码评审人

摘要

在软件开发的早期阶段，同级代码评审可以找出常见的编码规范错误和简单的逻辑错误，从而降低总体的开发成本。然而，在GitHub中，为一个提交的PR识别一个合适的代码评审人可以说是一个挑战，因为判定评审人的可靠信息通常是不容易得到的。本文提出一个推荐代码评审人的工具CORRECT，它不仅考虑了某一开发者的相关跨项目工作经验(如，外部库经验)，而且考虑了他在某一特定技术领域的经验(如，谷歌搜索引擎)，通过这些与PR相关的经验来判定该开发者是否是合适的代码评审人。我们使用客户机-服务器的架构来设计该工具，然后将解决方案打包为谷歌Chrome插件。一旦开发人员在GitHub上发起一个新的PR，我们的工具就会自动分析该请求，挖掘两个方面的相关历史，然后在浏览器的上下文中为该请求返回一个排好序的合适代码评审人列表。

Demo：https://www.youtube.com/watch?v=rXU1wTD6QQ0

关键词

代码评审人推荐，跨项目经验，专业技术经验，GitHub，拉取请求(即PR)

1 引言

同行代码评审对于查找违反编码规范的行为或执行简单的逻辑验证是非常有效的[1,4,12]。它还有助于在开发的早期阶段识别源代码问题(即漏洞)，从而降低软件项目的总体成本[1,4]。GitHub分别通过PR机制和代码审查来促进分布式和协作式软件开发。在GitHub中，开发人员复制已有的存储库(即项目)到本地，并对感兴趣的模块进行开发，然后利用PR机制[6]将更改后的文件提交到最初的存储库。在提交PR的过程中，开发人员需要选择一个或多个代码评审人员，他们会在接受变更之前仔细地审阅代码。然而，为一个PR选择合适的评审人是面临的一个重大挑战[2]，到目前为止，GitHub还没有为此提供任何支持。关于评审者专业技能的可靠信息通常是不容易获得的，需要从代码库中仔细挖掘。因此，识别合适评审员的任务对于新开发人员来说更加具有挑战性和耗时，因为他们既不熟悉代码库，也不了解数百名潜在评审员的技能。这样的挑战不仅在开源开发中很普遍，在工业环境中也很普遍，如Vendasta公司努力在商业软件开发中保持代码质量，并鼓励开发人员以同行代码评审的形式进行协作。

现有的一些研究通过分析过去的代码评审历史(例如，行变更历史[2]，评审注释[16,18])、项目目录结构[13,14]和开发人员协作网络[18]来推荐代码评审人员。简而言之，现有的研究主要依赖于开发人员(即潜在的评审人)在某些项目的开发历史，以及他与其他开发人员的合作历史，来确定他擅长的领域。但是，没有研究考虑开发人员的跨项目经验或在各种专业技术方面的经验，因此在应对某些挑战方面存在不足。首先，在行业中，软件开发人员经常重用以前自己开发的软件组件(例如，库)，以实现更高的成本效益和更快的开发速度。因此，他们的贡献分散在组织的代码存储库中的不同项目中。这些贡献很大程度上反映了他们的经验。但现有的关于代码评审者推荐的研究完全忽略了开发者专长判定方面的信息，而且他们仅仅是基于特定项目中的贡献细节。其次，软件项目的底层工具和技术正在迅速变化，当前项目通常涉及不同的专业和前沿技术，如map- reduce、任务队列、urlfetch、memcache和pipeline。因此，PR的代码审查人员应该具有这些技术方面的专业知识。然而，挖掘已更改文件的修订历史或挖掘开发人员协作历史，就如现有研究所做的那样，都不足以确保这一点。因此，一种能够分析相关跨项目经验和开发人员与PR相关的特定技术经验的技术的提出，很可能会克服上述挑战。

本文为GitHub上的PR提供了一个新的代码评审人推荐工具CORRECT，该工具通过分析开发人员过去的工作经验，包括外部软件库的开发经验和PR所使用的特定技术，来确定开发人员是否有资格作为某个PR的代码评审人。对外部库的引用(即项目引入外部的软件单元)通常暗示了某个开发者使用这些库的开发经验，称之为跨项目经验。本文的关键思想-如果过去的PR使用了与当前PR相似的外部软件库或类似的专业技术，那么过去的请求与当前请求是相似的，于是它的评审人也是当前PR的代码审查的潜在候选人。

我们首先使用静态分析从当前的PR中挖掘外部库和技术信息，再从最近的提交PR集合中识别相关的(或类似的)请求在库和技术方面的相似性。然后，我们将每个相关请求的相似度评分传给相应的代码评审人员，作为与当前请求在外部库和专门技术中相似程度的参考值。因此，针对所有相关的请求为每个候选对象累积分数，最后该工具返回一个排序的代码评审者列表。该推荐系统采用了客户端-服务器架构，其中客户端模块打包为谷歌Chrome插件(即作为Vendasta技术的某一功能插件)，服务器模块作为web服务被托管。综上所述，本文提出的工具提供了以下功能，以帮助Vendasta软件开发人员选择合适的代码评审员：

(a)自动分析给定PR的技术细节，并为其代码评审推荐合适的审查人员的排序列表；

(b)自动获取和利用开发人员的两个方面的专业经验，分别是跨项目经验和专业技术经验，以确定他作为代码评审员的专业知识或资格；

(c)为使用开放认证的GitHub开发人员提供定制推荐；

(d)通过一个谷歌Chrome插件完善了GitHub现有的PR提交工具；

(e)提供一个客户-服务器架构，以无缝集成我们的代码审查推荐服务。

虽然本文关注的是代码评审员推荐的工具实现，但我们请读者参阅详见原始文献[11]。

2 现代代码评审(MCR)

代码评审是指对代码中潜在的缺陷(如，逻辑错误)和质量问题(如，不符合编码规范)进行的手工评估[3]。近年来，代码评审得到了各种工具的帮助，这些工具与传统的评审技术相比，不那么正式，但更受欢迎[2]。这样的代码评审称为现代代码评审(MCR)[3]。它被商业组织(如，微软)和开源社区(如，Android，LibreOffice)广泛采用。例如，开发人员jrans-va(即图1中的绿框)在PR#1745提交期间向开发团队cashlab(即图1中的红框)请求代码评审。该请求包含与五个更改的源文件相关联的两次提交。来自该开发团队的两个开发人员cgooding-va和cberenik-va(即图1中的蓝框)分析提交的PR，进行代码评审，然后使用注释来传达他们的反馈(如橘黄色框中所示)。尽管有了静态分析工具[2]的帮助，有效的代码评审仍然是一个挑战，并且为代码评审识别合适的评审者更具有挑战性。到目前为止，评审员的选择和代码评审都是在GitHub上手动执行的。本文提出的工具推荐合适的开发人员(例如cgooding-va)在GitHub执行这样的代码评审任务(如图1所示)。

3 CORRECT：提出的工具

图2显示了包含浏览器的工具栏(d)，推荐面板(e)-(f)，PR主面板(g)的CORRECT用户界面。本节讨论该工具提供的不同技术特性。

(1)用例：CORRECT为基于协同软件开发的两个PR用例提供了自动推荐支持，具体如下：

A.提交一个新的PR: 某用户在提交一个新的PR时，将自己的项目分支(如图2-(a)中的AA-2453)与基库(如图2-(a)中的develop)进行对比，然后寻找潜在的代码评审者。我们的工具使用静态分析来对更改后的源代码文件进行分析(如图2-(b)所示)，然后在推荐面板中展示一个合适的代码评审者的推荐排名列表(如图2-(e)所示)。

B.更新现有的PR：CORRECT还可以为已经提交的PR推荐代码评审员，该请求要么没有分配评审员，要么分配了不合适的评审员。这可能对开发非常有帮助，因为代码评审人的不恰当分配会浪费宝贵的开发时间[14]。我们的工具使用静态分析对PR包含的更改后的源文件进行分析，然后推荐代码评审人员。

(2)自动挖掘相关工件：CORRECT自动挖掘软件项目的版本控制历史和代码评审历史，为给定的PR识别合适的代码评审人员，如下所示：

A.分析更改后的源代码文件：一旦一个分支(即第一个用例)或一个PR(即第二个用例)被选中时，该工具将从版本控制历史记录中的每次提交中收集所有更改过的文件。它访问GitHub API端点来收集更改后的文件，并使用GitHub-api，一个流行的GitHub客户端库来进行API访问。由于每个请求或分支可能涉及许多源代码文件，因此该工具只从API收集更改文件的路径，然后将这些信息应用到GitHub存储库的本地镜像，以执行进一步的静态分析。

B.分析代码评审历史：CORRECT从过去的代码评审中学会了推荐，正如现有的文献[2,14,16]所了解的那样。因此，它使用GitHub API[11]收集最近提交的30个PR的代码评审细节。由于在线API访问很耗时，并且会损害工具的性能，所以我们在进行API访问时采用并行机制。具体来说，我们将Java多线程应用于API访问，并进一步分析历史记录里的每个过去的PR。

(3)代码评审人的自动推荐：CORRECT对于任何给定的PR，返回一个包含五个代码评审人的排序列表(如图2-(e)所示)。此推荐的规模是可设定的，每次推荐平均需要10-15秒。该工具还提供了额外的见解来为开发者提交的PR选择合适的代码评审员。特别地，它提供了相关的专业评估(即由我们之前技术[11]评估)对外部软件库和PR所使用的特定技术的推荐评审人员进行了评估。该工具还提供了如下的几个可用特征：

A.自动化推荐的使用：一旦代码评审者在推荐面板中被推荐，用户只需点击“Copy reviewers”按钮(即图2-(f))就可以在PR主面板(即图2-(g))中复制粘贴评审者。然后用户可以通过使用“Create Pull request”按钮(即图2-(h))提交请求。该工具还提供了一个刷新按钮(如图2-(f)以右所示)帮助用户刷新评审人推荐列表。

B.基于缓存的推荐：由于我们使用的是无状态协议-HTTP，缓存是提高该工具性能(如响应时间)的一种便捷的方式。CORRECT使用localStorage来存储最近收集到的推荐结果，localStorage是谷歌Chrome和其他支持html5的浏览器的存储特性。对于来自同一页面的重复请求，CORRECT显示先前localStorage数据库存储的结果。如果用户需要，缓存也可以被清除，通过点击刷新按钮。

(4)个性化与优化：CORRECT使用开放认证的GitHub API访问，不仅具有评审人个性化推荐的潜力，还具有性能优化的潜力，如下所示：

A.个性化推荐：该工具在开放认证步骤中提取用户的身份，然后为其定制代码评审人推荐列表。特别地，CORRECT目前丢弃了推荐列表中的自引用(即用户自身作为评审人)。但是，其他社会方面(如开发人员合作历史)也可以用来进一步个性化评审员的推荐。

B.性能优化：GitHub将每位注册用户的API访问限制为每小时5000次调用。如果它仅限于一个用户帐户，特别是在涉及频繁访问API的工业环境中，这个限制很可能会引入工具的拒绝服务问题(如GitHub API的访问)。我们的工具通过使用开放身份验证克服了这一难题，其中工具代表登录的工具用户访问GitHub API，因此访问很少超过速率限制。

4 工作原理

图3显示了我们提出的工具CORRECT的原理图。该工具分析软件项目的版本控制历史和代码评审历史，然后为任何给定的PR提供一个潜在的代码评审人员列表。本节简要讨论该工具的内部结构和工作方法，同时请读者参阅原始论文[11]了解更多细节。

工作模块：CORRECT采用客户端-服务器架构，有两个工作模块，包括推荐引擎和客户端模块。我们将客户端模块打包为谷歌Chrome插件，将推荐引擎打包为web服务。一旦插件成功安装，它就会以用户图标的形式出现在浏览器的工具栏上(如图2-(d)所示)。当插件从web浏览器捕获PR的技术细节时，web服务分析请求和历史记录中的其他相关工件，并为请求获取代码评审人推荐。这两个模块都使用REST和HTTP之上的AJAX进行通信。

历史数据收集：CORRECT从一个项目中收集30个过去关闭的PR及其相应的评审细节，以便为新的PR推荐代码评审人员。我们首先识别每个PR并提取它们对应的提交。每个提交都可以使用它们基于SHA-1的ID进行区分，它们通常包含一个或多个一起更改的源文件。我们使用GitHub API访问和本地存储库分析从每个选择的过去的PR中收集这些更改的文件。我们对新的PR重复相同的步骤，并收集已更改的源文件，以提交到基本存储库。

然后，我们分析过去每个PR的代码评审细节，并使用GitHub API访问收集相应的评审人员信息。特别的是，我们收集了提交过程中引用的评审人员(如图2-(g)中的rwibe-va)和实际评审PR的评审人员(如图1中的cgooding-va)。这些历史信息为学习和评估我们的工具提交提供了基础(如真实数据集)。

代码评审技能和评审人排名：本文的核心思想是—拥有类似PR评审经验的开发人员是评审当前提交PR的合适候选者[2,14]。一旦收集了更改的源代码文件和以往PR的检查细节，我们就可以根据它们共享的外部库(如vapi、vform)和更改文件中采用的特定技术(如taskqueue、ndb)来确定它们与当前请求的相关性。特别的是，我们从每个PR中提取外部库名或专用技术名称，并确定当前请求与每个过去请求之间的余弦相似性。然后，我们将相似性估计(作为评审专业知识的代理)传播给过去请求的相应代码评审人员。因此，根据工具CORRECT的思想，对引入的外部库(即跨项目经验)和当前PR变更文件中采用的专业技术有更多经验的软件开发人员更适合代码评审。

举例：让我们考虑R3(图3)是一个要提交的PR，提交者正在为该请求寻找一个或多个代码评审人。R1和R2是两个过去的与R3类似的请求，其中包含一个或多个更改过的文件。从图3中，我们可以看到R1和R2分别都包括三个库，且都采用了三种专门的技术，并由不同的开发人员进行评审。同样，R3也包含了三个外部库，并在更改后的文件中采用了三种专用技术。为了向R3推荐评审人，CORRECT工具首先确定R3的库和技术与R1和R2的库和技术之间的余弦相似度。然后，它将这些分数应用到R1和R2的对应评审员身上。因此，对过去类似的请求拥有最多评审经验的开发人员，会排在代码评审人员的排名列表的最前面。从图3可以看出，评审人A得分最高(即1.17)。因此，我们推荐评审人A作为当前请求R3的代码评审人。对于任何给定的PR，我们推荐这个排名列表中的前5位代码评审者[2,14]。

5 用例场景

接下来将通过一个用例场景，来试着解释我们的CORRECT工具，如何帮助软件开发人员从web浏览器的上下文中为其提交的PR选择合适的代码评审人。

假设一个叫Alice的开发人员已经开始合作一个新的软件项目SR，并负责与Vendasta技术相关的部分。她首先从基库复制该项目，这为她提供了项目的本地副本，使她能够访问、编辑以及提交代码。然后，她开始修复ID为SR-3869的报告错误，在本地项目中删除了28行代码并添加了26行代码。当她完成修复之后，发现对包含在两个提交中的5个源代码文件进行了修改(如图4所示)。然后，她试着通过PR机制将更改提交到项目基库。如今的软件公司，如Vendasta，经常有一个强制性的代码评审要求，以保持代码质量。因此，她还关心提交更高代码质量的更改。在提交PR的过程中，她需要选择一个专业的开发人员列表，这些开发人员将在接受更改作为该项目的贡献之前对更改进行评审检查。到目前为止，GitHub还没有对这个任务提供任何支持，因此，她在这个阶段面临着几个挑战：(1)谁是这些更改最合适的代码评审者？(2)如何确定开发人员的代码评审能力？(3)我们能从过去的代码评审或版本控制历史中找到合适的评审人吗？

她可能会将该更改文件的原始作者作为评审候选人。然而，这可能是不贴合实际的，因为更改的文件可能是由许多开发人员多年来编写的，他们可能已经不在公司了。对于这个用例，我们注意到9个开发人员编写了更改的文件。Alice仍然需要自己从这些作者中找出最合适的评审者，而且她对他们的认识很少或根本没有帮助，这是一项具有挑战性的任务。对于Alice来说，如果她是新手，或者不熟悉公司的其他开发人员或代码库，任务就更有挑战性了。

现在，如果Alice在她的Chrome浏览器上安装了CORRECT插件，并且她提交了一个PR。我们的工具使用GitHub API访问从分支项目中自动收集更改后的源文件。然后，它通过分析最近提交的类似的PR信息(包含代码评审信息)，从项目的版本控制历史中获得的，从而向她推荐一份合适的代码评审员名单。特别的是，该工具会从PR的每个源文件自动提取外部库和专业技术信息(如表1所示)，然后利用提取的信息向其推荐代码评审员(如第4节所述)。除了排名，该工具还提供了关于代码评审人员的库和技术相关经验的额外信息(如表2所示)，这有助于Alice选择正确的评审人员。例如，推荐列表中排名前三位的评审人cberenik-va、cgooding-va和ywang-va具有期望的最大经验，她可以自信地选择他们作为她更改文件的评审人。因此，为了克服她之前面临的挑战，我们的工具将：(1)自动为被提交的PR推荐一个合适的代码评审人员列表，(2)自动捕获和利用开发人员的跨项目开发经验以及专业技术经验，来作为他们代码评审能力的合适评判，以及(3)使用GitHub API访问自动挖掘版本控制历史和代码评审历史，以实现推荐。简而言之，我们的工具在后台为Alice完成了所有繁重的工作，她只需在PR提交期间单击按钮即可获得推荐。更有趣的是，CORRECT在浏览器的上下文中提供推荐，这有助于维护通常的工作流程，并避免意外的上下文切换。在Vendasta技术的上下文中，我们选择了谷歌Chrome作为浏览器。但实际上，任何能够进行HTTP访问的浏览器插件都可以很容易地使用我们的推荐服务。

6 评估和验证

评估代码评审者推荐系统的最有效的方法之一，是咨询实际的代码评审人和通过分析代码库自动分配给他们的评审者。我们使用来自Vendasta代码库的真实代码评审数据来评估我们的技术。特别的是，我们通过分析来自Vendasta数据库的13,081个PR及其代码评审细节，以及使用一些流行的性能指标，来评估CORRECT工具。为了进一步验证我们的发现并证明其优越性，我们使用来自6个使用三种不同编程语言的开源系统的4,034个PR进行实验，并与最先进的技术进行比较。下面将简要讨论我们的评估和验证，详细内容可以在原始论文[11]中找到。

使用Vendasta系统进行评估：我们使用来自10个系统(Vendasta技术)的13,081个PR和4个最先进的性能指标(Top-K准确度、平均倒数排名、平均精度和平均召回率)，来评估我们的推荐技术[11]。我们的工具CORRECT提供了92.15%的Top-5准确度，0.67的平均倒数排名，85.93%的平均精度，81.39%的平均召回率，根据相关文献来看，该工具具有很高的应用前景。

与最先进技术的比较：我们通过与Thongtanunam等人提出的技术[14]的比较来验证我们的技术的性能，它是一种先进的代码评审者推荐技术，其性能优于早期的技术。我们的工具CORRECT与先进的技术相比，提高了11.43%的Top-5准确度，以及约10%的精度和召回率。MWU、Cohen’s d和Glass △这三个统计测试也表明这种改善在统计学上是显著的。

开源项目实验：虽然使用Vendasta的Python系统可以充分评估CORRECT工具，但我们对来自GitHub的六个开源项目进行了另一个实验，这些项目用三种不同的编程语言(java、Python和Ruby)编写。在这种情况下，CORRECT推荐的Top-5准确度为85.20%，平均倒数排名为0.69，平均精度为84.76%，平均召回率为78.73%。比较表明，我们的工具要比先进的技术[14]表现更为突出。进一步的调查也证实了CORRECT不显示对任何编程语言或任何项目类型(开放源码和封闭源码)的偏好。

基于用户研究的评估计划：虽然基于经验评估，我们发现这个工具很有前途，我们仍计划使用用户研究来评估这个工具，其中包括来自Vendasta的专业开发人员。研究的目标是根据实际开发人员的反馈来确定工具的可用性和有用性。在用户研究中，我们计划让至少10名开发人员参与10个不同的运行项目。每个参与者将安装该工具，使用它来完成两项受控任务(即代码评审人分配)，然后将使用预定义的评分等级来评估工具提供的建议。然后，我们会收集数字评级以及它们的定性反馈，以便用我们的实证结果对它们进行三角分析。

7 相关的工作

代码评审人推荐：现有的研究主要通过分析代码评审或版本控制历史[2,13,14,16,18]和开发人员协作网络[18]来推荐代码评审人员。Balachandran[2]提出了一个ReviewBot工具，它可以分析给定审查请求中受影响的源代码行更改历史，然后根据该请求的历史记录确定代码评审人员。然而，现有的发现表明，大多数行通常只改变一次[14]，这使得行改变历史真的很少，因此，ReviewBot的性能是有限的。Thongtanunam等人提出了RevFinder[14]，它使用文件路径相似度(FPS)[13]识别相关评审请求，然后从这些请求中推荐某请求的评审人。RevFinder也优于包括ReviewBot[14]在内的早期技术。另一方面，为了正确识别相关PR，便于评审人推荐，发现在估算PR之间的相关性时，CORRECT利用外部库相似度和专业技术相似度，要比计算文件路径相似度[14]更有效。在我们较早的工作[11]中，我们表明了我们的技术在统计上显著的性能改进优于RevFinder。另一项最近的工作[16]在过去的代码评审中应用了机器学习，并结合了文本相似性和文件路径相似性[14]。因此，它与RevFinder存在类似的问题，如PR相关性问题，以及所学习的模型可能会偏向于所研究的主题系统。其他的工作-Yu等人[18]分析了过去的评审评论和开发人员协作网络以获得评审人推荐。当我们在使用PR之间的库和技术相似度来确定相关的过去请求时，他们使用评审评论相似度(即文本相似度)，以达到相同的目的。此外，他们的想法仍然没有得到合适的评估或验证。

专家推荐：Kintab等人[9]通过利用代码与其他代码片段的相似性来识别对该代码片段可能感兴趣的专家开发人员。Trindade等人[5]也采用了类似的技术，他们构建了一个文档、源代码和开发人员之间的通信网络，然后推荐占主导地位的开发人员为专家。Yang[17]使用代码评审关系研究开发人员网络，并使用不同网络属性来识别核心和外围开发人员。在bug分类领域中也有一些研究，它们通过分析重复的bug报告[8]，或者利用IR的可跟踪性[10]来推荐合适的开发人员进行bug修复。还有一些在Stack Overflow上进行专家用户推荐的研究，它们通过分析跨域贡献[15]或问题难度[7]来进行专家估计。虽然这些专家推荐技术与我们的有些相似，但他们的推荐背景是不同的，因此，将我们的推荐技术与他们进行比较是不可行的。当然，我们引入了两种新颖而有效的专家经验模式(跨项目经验和专业技术经验)，它们没有被任何推荐系统所利用。这使得我们提出的CORRECT工具与其他所有工具都有显著的不同。

8 结论

综上所述，我们为Vendasta技术项目提出了一个新的工具CORRECT，用于在GitHub上对提交的PR推荐代码评审人。它会自动捕获开发人员开发外部库的经验(即跨项目经验)和在给定的PR中使用的特定技术经验，将这些经验作为代理应用于开发人员的代码评审能力的判断，最后推荐一个合适的代码评审人员的排名列表。我们的推荐技术使用经验数据来进行充分评估和验证的。我们将解决方案打包为一个web服务和一个谷歌Chrome浏览器插件。该工具可以帮助开发人员在提交新的PR或更新已有PR(如分配评审人)时，选择合适的代码评审人。