CN114327583A - 一种超图构建方法、装置、设备及存储介质 - Google Patents

Abstract

本发明公开了一种超图构建方法、装置、设备及存储介质。该方法包括：获取代码评审数据；根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，通过本发明的技术方案，能够根据代码评审数据，对合入请求、开发者信息以及评审者信息之间的关系进行建模，满足信息全面性和可解释性，方便后续对评审活动的研究和管理。

Description

一种超图构建方法、装置、设备及存储介质

技术领域

本发明实施例涉及软件开发技术领域，尤其涉及一种超图构建方法、装置、设备及存储介质。

背景技术

代码评审是软件开发过程中的一个重要过程，对商业项目和开源项目的软件质量至关重要。代码评审由专业评审者负责，评审者通过手动仔细检查源代码，目标是识别代码中存在的问题和潜在的改进，从而防止有问题的代码片段被合并到的代码存储库中。除了代码质量保证外，代码评审还有助于知识传播、团队协作等方面。现在需要有一种合理代码评审数据的建模方案，描述代码合入请求、开发者、评审者之间的关系，便于对代码评审行为进行研究和管理。

现有技术中，已经有几种基于构图对代码评审活动描述的建模方式。但是现在所有的建模方案都是以建立普通图为基础。普通图就是一条边有两个节点的图，无法同时连接三个以上节点。普通图无法准确的描述代码评审中复杂的交互关系，会损失部分的信息，如评审者的共同评审关系。并且用普通图描述复杂评审关系，会导致图上边数量众多，让人难以理解。现有的技术不能满足模型在信息全面性、可解释性等方面的需求，不方便后续对评审活动的研究和管理。

发明内容

本发明实施例提供一种超图构建方法、装置、设备及存储介质，解决了普通图无法准确的描述代码评审中复杂的交互关系，会损失部分的信息，并且用普通图描述复杂评审关系，会导致图上边数量众多，不能满足模型在信息全面性、可解释性等方面的需求，不方便后续对评审活动的研究和管理的问题，能够根据代码评审数据，对合入请求、开发者信息以及评审者信息之间的关系进行建模，满足信息全面性和可解释性，方便后续对评审活动的研究和管理。

第一方面，本发明实施例提供了一种超图构建方法，包括：

获取代码评审数据；

根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

进一步的，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标合入请求；

基于所述目标合入请求查询所述目标超图，得到目标开发者信息，与所述目标合入请求和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

进一步的，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标开发者信息；

基于所述目标开发者信息查询所述目标超图，得到所述目标开发者信息和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

进一步的，根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，包括：

获取所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重；

对所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重进行归一化处理；

根据归一化处理后的合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重构建超图。

进一步的，获取所述合入请求和所述评审者信息之间的超边的权重，包括：

根据所述代码评审数据确定请求集合；

获取所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和最晚创建的请求对应的创建时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重。

进一步的，所述评审者信息集合包括：评审者数量、每个评审者评审意见条数和每条评审意见对应的发布时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间、所述评审者数量、所述每个评审者评审意见条数和所述每条评审意见对应的发布时间确定所述合入请求和评审者信息之间的超边的权重。

进一步的，获取所述合入请求和所述开发者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和所述开发者信息之间的超边的权重。

进一步的，获取任意两个所述合入请求之间的超边的权重，包括：

获取所述任意两个合入请求对应的修改文件集合；

计算每个修改文件集合中任意两个修改文件之间的相似度；

根据所述修改文件集合的长度、所述每个修改文件集合中任意两个修改文件之间的相似度、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述合入请求所属请求集合中最晚创建的请求对应的创建时间以及所述任意两个合入请求对应的创建时间确定任意两个所述合入请求之间的超边的权重。

进一步的，计算每个修改文件集合中任意两个修改文件之间的相似度，包括：

获取每个修改文件集合中的修改文件的路径；

根据任意两个修改文件的路径确定任意两个修改文件的相同前缀长度和每个修改文件的路径深度；

根据所述任意两个修改文件的前缀长度和所述任意两个修改文件的路径深度确定任意两个修改文件之间的相似度。

第二方面，本发明实施例还提供了一种超图构建装置，该超图构建装置包括：

获取模块，用于获取代码评审数据；

确定模块，用于根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

构建模块，用于根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

