CN115729606A - 研发隐患分析方法、装置、设备及介质 - Google Patents

Abstract

本申请的实施方式提供了一种研发隐患分析方法、装置、设备及介质，涉及计算机技术领域。该方法可以对正处于研发阶段的项目版本进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

Description

研发隐患分析方法、装置、设备及介质

技术领域

本申请的实施方式涉及计算机技术领域，更具体地，本申请的实施方式涉及研发隐患分析方法、研发隐患分析装置、电子设备以及计算机可读存储介质。

背景技术

在研发领域，每一个项目版本可能都需要多个研发工程师共同配合研发，以在交付节点完成交付。在一个项目版本的研发过程中，各个研发工程师可以根据自身对应的研发任务，提交版本对应的代码，进而，通过整合各个研发工程师提交的代码可以得到该项目版本对应的完整代码。

在完成对于该项目版本的研发之后，一般会通过对于完整代码的功能性测试来发掘该项目版本对应的功能缺陷。但是，基于研发的紧迫性，研发工程师有时会通过非常规的手段完成该项目版本，而通过非常规手段完成的项目版本可能会存在很多隐患(如，代码实现逻辑不佳导致代码可维护性差等)。

在相关技术中，通常只能在研发完成之后对于正式项目版本进行功能测试，暂时还无法发掘项目在研发过程中存在的问题，因此，容易导致研发过程中的问题影响项目的上线效果。基于此，本申请认为，如何发掘研发过程中存在的隐患是当前亟需解决的问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解，因此，不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

基于上述问题，本申请做出了有针对性的改进，提供了研发隐患分析方法、研发隐患分析装置、电子设备以及计算机可读存储介质，可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

根据本申请实施例的第一方面，公开了一种研发隐患分析方法，包括：

获取当前项目版本对应的研发提交记录；

根据研发提交记录生成当前项目版本对应的研发隐患分析报告；

上报研发隐患分析报告。

在一个实施例中，基于前述方案，获取当前项目版本对应的研发提交记录，包括：

获取项目清单中各项目对应的仓库地址；

根据仓库地址获取各项目的当前项目版本；

获取预设周期内各当前项目版本对应的研发提交记录。

在一个实施例中，基于前述方案，根据研发提交记录生成当前项目版本对应的研发隐患分析报告，包括：

获取研发提交记录对应的项目文件；

根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，获取研发提交记录对应的项目文件，包括：

获取当前项目版本对应的源代码；

从源代码中获取与研发提交记录对应的目标代码；

根据目标代码和研发提交记录生成项目文件。

在一个实施例中，基于前述方案，根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告，包括：

将项目文件解析为语法树；

基于语法树中限定的函数节点关系计算对应于项目文件的复杂度；

根据研发提交记录的数量确定提交频率；

根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告，包括：

根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告，包括：

若复杂度大于预设复杂度而提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；

若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则生成包含研发任务异常提示的研发隐患分析报告；

若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；

若提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。

在一个实施例中，基于前述方案，上报研发隐患分析报告，包括：

在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。

在一个实施例中，基于前述方案，上报研发隐患分析报告之后，方法还包括：

从项目清单中确定研发隐患分析报告对应的项目的负责人信息；

基于负责人信息将研发隐患分析报告发送至负责人端。

根据本申请实施例的第二方面，公开了一种研发隐患分析装置，包括：

信息获取单元，用于获取当前项目版本对应的研发提交记录；

报告生成单元，用于根据研发提交记录生成当前项目版本对应的研发隐患分析报告；

上报单元，用于上报研发隐患分析报告。

在一个实施例中，基于前述方案，信息获取单元获取当前项目版本对应的研发提交记录，包括：

获取项目清单中各项目对应的仓库地址；

根据仓库地址获取各项目的当前项目版本；

获取预设周期内各当前项目版本对应的研发提交记录。

在一个实施例中，基于前述方案，报告生成单元根据研发提交记录生成当前项目版本对应的研发隐患分析报告，包括：

获取研发提交记录对应的项目文件；

根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，报告生成单元获取研发提交记录对应的项目文件，包括：

获取当前项目版本对应的源代码；

从源代码中获取与研发提交记录对应的目标代码；

根据目标代码和研发提交记录生成项目文件。

在一个实施例中，基于前述方案，报告生成单元根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告，包括：

将项目文件解析为语法树；

基于语法树中限定的函数节点关系计算对应于项目文件的复杂度；

根据研发提交记录的数量确定提交频率；

根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，报告生成单元根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告，包括：

根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告。

在一个实施例中，基于前述方案，报告生成单元根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告，包括：

若复杂度大于预设复杂度而提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；

若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则生成包含研发任务异常提示的研发隐患分析报告；

若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；

若提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。

在一个实施例中，基于前述方案，上报单元上报研发隐患分析报告，包括：

在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。

在一个实施例中，基于前述方案，装置还包括：

报告发送单元，用于在上报单元上报研发隐患分析报告之后，从项目清单中确定研发隐患分析报告对应的项目的负责人信息；基于负责人信息将研发隐患分析报告发送至负责人端。

根据本申请实施例的第三方面，公开了一种电子设备，包括：处理器；以及存储器，存储器上存储有计算机可读指令，计算机可读指令被处理器执行时实现如第一方面公开的研发隐患分析方法。

根据本申请实施例的第四方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当计算机可读指令被计算机的处理器执行时，使计算机执行根据本申请第一方面公开的研发隐患分析方法。

本申请实施例可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，其中：

图1示出的是根据本申请一示例实施方式的研发隐患分析方法的流程示意图；

图2示出的是根据本申请一示例实施方式的项目清单示意图；

图3示出的是根据本申请一示例实施方式的当前项目版本与研发提交记录之间关系的示意图；

图4示出的是根据本申请另一示例实施方式的研发隐患分析方法的流程示意图；

图5示出的是根据本申请一示例实施方式的研发隐患分析装置的结构框图；

图6示出的是根据本申请另一可选示例实施方式的研发隐患分析装置的结构框图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本申请的实施方式可以实现为一种装置、设备、方法或计算机程序产品。因此，本申请可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本申请的实施方式，提出了一种研发隐患分析方法、研发隐患分析装置、电子设备以及计算机可读存储介质。

附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本申请的若干代表性实施方式，详细阐释本申请的原理和精神。

发明概述

在项目研发过程中，通常需要多个研发人员配合实现不同的需求。一个项目可以包含多个项目文件，不同的研发人员可以根据各自对应的研发任务，修改相应的项目文件并提交，在项目交付节点到达时，可以将各研发人员提交的项目文件覆盖到主代码上，得到最终的项目版本。

在相关技术中，通常只能够对于最终的项目版本进行功能测试，例如，该最终的项目版本的预期功能包括10个，在得到最终的项目版本之后，测试人员会测试该最终的项目版本是否能够实现10个预期功能，如果均能实现，则代表该最终的项目版本研发成功。

但是，在实际研发工作中，研发人员通常会面临需求实现难度大、交付时间紧迫等问题，在这种情况下，研发过程可能会面临如下问题：1、研发人员关闭了代码规范检测开关，进而通过不规范的编写方式编写出代码2、同一研发人员需要同时参与多个项目版本的开发，研发人员大概率会陷入频繁加班、疲劳等境地，导致编写的代码质量不佳3、由于研发人员自身能力不足，导致代码编写进度难以推进。

上述问题无疑会对最终项目版本的质量造成无法估量的不良影响(如，代码维护难度大、最终项目版本上线后频繁接收到用户反馈的报错信息等)，但是，在相关技术中，通常无法检查研发过程中存在的问题，导致这些问题无法被及时发现。

基于上述问题，申请人想到可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

应用场景总览

需要注意的是，下述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。相反，本申请的实施方式可以应用于适用的任何场景。

在项目研发过程中，可以及时地、频繁地获取到当前项目版本的提交记录，对于单次获取到的一个或多个提交记录可以进行隐患分析，从而生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以记载基于本次获取的提交记录分析出的研发隐患，从而通过上报研发隐患分析报告的方式，使得相关人员可以及时得知该研发过程中存在的隐患，从而便于相关人员及时采取措施解决隐患。并且，基于本申请公开的技术方案，还可以对多个项目同时采取上述手段进行隐患监控，以实现处于研发阶段的各项目的实时监控，方便各项目的相关人员及时了解到其负责的项目面临的隐患，以便其及时采取相应的措施进行应对，避免项目隐患对后续项目上线造成不良影响。

示例性方法

下面结合上述的应用场景，参考图1～图4来描述根据本申请示例性实施方式的研发隐患分析方法。

请参阅图1，图1示出的是根据本申请一示例实施方式的研发隐患分析方法的流程示意图，该研发隐患分析方法可以由服务器或终端设备来实现。