第三方面，本发明实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如本发明实施例中任一所述的超图构建方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例中任一所述的超图构建方法。

本发明实施例通过获取代码评审数据；根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，解决了普通图无法准确的描述代码评审中复杂的交互关系，会损失部分的信息，并且用普通图描述复杂评审关系，会导致图上边数量众多，不能满足模型在信息全面性、可解释性等方面的需求，不方便后续对评审活动的研究和管理的问题，能够根据代码评审数据，对合入请求、开发者信息以及评审者信息之间的关系进行建模，满足信息全面性和可解释性，方便后续对评审活动的研究和管理。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本发明实施例中的一种超图构建方法的流程图；

图1a是本发明实施例中的一种超图示意图；

图1b是本发明实施例中的超边建立方法的流程图；

图1c是本发明实施例中的两个修改文件之间的相似度的计算方法的流程图；

图2是本发明实施例中的一种超图构建装置的结构示意图；

图3是本发明实施例中的一种电子设备的结构示意图；

图4是本发明实施例中的一种包含计算机程序的计算机可读存储介质的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

本发明使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本发明的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1为本发明实施例提供的一种超图构建方法的流程图，本实施例可适用于超图构建的情况，该方法可以由本发明实施例中的超图构建装置来执行，该装置可采用软件和/或硬件的方式实现，如图1所示，该方法具体包括如下步骤：

S110，获取代码评审数据。

其中，所述代码评审数据可以为至少一个项目的历史代码评审数据。

具体的，代码评审数据是指若干次的合入请求以及相关代码评审活动的集合，表示软件项目代码提交情况的非正式的、异步的、基于工具的代码审查实践。合入请求包括代码修改文件集合，相关代码评审活动的集合包括：合入请求对应的开发者信息、合入请求的评审者信息以及评审意见。示例性的，项目中存在若干的历史合入请求，为集合PRS，对于集合中任意合入请求p_i∈PRS，存在开发者a_i，以及若干在p_i上发表过评审意见的评审者组成的集合R_i。

在一个具体的例子中，首先读取预先获取的开源项目平台GitHub上的软件项目metaploit的代码评审数据。评审数据包括了若干次的代码合入请求以及相关代码评审活动的集合，具体体现为代码合入请求数据和评审意见数据，代码合入请求数据和评审意见数据格式均为TSV文件。

S120，根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息。

其中，所述合入请求为代码合入请求，所述合入请求用于将代码合入代码仓库。所述合入请求包括：合入请求的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间。

其中，所述开发者信息为所述合入请求对应的开发者信息。所述开发者信息包括：开发者标识信息和开发者对应的终端地址信息等。

具体的，根据所述代码评审数据确定至少两个目标节点的方式可以为：初始情况下的超图节点集合和超边集合均为空集，开发者信息、评审者信息以及合入请求构成目标节点。

在一个具体的例子中，根据获取到的某个项目的全部历史代码合入请求信息，首先按照开发者进行统计，获得全部开发者信息，然后按照代码评审者进行统计，获得全部的代码评审者信息，然后按照代码合入统计，获得全部的代码合入请求。示例性的，收集到某软件项目的1000个代码合入请求，以及参与这些代码合入请求的50个开发者与70个代码评审者。进一步的，将这些代码合入请求、开发者以及评审者加入超图的节点集合，例如，创建1000个代表代码合入请求的节点，50个代表开发者信息的节点，70个代表代码评审者信息的节点，并将这些节点加入超图的节点集合。

S130，根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

其中，超图是用来表述更加准确的描述存在多元关联的对象之间的关系的一种图结构。

具体的，根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图的方式可以为：根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建超边，根据构建的超边和目标节点构建目标超图，其中，构建超边是指，在新的超边中添加合入请求节点和评审者信息节点。计算合入请求节点到评审者信息节点之间超边的权重。将计算得出的超边加入超图的超边集合中。由于存在多个合入请求，在超图中会添加多条边。

在一个具体的例子中，按照单次合入请求为处理粒度，依次处理多个合入请求。对于某次合入请求，有对应的代码评审者集合，以及每个评审者做出评审时，多条意见提出的时间。对该次合入请求，建立一条超边，把合入请求和合入请求对应所有评审者信息加入超边中。

在另一个具体的例子中，对于某次代码合入对应的具体项目而言，可以得到这个项目中最早的代码合入请求创建的时间，以及这个项目中最晚的代码合入请求创建的时间。在获得项目中最早和最晚的代码合入请求创建的时间的基础上，进一步的，根据各代码评审日期的时间分布，代码评审意见的发表时间，参与评审的评审者数量以及对应的意见数量为判断标准，计算代码合入请求节点到评审者信息节点之间超边的权重。在计算完成代码合入请求节点到评审者信息节点之间超边的权重后，进一步的，可以将代码合入请求和代码评审者之间的超边加入超图的超边集合。

其中，合入请求与开发者信息之间的关系，表示在某个具体的合入请求中，开发者对合入请求的创建情况；构建超边是指，在新的超边中添加合入请求节点和开发者节点。计算合入请求对应的节点到开发者信息节点之间超边的权重。将计算得出的超边加入超图的超边集合中。

本实施例中，按照单次代码合入请求为处理粒度，依次处理多个合入请求。对于某次合入请求，有对应的开发者信息，以及合入请求的创建时间。对该次合入请求，建立一条超边，把合入请求和对应开发者信息加入超边中。

对于某次合入请求对应的具体项目而言，可以得到这个项目中最早的合入请求创建的时间，以及这个项目中最晚的合入请求创建的时间。在获得项目中最早和最晚的合入请求创建的时间的基础上，进一步的，根据合入请求创建日期为判断标准，计算合入请求节点到开发者信息节点之间超边的权重。将开发者信息与合入请求之间的超边加入超图的超边集合。

其中，合入请求之间的关系，表示两个合入请求之间的相关程度，这些合入请求属于同一个项目；构建超边是指，在新的超边中添加两个合入请求节点。计算两个合入请求节点之间超边的权重。为每一个合入请求保留若干条和其他合入请求权重最大的超边。将计算得出的超边加入超图的超边集合中。

具体的，按照单次合入请求为处理粒度，依次处理多个合入请求。对于某软件项目，存在多个历史合入请求。可以得到这个项目中最早的合入请求创建的时间，以及这个项目中最晚的合入请求创建的时间。对于某次合入请求，可以得到合入请求涉及到的修改的文件集合。在获得项目所有合入请求，以及每个合入请求中修改的文件集合的基础上。进一步的，计算每个合入请求节点到其他合入请求节点之间超边的权重。权重由修改文件集合之间的相似度，项目中最早的代码合入请求创建的时间，项目中最晚的代码合入请求创建的时间，以及两个配对的代码合入请求的创建时间计算得到。其中，修改文件集合之间的相似度，取决于两个文件集合中文件的数量以及集合中两两修改文件之间的相似度。修改文件之间的相似度，代表两个被修改文件的文件路径的相同前缀长度以及两个文件路径中路径的深度之间的关系。两个修改文件之间的相似度与两个文件路径的相同前缀长度成正比，与两个文件路径中最深的路径长度成反比。示例性的，文件A的路径为”src/com/android/settings/LocationSettings.java”，文件B的路径为”src/com/android/settings/Utils.java”，那么，两个文件路径的相同前缀长度为4，文件A的路径的深度为5，文件B的路径的深度为5，则文件A和文件B的相似度为4/5。

具体的，程序读取合入请求和评审意见数据，添加合入请求、开发者信息和评审者信息对应的节点。程序按照合入请求和评审者关系、合入请求和开发者关系、合入请求之间的关系在超图中添加超边。统计每个节点相连的边和每条超边的权重，建立指示矩阵H和边权重矩阵W。对于包含顶点集合V和超边集合E超图G＝{V,E}，在程序中使用矩使用指示矩阵H和边权重矩阵W表示。指示矩阵用于记录超图上节点和超边的关系，大小为|V|×|E|。指示矩阵的第i行第j列记录了顶点v_i∈V和超边e_j∈E的关系。如果顶点v_i在边e_j中h(v_i,e_j)＝1，否则h(v_i,e_j)＝0。而边权重矩阵是一个大小为|E|×|E|的对角矩阵，其中对角线元素为超边的权重。

本实施例中，对于计算完成的超图，使用软件Gephi进行可视化展示。如图1a所示，图中包括三种不同的节点：接入请求对应的节点、开发者信息对应的节点以及评审者信息对应的节点。代码评审的建模数据，可以用于后续的研究或者管理活动。