如图1所示，根据本申请的一个实施例的研发隐患分析方法包括：

步骤S110：获取当前项目版本对应的研发提交记录。

步骤S120：根据研发提交记录生成当前项目版本对应的研发隐患分析报告。

步骤S130：上报研发隐患分析报告。

实施图1所示的研发隐患分析方法，可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

下面对这些步骤进行详细描述。

在步骤S110中，获取当前项目版本对应的研发提交记录。

具体地，当检测到处于研发过程中的项目版本时，可以获取该当前项目版本对应的研发提交记录，当前项目版本可以理解为该项目的最新版本，即，需要上线但还未上线的版本，非最新项目版本是旧版本，即，已经上线的版本，不属于处于研发过程中的项目版本，因此对于非最新项目版本无需进行隐患监控。

此外，对于研发提交记录的数量，本申请实施例不作限定。当存在多条研发提交记录时，多条研发提交记录可以来自于不同的研发端也可以来自于相同的研发端；其中，不同的研发端可以理解为不同研发人员的终端也可以理解为不同研发小组的终端或者其他形式，本申请实施例不作限定。

其中，研发提交记录可以用于记载：提交该研发提交记录的研发端标识、修改的内容(如，将“xxx”修改为“yyy”)、新增的内容(如，在第433行增加“SSS”)、删除的内容(如，将第433中的“nnn”删除)、提交的时间(如，2022-1-1)等，本申请实施例不作限定。

作为一种可选的实施例，获取当前项目版本对应的研发提交记录，包括：获取项目清单中各项目对应的仓库地址；根据仓库地址获取各项目的当前项目版本；获取预设周期内各当前项目版本对应的研发提交记录。这样可以实现对于项目清单中的多个项目的同时监控，通过获取到各项目的研发提交记录，可以进一步实现对于各项目的研发隐患分析，从而有利于各项目在研发过程中存在的隐患被相关人员及时获知并解决。

具体地，可以获取用于记录正处于研发过程中的各项目的项目清单，项目清单可以包括但不限于：各项目对应的仓库地址(git)、各项目对应的负责人信息；其中，负责人信息可以表示为负责人手机号、负责人社交账号、负责人终端IP等，本申请实施例不作限定。其中，仓库地址(git)可以用于存储相应当前项目版本对应的源代码等其他相关信息。

进而，可选的，根据仓库地址获取各项目的当前项目版本，包括：根据仓库地址从代码版本管理托管平台(如，gitlab)中获取到各项目的当前项目版本，例如，项目A对应的当前项目版本为2.0、项目B对应的当前项目版本为14.0、项目C对应的当前项目版本为5.0、项目D对应的当前项目版本为2.0。其中，当前项目版本的表示方式可以为数值、符号、字符等，本申请不作限定。

此外，可选的，获取预设周期内各当前项目版本对应的研发提交记录，包括：可以按照预设周期获取各当前项目版本对应的研发提交记录，预设周期可以设定为任意长度，如，1天、1周等。举例来说，按照预设周期获取各当前项目版本对应的研发提交记录，可以理解为，每一周对各当前项目版本对应的研发提交记录进行一次获取，针对每个当前项目版本，获取的结果包括截至当前时间前的一周内(如，2022-1-1～2022-1-7)所有的研发提交记录，即，可以获取到每个项目的当前项目版本在2022-1-1～2022-1-7内对应的研发提交记录，对于不同的当前项目版本来说，在2022-1-1～2022-1-7内的研发提交记录数量可以是不同的。

请参阅图2，图2示出的是根据本申请一示例实施方式的项目清单示意图。如图2所示，项目清单200可以包括项目1-仓库地址211、项目1-负责人信息212；项目2-仓库地址221、项目2-负责人信息222；……；项目n-仓库地址231、项目n-负责人信息232；其中，n为正整数，n可以表征处于研发过程中的项目的总数量。

具体地，图2示出的是一种对于项目清单200的示例，在是实际应用过程中，本申请对于项目清单200中记录的项目的数量不作限定。在图2中，项目1-仓库地址211、项目1-负责人信息212；项目2-仓库地址221、项目2-负责人信息222；项目n-仓库地址231、项目n-负责人信息232均为成对存储的，例如，项目1-仓库地址211、项目1-负责人信息212是一对，可以进行对应存储。基于该项目清单200，可以确定需要隐患分析的项目有哪些以及需要隐患分析的项目的仓库地址和负责人信息。