可选的，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标合入请求；

基于所述目标合入请求查询所述目标超图，得到目标开发者信息，与所述目标合入请求和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

其中，所述目标合入请求的获取方式可以为用户点击目标控件得到的目标合入请求，所述目标合入请求的获取方式还可以为用户语音输入方式，本发明实施例对此不进行限制。

其中，所述匹配度阈值可以为预先设定的阈值。

具体的，获取目标合入请求；基于所述目标合入请求查询所述目标超图，得到目标开发者信息，与所述目标合入请求和评审者信息的匹配度；将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端，例如可以是，获取合入请求A，根据合入请求A查询目标超图，得到合入请求A对应的开发者信息Q，合入请求A和全部评审者信息的匹配度，将匹配度大于匹配度阈值的评审者信息发送至开发者信息Q对应的终端。

可选的，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标开发者信息；

基于所述目标开发者信息查询所述目标超图，得到所述目标开发者信息和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

其中，所述目标开发者信息可以为开发者ID，也可以为其他能够标识开发者的标识信息，本发明实施例对此不进行限制。

具体的，获取目标开发者信息；基于所述目标开发者信息查询所述目标超图，得到所述目标开发者信息和评审者信息的匹配度；将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。例如可以是，获取开发者信息P；基于开发者信息P查询所述目标超图，得到开发者信息P和全部评审者信息的匹配度；将匹配度大于匹配度阈值的评审者信息发送至开发者信息P对应的终端。

可选的，根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，包括：

获取所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重；

对所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重进行归一化处理；

根据归一化处理后的合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重构建超图。

其中，归一化处理是通过一定的计算方法，将数据映射到0到1的范围之内的一种处理方式。

具体的，根据之前步骤得到的所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重，对不同类型的超边分别进行归一化处理。示例性的，对全部合入请求与评审者信息之间的超边权重进行处理，将所有权重映射到0到1范围之内，以方便后续的模型数据处理。

在一个具体的例子中，根据之前步骤得到的合入请求与评审者信息之间、合入请求与开发者信息之间、合入请求与其他合入请求之间的超边，对不同类型的超边分别进行归一化处理。把图中的边e∈E分为三个集合，分别是E_pr,E_pc,E_pp，对于每个集合中的权值进行归一化处理。以集合E_pr为例，假设对应的权值集合为W_pr＝{w₁Kw_n}。对其中任意权值w_i做以下的处理：

其中，w_min为权值集合W_pr的最小值，W_max为权值集合W_pr的最大值。归一化后的结果W′_pr＝{w′₁K w′_n}代替原来的权值。

可选的，获取所述合入请求和所述评审者信息之间的超边的权重，包括：

根据所述代码评审数据确定请求集合；

获取所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重。

其中，所述合入请求所属请求集合为合入请求所属项目对应的请求集合，例如可以是，若项目X对应的请求集合为W，合入请求A为请求集合W中的合入请求，则合入请求A所属请求集合为请求集合W。

其中，所述合入请求所属请求集合中最早创建的请求对应的创建时间为请求集合W中最早创建的请求对应的创建时间。

其中，所述合入请求所属请求集合中最晚创建的请求对应的创建时间为请求集合W中最晚创建的请求对应的创建时间。

其中，所述评审者信息集合包括：评审者数量、每个评审者评审意见条数和每条评审意见对应的发布时间。

具体的，根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重的方式可以为：根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间、所述评审者数量、所述每个评审者评审意见条数和所述每条评审意见对应的发布时间确定所述合入请求和评审者信息之间的关系。

可选的，所述评审者信息集合包括：评审者数量、每个评审者评审意见条数和每条评审意见对应的发布时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间、所述评审者数量、所述每个评审者评审意见条数和所述每条评审意见对应的发布时间确定所述合入请求和评审者信息之间的超边的权重。

具体的，根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间、所述评审者数量、所述每个评审者评审意见条数和所述每条评审意见对应的发布时间确定所述合入请求和评审者信息之间的超边的权重，例如可以是，计算合入请求与评审者信息之间的超边权重，具体计算方法如下：

其中，合入请求p_i的每一个评审者

在p_i的评审中发表了

条评审意见，其中第k条评审意见的发布时间为