请参阅图3，图3示出的是根据本申请一示例实施方式的当前项目版本与研发提交记录之间关系的示意图。如图3所示，以图2多个项目中的一个项目为例，主代码300可以对应于项目版本(1.0)310、项目版本(2.0)320、项目版本(3.0)330、项目版本(4.0)340，其中，主代码300是初始研发的产品代码，代表了项目产品，针对该项目产品可以进行不断的迭代，从而产生了项目版本(1.0)310、项目版本(2.0)320、项目版本(3.0)330。新的项目版本对应的提交记录覆盖旧有的版本可以得到新的项目版本的代码。

在图3的示例中，可以理解的是，项目版本(4.0)340是该项目产品对应的最新版本(即，前述的当前项目版本)，针对该项目版本(4.0)340，各个研发端可以依据各自对应的研发任务提交代码，在本申请中，可以以预设周期(如，1天)为单位，周期性地获取项目版本(4.0)340对应的提交记录。

以图3为例，在预设周期341获取到的提交记录包括：研发端A-提交记录3411、研发端A-提交记录3412、研发端C-提交记录3413、研发端F-提交记录3414；在预设周期342获取到的提交记录包括：研发端C-提交记录3421、研发端C-提交记录3422、研发端C-提交记录3423、研发端A-提交记录3423、研发端A-提交记录3424、研发端A-提交记录3425、研发端A-提交记录3426。

可见，对于同一研发端来说，可以针对同一个项目的当前项目版本多次提交代码，在不同的预设周期内，可以包含不同数量的提交记录。

在步骤S120中，根据研发提交记录生成当前项目版本对应的研发隐患分析报告。

具体地，研发隐患分析报告可以表征当前研发进程中可能存在的一个或多个问题。

作为一种可选的实施例，根据研发提交记录生成当前项目版本对应的研发隐患分析报告，包括：获取研发提交记录对应的项目文件；根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告。这样可以实现基于研发提交记录和项目文件的研发隐患分析，研发提交记录通常表征了当前项目版本的提交情况，项目文件表征了提交的结果，基于研发提交记录和项目文件进行研发隐患分析可以得到更为准确的研发隐患分析报告，该研发隐患分析报告可以更详细、准确地描述当前项目版本可能存在的研发隐患。

具体地，研发提交记录对应的项目文件中具体包含的内容是代码，不同的研发提交记录对应的项目文件可以是不同的。

作为一种可选的实施例，获取研发提交记录对应的项目文件，包括：获取当前项目版本对应的源代码；从源代码中获取与研发提交记录对应的目标代码；根据目标代码和研发提交记录生成项目文件。这样可以从源代码中获取目标代码，基于目标代码和研发提交记录得到项目文件，项目文件即为研发提交记录对应的修改后的项目文件，通过对于该项目文件的分析，可以准确确定出当前项目版本的研发隐患。

具体地，可以从代码版本管理托管平台(如，gitlab)中获取到当前项目版本对应的源代码并将获取到的源代码存储与本地的服务器，在需要对研发提交记录进行分析时(即，需要用到该源代码时)可以直接从本地的服务器读取，这样可以提升对于研发隐患分析的效率。此处的源代码可以理解为项目上线的最后一个版本对应的源代码。

源代码包含了该项目中所有项目文件的代码总和，即，当前项目版本是在该源代码的基础上进行开发的，因此，获取该源代码可以便于确定出项目文件。其中，源代码可以表示为JSON等形式，本申请实施例不作限定，JSON是一种轻量级的数据交换格式，易于阅读和编写，可以在多种语言之间进行数据交换。

其中，由于研发提交记录记载了研发人员的对于代码的详细修改内容，因此，从源代码中获取与研发提交记录对应的目标代码，包括：基于研发提交记录对应的修改内容确定该研发提交记录所修改的原项目文件，从源代码中获取到该原项目文件对应的代码，作为目标代码。

进而，根据目标代码和研发提交记录生成项目文件，包括：基于研发提交记录对应的修改内容覆盖该目标代码，以得到项目文件，项目文件表征的是研发提交记录对应的修改结果。

作为一种可选的实施例，根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告，包括：将项目文件解析为语法树；基于语法树中限定的函数节点关系计算对应于项目文件的复杂度；根据研发提交记录的数量确定提交频率；根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告。这样可以基于语法树实现对于代码复杂度的高效计算，以及，基于复杂度和提交频率可以生成更为准确的研发隐患分析报告。

具体地，可以将包含代码的项目文件解析为语法树，此处的语法树指的是抽象语法树(abstract syntax tree，AST)或者语法树(syntax tree)，语法树，是源代码的抽象语法结构的树状表现形式，语法树中每个节点可以代表一个函数，语法树可以体现代码中的函数节点关系。

此外，函数节点关系可以包括节点数量N、从根节点(root)到最终子叶的路径数量E、连通分量P，基于语法树中限定的函数节点关系计算对应于项目文件的复杂度，包括：将语法树的节点数量N、从根节点到最终子叶的路径数量E、连通分量P带入表达式V(G)＝E-N+2P，以计算得到项目文件的复杂度V(G)。其中，连通分量P可以设置为常数，如，1，复杂度V(G)可以理解为圈复杂度(Cyclomatic complexity)，圈复杂度可以理解为代码复杂度的衡量标准。

基于步骤：将项目文件解析为语法树，基于语法树中限定的函数节点关系计算对应于项目文件的复杂度。遍历各个项目文件，可以计算得到各个项目文件的复杂度。

作为一种可选的实施例，根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告，包括：根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告。这样可以实现基于多维因素的研发隐患分析，从而有利于生成内容更丰富、隐患分析更精准的研发隐患分析报告。

具体地，研发提交记录中的提交时间可以表征该研发提交记录是何时的提交的，代码语法规则可以用于限定代码的编写规则(例如，单个需求的实现逻辑不能超过50行)，代码语法规则中可以包括一条或多条规则，本申请实施例不作限定。

作为一种可选的实施例，根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告，包括：

若复杂度大于预设复杂度而提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；

若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则生成包含研发任务异常提示的研发隐患分析报告；

若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；

若提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。这样可以实现对于代码异常提示、研发任务异常提示、异常提交提示、项目延期提示的多类研发隐患的分析，已实现对于研发隐患的更全面覆盖，避免漏检研发隐患。

其中，研发隐患分析报告可以包括文本、图表等任意一种或多种表示形式。具体地，若复杂度大于预设复杂度而提交频率小于上限频率，则表示代码质量较低；若复杂度大于预设复杂度且提交频率大于上限频率，则表示需求研发难度超出了研发人员的能力；来自多种项目的研发提交记录对应于同一研发端，表示了同一个研发人员/研发小组在同时开发多个项目，可能会存在研发任务过重的问题；对应于同一研发端的多个提交时间晚于预设时间(如，晚上10：00)，表示了同一个研发人员/研发小组在预设周期内的针对同一项目/不同项目的多次提交时间(可以理解为，大于等于两次)都晚于预设时间，可能会存在研发任务过重的问题；对应于同一项目的多个提交时间晚于预设时间，则表示对于同一项目的多个研发人员都经常在晚于预设时间的时间点提交代码，可能会存在研发人员加班情况严重的问题。

在步骤S130中，上报研发隐患分析报告。

具体地，研发隐患分析报告可以上报于云平台、系统、特定的终端等，本申请实施例不作限定。

作为一种可选的实施例，上报研发隐患分析报告，包括：在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。这样可以便于登录项目管理平台的管理人员可以直观地了解到各个项目的研发隐患分析报告，从而便于其做出及时的干预，避免当前项目版本交付后才发现问题。

具体地，项目管理平台可以用于查看各个项目的当前项目版本的研发进度、各预设周期对应的研发隐患分析报告等信息。管理人员通过登录项目管理平台可以横向了解一个项目的当前项目版本在每个预设周期内的研发隐患分析报告，以便其对当前项目版本的研发团队进行能力评价，以及可以纵向了解各项目在同一预设周期内的研发隐患分析报告，以便其评估各当前项目版本的研发难度。

作为一种可选的实施例，上报研发隐患分析报告之后，方法还包括：从项目清单中确定研发隐患分析报告对应的项目的负责人信息；基于负责人信息将研发隐患分析报告发送至负责人端。这样可以点对点地将研发隐患分析报告发送至对应的负责人端，以免负责人未及时登录项目管理平台而无法及时获知研发隐患，从而可以提升负责人获知研发隐患分析报告的及时性。

具体地，负责人端可以理解为负责人的手机、电脑、智能手表等，本申请实施例不作限定。