λ∈[0,1]为超参数，用于调整多条评审意见影响程度。对于合入请求p_i，t_i为合入请求p_i的创建时间；t_s为集合PRS中最早的合入请求的创建时间，t_e为集合PRS中最晚的合入请求的创建时间。

可选的，获取所述合入请求和所述开发者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和所述开发者信息之间的超边的权重。

具体的，根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和所述开发者信息之间的超边的权重。例如可以是，计算合入请求与评审者信息之间的超边权重，具体计算方法如下：

其中，t_i为合入请求p_i的创建时间；对于整个项目的所有PRS，t_s为集合PRS中最早的合入请求的创建时间，t_e为集合PRS中最晚的合入请求的创建时间。

基于上述公式得到以p_i以及a_i作为节点，权重为w的超边e_pc，并将这个超边加入超图边集合E中。

可选的，获取任意两个所述合入请求之间的超边的权重，包括：

获取所述任意两个合入请求对应的修改文件集合；

计算每个修改文件集合中任意两个修改文件之间的相似度；

根据所述修改文件集合的长度、所述每个修改文件集合中任意两个修改文件之间的相似度、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述合入请求所属请求集合中最晚创建的请求对应的创建时间以及所述任意两个合入请求对应的创建时间确定任意两个所述合入请求之间的超边的权重。

其中，每个合并请求对应一个修改文件集合。

具体的，计算每个修改文件集合中任意两个修改文件之间的相似度的方式可以为：计算每个修改文件集合中两两修改文件之间的相似度。例如可以是，若包括修改文件集合M和修改文件集合V，修改文件集合M包括：修改文件1、修改文件2和修改文件3，修改文件集合V包括：修改文件4、修改文件5和修改文件6，计算修改文件1和修改文件2之间的相似度、修改文件1和修改文件3之间的相似度以及修改文件2和修改文件3之间的相似度；计算修改文件4和修改文件5之间的相似度、修改文件4和修改文件6之间的相似度以及修改文件5和修改文件6之间的相似度。

示例性的，对于合入请求p_i，F_i为p_i中涉及到修改的文件集合，其中数量为|F_i|。对于合入请求p_j，F_j为p_j中涉及到修改的文件集合，其中数量为|F_j|。对于选择任意修改文件f_i∈F_i和f_j∈F_j，计算两个修改文件之间的相似度(Similarity(f_i,f_j))，计算两个修改文件之间的相似度(Similarity(f_i,f_j))，其计算方法如下：

计算细节如图1c所示，其中，LCP(f_i,f_j)即求两个文件路径f_i,f_j的相同前缀长度。把文件路径按照路径分割符切分，可以获得两个字符串数组。两个字符串数组从数组头部开始对比，相同字符串元素的数量就为最长前缀长度。而len(f_i)函数计算了文件路径的深度,即把文件路径按照路径分割符切分获得的字符串数组的元素个数。

在一个具体的例子中，如图1b所示，需要遍历的代码合入请求集合为PRS,大小为|PRS|。初始化超边集合E_pp用于存放需要建立超边的顶点和权重信息。外层循环使用变量i，遍历的代码合入请求为p_i。内层循环使用变量j，遍历的代码合入请求为p_j。每次遍历外层循环时候，初始化候选集合

在内层循环中，计算代码合入请求p_i和p_j的相似程度w_ij。对于建立三元组(p_i',p_j',w_ij)，放入

其中如果i＜j则i'＝i,j'＝j，如果i＞j则i'＝j,j'＝i。在一次内层循环遍历完成之后，对于候选集合

中的三元组，根据权重(三元组中第三项)从大到小排序，获得列表

对于列表

选择前面的a项加入集合E_pp中。在外层遍历结束之后，根据集合E_pp的三元组，建立代码合入请求之间的超边。三元组的头两项为超边的顶点，第三项为超边的权重。

可选的，计算每个修改文件集合中任意两个修改文件之间的相似度，包括：

获取每个修改文件集合中的修改文件的路径；

根据任意两个修改文件的路径确定任意两个修改文件的相同前缀长度和每个修改文件的路径深度；

根据所述任意两个修改文件的前缀长度和所述任意两个修改文件的路径深度确定任意两个修改文件之间的相似度。