进一步地，请参阅图4，图4示出的是根据本申请另一示例实施方式的研发隐患分析方法的流程示意图。如图4所示，该研发隐患分析方法包括：

步骤S400：获取项目清单中各项目对应的仓库地址，并根据仓库地址获取各项目的当前项目版本，进而获取预设周期内各当前项目版本对应的研发提交记录。

其中，需要说明的是，对于上述各当前项目版本中任一当前项目版本，均可以执行下述步骤：

步骤S410：获取当前项目版本对应的源代码，并从源代码中获取与研发提交记录对应的目标代码，根据目标代码和研发提交记录生成项目文件。

步骤S420：将项目文件解析为语法树，并基于语法树中限定的函数节点关系计算对应于项目文件的复杂度，并根据研发提交记录的数量确定提交频率。

步骤S430：根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则分析当前项目版本对应的问题。若复杂度大于预设复杂度而提交频率小于上限频率，则执行步骤S440；若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则执行步骤S450；若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则执行步骤S460；若提交频率低于下限频率，则执行步骤S470。

步骤S440：生成包含代码异常提示的研发隐患分析报告。

步骤S450：生成包含研发任务异常提示的研发隐患分析报告。

步骤S460：生成包含异常提交提示的研发隐患分析报告。

步骤S470：生成包含项目延期提示的研发隐患分析报告。

步骤S480：在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。

步骤S490：从项目清单中确定研发隐患分析报告对应的项目的负责人信息，基于负责人信息将研发隐患分析报告发送至负责人端。

需要说明的是，步骤S400～步骤S490与图1所示的各步骤及其实施例相对应，针对步骤S400～步骤S490的具体实施方式，请参阅图1所示的各步骤及其实施例，此处不再赘述。

可见，实施图4所示的方法，可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

示例性介质

在介绍了本申请示例性实施方式的方法之后，接下来，对本申请示例性实施方式的介质进行说明。

在一些可能的实施方式中，本申请的各个方面还可以实现为一种介质，其上存储有程序代码，当程序代码被设备的处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本申请各种示例性实施方式的研发隐患分析方法中的步骤。

具体地，所述设备的处理器执行所述程序代码时用于实现如下步骤：获取当前项目版本对应的研发提交记录；根据研发提交记录生成当前项目版本对应的研发隐患分析报告；上报研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：获取项目清单中各项目对应的仓库地址；根据仓库地址获取各项目的当前项目版本；获取预设周期内各当前项目版本对应的研发提交记录。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：获取研发提交记录对应的项目文件；根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：获取当前项目版本对应的源代码；从源代码中获取与研发提交记录对应的目标代码；根据目标代码和研发提交记录生成项目文件。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：将项目文件解析为语法树；基于语法树中限定的函数节点关系计算对应于项目文件的复杂度；根据研发提交记录的数量确定提交频率；根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：若复杂度大于预设复杂度而提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则生成包含研发任务异常提示的研发隐患分析报告；若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；若提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。

在本申请的一些实施方式中，所述设备的处理器执行所述程序代码时还用于实现如下步骤：从项目清单中确定研发隐患分析报告对应的项目的负责人信息；基于负责人信息将研发隐患分析报告发送至负责人端。

需要说明的是：上述的介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

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

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

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

示例性装置

在介绍了本申请示例性实施方式的介质之后，接下来，参考图5对本申请示例性实施方式的研发隐患分析装置进行说明。

请参阅图5，图5示出的是根据本申请一示例实施方式的研发隐患分析装置的结构框图。如图5所示，本申请一示例实施方式的研发隐患分析装置500包括：信息获取单元501、报告生成单元502、上报单元503，其中：

信息获取单元501，用于获取当前项目版本对应的研发提交记录；

报告生成单元502，用于根据研发提交记录生成当前项目版本对应的研发隐患分析报告；

上报单元503，用于上报研发隐患分析报告。

可见，实施图5所示的装置，可以对正处于研发阶段的项目版本(即，当前项目版本)进行研发提交记录提取，对于这些处于研发阶段的项目版本来说，通常会存在多个研发提交记录，通过对这些研发提交记录进行分析，可以及时生成当前项目版本对应的研发隐患分析报告，研发隐患分析报告可以暴露研发过程中可能存在的隐患，进而，通过对于研发隐患分析报告的上报，可以使得相关人员及时了解到当前项目版本在研发过程中有可能存在的问题，便于相关人员及时介入以解决这些问题，从而保证当前项目版本对应的代码的严谨性和合理性，避免代码逻辑性不佳或者编写方式不正规导致的后续维护难等问题。

在一个实施例中，基于前述方案，信息获取单元501获取当前项目版本对应的研发提交记录，包括：

获取项目清单中各项目对应的仓库地址；

根据仓库地址获取各项目的当前项目版本；

获取预设周期内各当前项目版本对应的研发提交记录。

可见，实施该可选的实施例，可以实现对于项目清单中的多个项目的同时监控，通过获取到各项目的研发提交记录，可以进一步实现对于各项目的研发隐患分析，从而有利于各项目在研发过程中存在的隐患被相关人员及时获知并解决。

在一个实施例中，基于前述方案，报告生成单元502根据研发提交记录生成当前项目版本对应的研发隐患分析报告，包括：

获取研发提交记录对应的项目文件；

根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告。

可见，实施该可选的实施例，可以实现基于研发提交记录和项目文件的研发隐患分析，研发提交记录通常表征了当前项目版本的提交情况，项目文件表征了提交的结果，基于研发提交记录和项目文件进行研发隐患分析可以得到更为准确的研发隐患分析报告，该研发隐患分析报告可以更详细、准确地描述当前项目版本可能存在的研发隐患。

在一个实施例中，基于前述方案，报告生成单元502获取研发提交记录对应的项目文件，包括：

获取当前项目版本对应的源代码；

从源代码中获取与研发提交记录对应的目标代码；

根据目标代码和研发提交记录生成项目文件。

可见，实施该可选的实施例，可以从源代码中获取目标代码，基于目标代码和研发提交记录得到项目文件，项目文件即为研发提交记录对应的修改后的项目文件，通过对于该项目文件的分析，可以准确确定出当前项目版本的研发隐患。

在一个实施例中，基于前述方案，报告生成单元502根据研发提交记录和项目文件生成当前项目版本对应的研发隐患分析报告，包括：

将项目文件解析为语法树；

基于语法树中限定的函数节点关系计算对应于项目文件的复杂度；

根据研发提交记录的数量确定提交频率；

根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告。

可见，实施该可选的实施例，可以基于语法树实现对于代码复杂度的高效计算，以及，基于复杂度和提交频率可以生成更为准确的研发隐患分析报告。

在一个实施例中，基于前述方案，报告生成单元502根据提交频率和复杂度生成当前项目版本对应的研发隐患分析报告，包括：

根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告。

可见，实施该可选的实施例，可以实现基于多维因素的研发隐患分析，从而有利于生成内容更丰富、隐患分析更精准的研发隐患分析报告。

在一个实施例中，基于前述方案，报告生成单元502根据提交频率、复杂度、研发提交记录中的提交时间、代码语法规则生成当前项目版本对应的研发隐患分析报告，包括：

若复杂度大于预设复杂度而提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；

若复杂度大于预设复杂度且提交频率大于上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于预设时间，则生成包含研发任务异常提示的研发隐患分析报告；

若复杂度小于预设复杂度而提交频率大于上限频率、或者基于代码语法规则检测到项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；

若提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。

可见，实施该可选的实施例，可以实现对于代码异常提示、研发任务异常提示、异常提交提示、项目延期提示的多类研发隐患的分析，已实现对于研发隐患的更全面覆盖，避免漏检研发隐患。

在一个实施例中，基于前述方案，上报单元503上报研发隐患分析报告，包括：

在项目管理平台上发布研发隐患分析报告；其中，项目管理平台用于展示各项目对应的研发隐患分析报告。

可见，实施该可选的实施例，可以便于登录项目管理平台的管理人员可以直观地了解到各个项目的研发隐患分析报告，从而便于其做出及时的干预，避免当前项目版本交付后才发现问题。

在一个实施例中，基于前述方案，装置还包括：

报告发送单元，用于在上报单元503上报研发隐患分析报告之后，从项目清单中确定研发隐患分析报告对应的项目的负责人信息；基于负责人信息将研发隐患分析报告发送至负责人端。

可见，实施该可选的实施例，可以点对点地将研发隐患分析报告发送至对应的负责人端，以免负责人未及时登录项目管理平台而无法及时获知研发隐患，从而可以提升负责人获知研发隐患分析报告的及时性。

应当注意，尽管在上文详细描述中提及了研发隐患分析装置的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

示例性电子设备