示例性的，如果f₁＝“src/com/android/settings/LocationSettings.java”,f₂＝”src/com/android/settings/Utils.java”。那么len(f₁)＝5，len(f₂)＝5，LCP(f₁,f₂)＝length([src,com,android,settings])＝4。LCP(f₁,f₂)为两个修改文件的相同前缀长度，len(f₁)为f₁的路径深度，len(f₂)为f₂的路径深度。

在一个具体的例子中，首先初始化超图G＝{V,E}，将节点集合V和超边集合E设置为空集，即：

进一步，添加超图的节点。项目中存在若干的历史合入请求，为合入请求集合PRS。对于合入请求集合中任意合入请求p_i∈PRS，存在开发者a_i，以及若干在p_i上发表过评审意见的评审者集合R_i。依次遍历合入请求p_i∈PRS，节点集合V中依次添加合入请求p_i，开发者a_i以及评审者集合R_i中的成员作为节点，即V←{V∪{p_i}∪{a_i}∪R_i}。

计算合入请求与评审者信息之间的超边权重，具体计算方法如下：

其中，合入请求p_i的每一个评审者

在p_i的评审中发表了

条评审意见，其中第k条评审意见的发布时间为

λ∈[0,1]为超参数，用于调整多条评审意见影响程度。对于合入请求p_i，t_i为合入请求p_i的创建时间；t_s为集合PRS中最早的合入请求的创建时间，t_e为集合PRS中最晚的合入请求的创建时间。

超边的权重衡量了合入请求和评审者信息之间的相关程度，考虑了合入请求中所有的评审者的参与情况

以及每个评审者提出评审意见的数量

参与的人越多，意见提的越多，相关程度就越大。对于每条评审意见，还考虑了其时效性

和发表顺序(λ^k-1)，发表的时间越新并且意见发表顺序越前，就越相关。

得到以p_i以及任意

作为节点，权重为w的超边e_pr，并将这个超边加入超图边集合E中。

其中，λ∈[0,1]用于调整多条评审意见的影响程度。评审意见之间会相互作用，发表早的意见会影响后续的意见，有较大的影响力，而后面的评审意见相对会受到前面意见影响，影响力较小。

本发明实施例提供了一种具体的多条评审意见影响程度的衡量方法，它和评审意见发表的顺序有关，发表时间越早表示评审意见越不受其他评审意见的影响。

计算合入请求与评审者信息之间的超边权重，具体计算方法如下：

其中，t_i为合入请求p_i的创建时间；对于整个项目的所有PRS，t_s为集合PRS中最早的合入请求的创建时间，t_e为集合PRS中最晚的合入请求的创建时间。

基于上述公式得到以p_i以及a_i作为节点，权重为w的超边e_pc，并将这个超边加入超图边集合E中。

超边的权重衡量了合入请求和开发者之间的相关程度，考虑了合入请求时效性

合入请求的创建时间越新(t_i-t_s)，那么相关程度就越大，考虑最早合入请求和最晚合入请求创建时间差值是为了权重归一化(t_e-t_s)。

对于合入请求p_i，F_i为p_i中涉及到修改的文件集合，其中数量为|F_i|。对于合入请求p_j，F_j为p_j中涉及到修改的文件集合，其中数量为|F_j|。对于选择任意修改文件f_i∈F_i和f_j∈F_j，计算两个修改文件之间的相似度(Similarity(f_i,f_j))，计算两个修改文件之间的相似度(Similarity(f_i,f_j))，其计算方法如下：

计算细节如图1c所示，其中，LCP(f_i,f_j)即求两个文件路径f_i,f_j的相同前缀长度。把文件路径按照路径分割符切分，可以获得两个字符串数组。两个字符串数组从数组头部开始对比，相同字符串元素的数量就为最长前缀长度。而len(f_i)函数计算了文件路径的深度,即把文件路径按照路径分割符切分获得的字符串数组的元素个数。

示例性的，如果f₁＝“src/com/android/settings/LocationSettings.java”,f₂＝”src/com/android/settings/Utils.java”。那么len(f₁)＝5，len(f₂)＝5，LCP(f₁,f₂)＝length([src,com,android,settings])＝4。

对于合入请求p_i，t_i为合入请求p_i的创建时间；对于整个项目的所有PRS，t_s为集合PRS中最早的合入请求的创建时间，t_e为集合PRS中最晚的合入请求的创建时间。对于任意合入请求p_i∈PRS，依次计算p_i和其他的合入请求{p_j∈PRS|i≠j}的相关程度w_ij，其计算方法为：