在介绍了本申请示例性实施方式的方法、介质和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图6来描述根据本申请的又一可选示例实施方式的研发隐患分析装置600。图6显示的研发隐患分析装置600仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，研发隐患分析装置600以电子设备的形式表现。研发隐患分析装置600的组件可以包括但不限于：上述至少一个处理单元610、上述至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元610执行，使得所述处理单元610执行本说明书上述示例性方法的描述部分中描述的根据本申请各种示例性实施方式的步骤。例如，所述处理单元610可以执行如图1和图4中所示的各个步骤。

存储单元620可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)6201和/或高速缓存存储单元6202，还可以进一步包括只读存储单元(ROM)6203。

存储单元620还可以包括具有一组(至少一个)程序模块6205的程序/实用工具6204，这样的程序模块6205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线630可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

研发隐患分析装置600也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与研发隐患分析装置600交互的设备通信，和/或与使得该研发隐患分析装置600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，研发隐患分析装置600还可以通过网络适配器660与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图6所示，网络适配器660通过总线630与研发隐患分析装置600的其它模块通信。应当明白，尽管图中未示出，可以结合研发隐患分析装置600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。

虽然已经参考若干具体实施方式描述了本申请的精神和原理，但是应该理解，本申请并不限于所发明的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本申请旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种研发隐患分析方法，其特征在于，包括：

获取当前项目版本对应的研发提交记录；

根据所述研发提交记录生成所述当前项目版本对应的研发隐患分析报告；

上报所述研发隐患分析报告。

2.根据权利要求1所述的方法，其特征在于，获取当前项目版本对应的研发提交记录，包括：

获取项目清单中各项目对应的仓库地址；

根据所述仓库地址获取所述各项目的当前项目版本；

获取预设周期内各当前项目版本对应的研发提交记录。

3.根据权利要求1所述的方法，其特征在于，根据所述研发提交记录生成所述当前项目版本对应的研发隐患分析报告，包括：

获取所述研发提交记录对应的项目文件；

根据所述研发提交记录和所述项目文件生成所述当前项目版本对应的研发隐患分析报告。

4.根据权利要求3所述的方法，其特征在于，获取所述研发提交记录对应的项目文件，包括：

获取当前项目版本对应的源代码；

从所述源代码中获取与所述研发提交记录对应的目标代码；

根据所述目标代码和所述研发提交记录生成项目文件。

5.根据权利要求3所述的方法，其特征在于，根据所述研发提交记录和所述项目文件生成所述当前项目版本对应的研发隐患分析报告，包括：

将所述项目文件解析为语法树；

基于所述语法树中限定的函数节点关系计算对应于所述项目文件的复杂度；

根据所述研发提交记录的数量确定提交频率；

根据所述提交频率和所述复杂度生成所述当前项目版本对应的研发隐患分析报告。

6.根据权利要求5所述的方法，其特征在于，根据所述提交频率和所述复杂度生成所述当前项目版本对应的研发隐患分析报告，包括：

根据所述提交频率、所述复杂度、所述研发提交记录中的提交时间、代码语法规则生成所述当前项目版本对应的研发隐患分析报告。

7.根据权利要求6所述的方法，其特征在于，根据所述提交频率、所述复杂度、所述研发提交记录中的提交时间、代码语法规则生成所述当前项目版本对应的研发隐患分析报告，包括：

若所述复杂度大于预设复杂度而所述提交频率小于上限频率，则生成包含代码异常提示的研发隐患分析报告；

若所述复杂度大于预设复杂度且所述提交频率大于所述上限频率、或者来自多种项目的研发提交记录对应于同一研发端、或者对应于同一研发端的多个提交时间晚于预设时间、或者对应于同一项目的多个提交时间晚于所述预设时间，则生成包含研发任务异常提示的研发隐患分析报告；

若所述复杂度小于预设复杂度而所述提交频率大于所述上限频率、或者基于代码语法规则检测到所述项目文件中存在异常格式，则生成包含异常提交提示的研发隐患分析报告；

若所述提交频率低于下限频率，则生成包含项目延期提示的研发隐患分析报告。

8.一种研发隐患分析装置，其特征在于，包括：

信息获取单元，用于获取当前项目版本对应的研发提交记录；

报告生成单元，用于根据所述研发提交记录生成所述当前项目版本对应的研发隐患分析报告；

上报单元，用于上报所述研发隐患分析报告。

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

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如权利要求1至7中任一项所述的研发隐患分析方法。

10.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的研发隐患分析方法。

Images