对于合入请求p_i，相关程度计算的结果集合为{w_ij,p_j∈PRS|i≠j}，根据权值的大小进行排序。权值越大代表越重要，选择a个最重要合入请求建立a条超边。将节点为合入请求p_i和对应的其他的合入请求p_j，权重为w_ij的超边

加入超图。

其中，选择a个最重要代码合入请求建立a条超边是为了限制图中这类型边的数量，每个代码合入请求最多保留a条和其他的超边，只选择权重最大的那些边。例如可以是，假设图中有100个合入请求节点。那么两两的相连有(100*100)/2条边，图中最多这个类型只有100*a条边了。建立合入请求到合入请求之间的超边时候，一条超边上面是只有两个顶点的。假设一共有100个合入请求，建立的逻辑是：依次遍历每个合入请求，计算其和其他99个合入请求之间的权重，一共有99个权重值。在这99个中选择a个最大的权重，和计算出该权重的两个节点，建立a条边。

本实施例的技术方案，通过获取代码评审数据；根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，解决了普通图无法准确的描述代码评审中复杂的交互关系，会损失部分的信息，并且用普通图描述复杂评审关系，会导致图上边数量众多，不能满足模型在信息全面性、可解释性等方面的需求，不方便后续对评审活动的研究和管理的问题，能够根据代码评审数据，对合入请求、开发者信息以及评审者信息之间的关系进行建模，满足信息全面性和可解释性，方便后续对评审活动的研究和管理。

图2为本发明实施例提供的一种超图构建装置的结构示意图。本实施例可适用于超图构建的情况，该装置可采用软件和/或硬件的方式实现，该装置可集成在任何提供超图构建功能的设备中，如图2所示，所述超图构建装置具体包括：获取模块210、确定模块220和构建模块230。

其中，获取模块，用于获取代码评审数据；

确定模块，用于根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

构建模块，用于根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

上述产品可执行本发明任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。

本实施例的技术方案，通过获取代码评审数据；根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，解决了普通图无法准确的描述代码评审中复杂的交互关系，会损失部分的信息，并且用普通图描述复杂评审关系，会导致图上边数量众多，不能满足模型在信息全面性、可解释性等方面的需求，不方便后续对评审活动的研究和管理的问题，能够根据代码评审数据，对合入请求、开发者信息以及评审者信息之间的关系进行建模，满足信息全面性和可解释性，方便后续对评审活动的研究和管理。

图3为本发明实施例三提供的一种电子设备的结构示意图。图3示出了适于用来实现本发明实施方式的电子设备312的框图。图3显示的电子设备312仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。设备312是典型的轨迹拟合功能的计算设备。

如图3所示，电子设备312以通用计算设备的形式表现。电子设备312的组件可以包括但不限于：一个或者多个处理器316，存储装置328，连接不同系统组件(包括存储装置328和处理器316)的总线318。

总线318表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(Industry StandardArchitecture，ISA)总线，微通道体系结构(Micro Channel Architecture，MCA)总线，增强型ISA总线、视频电子标准协会(Video Electronics Standards Association，VESA)局域总线以及外围组件互连(Peripheral Component Interconnect，PCI)总线。

电子设备312典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备312访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储装置328可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(Random Access Memory，RAM)330和/或高速缓存存储器332。电子设备312可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统334可以用于读写不可移动的、非易失性磁介质(图3未显示，通常称为“硬盘驱动器”)。尽管图3中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如只读光盘(Compact Disc-Read Only Memory，CD-ROM)、数字视盘(Digital Video Disc-Read Only Memory，DVD-ROM)或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线318相连。存储装置328可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。

具有一组(至少一个)程序模块326的程序336，可以存储在例如存储装置328中，这样的程序模块326包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块326通常执行本发明所描述的实施例中的功能和/或方法。

电子设备312也可以与一个或多个外部设备314(例如键盘、指向设备、摄像头、显示器324等)通信，还可与一个或者多个使得用户能与该电子设备312交互的设备通信，和/或与使得该电子设备312能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口322进行。并且，电子设备312还可以通过网络适配器320与一个或者多个网络(例如局域网(Local Area Network，LAN)，广域网Wide Area Network，WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器320通过总线318与电子设备312的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备312使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、磁盘阵列(Redundant Arrays of Independent Disks，RAID)系统、磁带驱动器以及数据备份存储系统等。

处理器316通过运行存储在存储装置328中的程序，从而执行各种功能应用以及数据处理，例如实现本发明上述实施例所提供的超图构建方法：

获取代码评审数据；

根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

图4为本发明实施例中的一种包含计算机程序的计算机可读存储介质的结构示意图。本发明实施例提供了一种计算机可读存储介质61，其上存储有计算机程序610，该程序被一个或多个处理器执行时实现如本申请所有发明实施例提供的超图构建方法：

获取代码评审数据；

根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。

在一些实施方式中，客户端、服务器可以利用诸如HTTP(Hyper Text TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (12)

1.一种超图构建方法，其特征在于，包括：

获取代码评审数据；

根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

2.根据权利要求1所述的方法，其特征在于，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标合入请求；

基于所述目标合入请求查询所述目标超图，得到目标开发者信息，与所述目标合入请求和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

3.根据权利要求1所述的方法，其特征在于，在根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图之后，还包括：

获取目标开发者信息；

基于所述目标开发者信息查询所述目标超图，得到所述目标开发者信息和评审者信息的匹配度；

将匹配度大于匹配度阈值的评审者信息发送至所述目标开发者信息对应的终端。

4.根据权利要求1所述的方法，其特征在于，根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图，包括：

获取所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重；

对所述合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重进行归一化处理；

根据归一化处理后的合入请求和所述评审者信息之间的超边的权重、所述合入请求和所述开发者信息之间的超边的权重以及任意两个所述合入请求之间的超边的权重构建超图。

5.根据权利要求4所述的方法，其特征在于，获取所述合入请求和所述评审者信息之间的超边的权重，包括：

根据所述代码评审数据确定请求集合；

获取所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和最晚创建的请求对应的创建时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重。

6.根据权利要求5所述的方法，其特征在于，所述评审者信息集合包括：评审者数量、每个评审者评审意见条数和每条评审意见对应的发布时间；

根据所述合入请求对应的创建时间、所述合入请求对应的评审者信息集合、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和评审者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述目标请求所属请求集合中最晚创建的请求对应的创建时间、所述评审者数量、所述每个评审者评审意见条数和所述每条评审意见对应的发布时间确定所述合入请求和评审者信息之间的超边的权重。

7.根据权利要求4所述的方法，其特征在于，获取所述合入请求和所述开发者信息之间的超边的权重，包括：

根据所述合入请求对应的创建时间、所述合入请求所属请求集合中最早创建的请求对应的创建时间和所述合入请求所属请求集合中最晚创建的请求对应的创建时间确定所述合入请求和所述开发者信息之间的超边的权重。

8.根据权利要求4所述的方法，其特征在于，获取任意两个所述合入请求之间的超边的权重，包括：

获取所述任意两个合入请求对应的修改文件集合；

计算每个修改文件集合中任意两个修改文件之间的相似度；

根据所述修改文件集合的长度、所述每个修改文件集合中任意两个修改文件之间的相似度、所述合入请求所属请求集合中最早创建的请求对应的创建时间、所述合入请求所属请求集合中最晚创建的请求对应的创建时间以及所述任意两个合入请求对应的创建时间确定任意两个所述合入请求之间的超边的权重。

9.根据权利要求8所述的方法，其特征在于，计算每个修改文件集合中任意两个修改文件之间的相似度，包括：

获取每个修改文件集合中的修改文件的路径；

根据任意两个修改文件的路径确定任意两个修改文件的相同前缀长度和每个修改文件的路径深度；

根据所述任意两个修改文件的前缀长度和所述任意两个修改文件的路径深度确定任意两个修改文件之间的相似度。

10.一种超图构建装置，其特征在于，包括：

获取模块，用于获取代码评审数据；

确定模块，用于根据所述代码评审数据确定至少两个目标节点，其中，所述目标节点包括：合入请求、开发者信息以及评审者信息；

构建模块，用于根据所述合入请求和所述评审者信息之间的关系、所述合入请求和所述开发者信息之间的关系以及任意两个所述合入请求之间的关系构建目标超图。

11.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述处理器实现如权利要求1-9中任一所述的方法。

12.一种包含计算机程序的计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被一个或多个处理器执行时实现如权利要求1-9中任一所述的方法。

Images