代码审查方法及装置与流程

本公开涉及计算机领域，尤其涉及一种代码审查方法及装置。

背景技术：

在开发人员将编写的代码提交至代码仓库之前，通常需要对代码进行审查，以保证代码质量。现有技术中，通常是通过人工评审代码，以发现代码中的错误，这种代码检查方法不仅待码审查质量完全依赖于评审者的审查水平，且代码审核不够全面，容易导致提交至代码仓库的代码质量较差。

可见，现有技术中存在因代码审核完全依赖于评审者，导致提交至代码仓库的代码质量较差的问题。

技术实现要素：

本公开实施例提供一种代码审查方法及装置，以解决因代码审核完全依赖于评审者，导致提交至代码仓库的代码质量较差的问题。

第一方面，本公开提供了一种代码审查方法，该方法包括：

接收待向代码仓库提交的代码；

对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；

在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。

可选的，所述对所述代码执行目标检查，包括：

按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查；

其中，仅在所述代码通过第一检查的情况下，对所述代码执行第二检查，所述第一检查的优先级高于所述第二检查的优先级，所述第一检查和所述第二检查为所述目标检查中任意两个优先级相邻的检查。

可选的，所述对所述代码执行目标检查之后，所述方法还包括：

在所述代码未通过所述目标检查中的第三检查的情况下，输出修改提示信息；

其中，所述第三检查为所述目标检查中任一检查，所述修改提示信息包括所述第一检查所检测出的错误信息和/或针对所检测出的错误信息的修改建议。

可选的，所述接收待向代码仓库提交的代码，包括：

通过gerrit接收待向代码仓库提交的代码；

所述对所述代码执行目标检查，包括：

通过jenkins对所述代码执行自动化检查。

可选的，所述通过jenkins对所述代码执行自动化检查，包括如下至少一项：

当所述自动化检查包括提交说明检查时，通过jenkins调用预设脚本程序，检查所述代码的提交说明的格式是否满足预设格式要求，并在所述提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查；

当所述自动化检查包括静态代码检查时，通过jenkins调用静态检查工具对所述代码执行静态代码检查；

当所述自动化检查包括编译检查时，通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查。

可选的，所述自动化检查还包括自动化测试检查；

所述通过jenkins对所述代码执行自动化检查，还包括：

通过jenkins调用测试服务器对编译后的代码执行自动化测试。

可选的，所述对所述代码执行目标检查之后，所述方法还包括：

在所述代码通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第一值；

在所述代码未通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第二值；

其中，所述第四检查为所述目标检查中的任一检查，所述代码未通过目标检查为：所述目标检查中存在至少一个检查对应的标签值为第二值。

可选的，所述对所述代码执行目标检查，还包括：

向至少一个评审者发送代码审查的通知信息，所述代码审查的通知信息用于通知所述至少一个评审者对所述代码进行审查；

接收所述至少一个评审者针对所述代码的评审结果；

在所述评审结果指示所述代码未通过评审的情况下，确定所述代码未通过人工检查。

第二方面，本公开还提供一种代码审查装置，该装置包括：

接收模块，用于接收待向代码仓库提交的代码；

检查模块，用于对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；

禁止模块，用于在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。

可选的，所述检查模块，包括：

第二检查单元，用于按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查；

其中，仅在所述代码通过第一检查的情况下，对所述代码执行第二检查，所述第一检查的优先级高于所述第二检查的优先级，所述第一检查和所述第二检查为所述目标检查中任意两个优先级相邻的检查。

可选的，所述装置还包括：

输出模块，用于所述对所述代码执行目标检查之后，在所述代码未通过所述目标检查中的第三检查的情况下，输出修改提示信息；

其中，所述第三检查为所述目标检查中任一检查，所述修改提示信息包括所述第一检查所检测出的错误信息和/或针对所检测出的错误信息的修改建议。

可选的，所述接收模块，包括：

第一接收单元，用于通过gerrit接收待向代码仓库提交的代码；

所述检查模块，包括：

第一检查单元，用于通过jenkins对所述代码执行自动化检查。

可选的，所述第一检查单元用于执行如下至少一项：

当所述自动化检查包括提交说明检查时，通过jenkins调用预设脚本程序，检查所述代码的提交说明的格式是否满足预设格式要求，并在所述提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查；

当所述自动化检查包括静态代码检查时，通过jenkins调用静态检查工具对所述代码执行静态代码检查；

当所述自动化检查包括编译检查时，通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查。

可选的，所述自动化检查还包括自动化测试检查；

所述第一检查单元还用于：

通过jenkins调用测试服务器对编译后的代码执行自动化测试。

可选的，所述装置还包括：

第一设置模块，用于所述对所述代码执行目标检查之后，在所述代码通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第一值；

第二设置模块，用于在所述代码未通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第二值；

其中，所述第四检查为所述目标检查中的任一检查，所述代码未通过目标检查为：所述目标检查中存在至少一个检查对应的标签值为第二值。

可选的，所述检查模块，还包括：

发送单元，用于向至少一个评审者发送代码审查的通知信息，所述代码审查的通知信息用于通知所述至少一个评审者对所述代码进行审查；

接收单元，用于接收所述至少一个评审者针对所述代码的评审结果；

确定单元，用于在所述评审结果指示所述代码未通过评审的情况下，确定所述代码未通过人工检查。

第三方面，本公开实施例还提供一种应用处理装置，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述的代码审查方法的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的代码审查方法的步骤。

本公开实施例提供的代码审查方法，通过接收待向代码仓库提交的代码；对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。由于对代码分别执行了自动化检查和人工检查，并在代码未通过检查的情况下，禁止向所述代码仓库提交所述代码，从而可以提高提交至代码仓库的代码的质量。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对本公开实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本公开实施例提供的代码审查方法的流程图；

图2是本公开又一实施例提供的代码审查方法的流程图；

图3是本公开实施例提供的代码审查装置的结构图；

图4是本公开又一实施例提供的代码审查装置的结构图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

为了便于描述，以下对本公开实施例涉及的一些术语进行说明：

gerrit：一种开源的代码审查软件，使用网页界面。具体的，通过gerrit，同一个团队的软件程序员，利用网页浏览器可以相互审阅彼此修改后的程序代码，决定是否能够提交，退回或者继续修改。

jenkins：一个开源软件项目，是基于java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

sonar：一个用于代码质量管理的开源平台，通过插件机制，sonar可以集成不同的测试工具、代码分析工具和持续集成工具。

本公开实施例提供一种代码审查方法。参见图1，图1是本公开实施例提供的代码审查方法的流程图，如图1所示，包括以下步骤：

步骤101、接收待向代码仓库提交的代码。

实际应用中，在用户编写了新的代码或是修改某代码后，会将新生成的代码提交至代码仓库，便于管理和使用。例如，在用户编写了新的应用程序或是某个应用程序的补丁后，可以将新的应用程序或是某个应用程序的补丁上传代码仓库。

本公开实施例中，上述代码可以是增量代码，也即补丁(patch)，也可以是完整代码，例如，某个新开发的应用程序的完整代码。

步骤102、对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项。

本公开实施例中，上述自动化检查是相对于人工评审代码来说的，可以是指通过电子设备自动对代码执行检查。具体的，自动化检查可以包括但不限于提交说明(也即commitmessage)检查、静态代码检查、编译检查和自动化测试检查中的至少两项。

其中，上述提交说明检查可以包括检查提交说明的格式是否满足预设格式要求。上述静态代码检查可以是指不运行被测代码本身，仅通过分析或检查代码的语法、结构、过程、接口等来检查代码的正确性，例如，静态代码检查可以包括检查代码是否存在变量未初始化、空指针引用、数据类型不匹配、数组越界、内存泄漏等中的一项或多项。上述编译检查可以是指检查代码是否可以成功编译。上述自动化测试检查可以是指对编译后的代码进行自动化的软件测试，以测试编译后的代码的功能、性能等。

上述人工检查可以是指人工评审代码。可以理解的是，人工检查可以包括人工利用代码审查(即codereview)工具(例如，gerrit)对代码进行评审，以得到评审结果。

步骤103、在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。

在该步骤中，上述代码通过目标检查可以是指代码同时通过自动化检查和人工检查。具体的，在所述代码通过目标检查的情况下，可以提交代码值代码仓库，而在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码，从而可以提高向代码仓库提交的代码质量。

本公开实施例提供的代码审查方法，通过接收待向代码仓库提交的代码；对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。由于对代码分别执行了自动化检查和人工检查，并在代码未通过检查的情况下，禁止向所述代码仓库提交所述代码，从而可以提高提交至代码仓库的代码的质量。

可选的，上述步骤102，也即所述对所述代码执行目标检查，可以包括：

按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查；

其中，仅在所述代码通过第一检查的情况下，对所述代码执行第二检查，所述第一检查的优先级高于所述第二检查的优先级，所述第一检查和所述第二检查为所述目标检查中任意两个优先级相邻的检查。

本公开实施例中，上述第一检查和第二检查可以为上述目标检查中任意两个优先级相邻的检查。例如，目标检查包括提交说明检查、静态代码检查和人工检查，且优先级从高到低依次为：提交说明检查、静态代码检查和人工检查，则提交说明检查和静态代码检查为优先级相邻的检查，静态代码检查和人工检查也为优先级相邻的检查。

实际应用中，代码中存在一些错误可能会在不同检查中均检测出来，即同一个错误在多个检查中都被检查到，例如，对于空指针引用，在代码静态检查、人工检查和编译检查中均可能检查出对应的错误。因此，为了避免代码中一些错误的重复检查，影响代码检查效率，可以预先为各个检查设置优先级，从而可以按照各个检查的优先级分别对代码执行代码检查。

例如，在自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查的情况下，各个检查的优先级从高到低依次为：提交说明检查，静态代码检查，人工检查，编译检查，自动化测试检查。可以理解的是，各个检查的优先级可以根据实际需求进行合理设置，例如可以根据代码错误的类型、代码错误受重视程度、代码错误的严重程度等情况进行设置优先级顺序等，本公开实施例对此不做限定。此外，需要说明的是，在存在优先级相同的至少两个检查的情况下，需要检查优先级相同的至少两个检查项均通过的情况下，才执行下一检查优先级的检查，例如，静态代码检查和人工检查的优先级相同，且均高于编译检查，则需要分别执行静态代码检查和人工检查，并在静态代码检查和人工检查均通过的情况下，才执行编译检查。

本公开实施例中，仅在代码通过较高检查优先级的检查的情况下，才对代码执行较低检查优先级的检查。需要说明的是，在代码未通过某个检查项之后，用户可以修改代码，此时，可以针对用户修改后的代码重新执行目标检查。

例如，当各个检查的优先级从高到低依次为：提交说明检查，静态代码检查，人工检查，编译检查，自动化测试检查的情况下，则可以先对代码执行提交说明检查，在代码通过提交说明检查的情况下，才对代码执行静态代码检查，否则可以输出提示信息，以提示用户修改提交说明和/或提示用户所检查出的错误信息等；在代码通过静态代码检查的情况下，才对代码执行人工检查，否则可以输出提示信息，以提示用户修改代码中所检查出的错误和/或提示用户所检查出的错误等；在代码通过人工检查的情况下，才对代码执行编译检查，否则可以输出提示信息，以提示用户修改代码中所检查出的错误和/或提示用户所检查出的错误信息等；在代码通过编译检查的情况下，才对代码执行自动化测试检查，否则可以输出提示信息，以提示用户修改代码中所检查出的错误和/或提示用户所检查出的错误等。

本公开实施例按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查，并仅在代码通过较高优先级的检查的情况下，才对代码执行较低优先级的检查，可以在保证代码审查质量的前提下，提高代码审查效率。

可选的，上述步骤102，也即所述对所述代码执行目标检查之后，所述方法还可以包括：

在所述代码未通过所述目标检查中的第三检查的情况下，输出修改提示信息；

其中，所述第三检查为所述目标检查中任一检查，所述修改提示信息包括所述第一检查所检测出的错误信息和/或针对所检测出的错误信息的修改建议。

本公开实施例中，上述第三检查可以是目标检查中任一检查。上述修改建议用于提示用户如何修改所检测出的错误信息，例如，对于数据类型不匹配的错误信息，可以提示用户修改数据类型。

实际应用中，可以输出代码未通过的各个检查的修改提示信息，以便于用户根据修改提示信息对代码进行修改。

可选的，上述步骤101，也即所述接收待向代码仓库提交的代码，可以包括：

通过gerrit接收待向代码仓库提交的代码；

上述步骤102，也即所述对所述代码执行目标检查，可以包括：

通过jenkins对所述代码执行自动化检查。

本公开实施例中，可以预先分别在服务器中配置gerrit和jenkins，从而当用户将待提交至代码仓库的代码提交至gerrit时，可以触发jenkins对所述代码执行自动化检查。

实际应用中，可以在配置有jenkins的服务器(以下简称为jenkins服务器)中集成配置有gerrit的服务器(以下简称为gerrit服务器)，从而jenkins服务器可以监控gerrit服务器是否有代码提交，并可以通过调用其集成的检查工具(例如，静态代码检查工具、编译服务器、测试服务器等)对代码执行自动化检查。

本公开实施例通过gerrit接收待向代码仓库提交的代码，并通过jenkins对所述代码执行自动化检查，不但可以实现代码的自动化检查，而且实现较为简单。

可选的，所述通过jenkins对所述代码执行自动化检查，包括如下至少一项：

当所述自动化检查包括提交说明检查时，通过jenkins调用预设脚本程序，检查所述代码的提交说明的格式是否满足预设格式要求，并在所述提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查；

当所述自动化检查包括静态代码检查时，通过jenkins调用静态检查工具对所述代码执行静态代码检查；

当所述自动化检查包括编译检查时，通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查。

本公开实施例中，上述提交说明(即commitmessage)的格式要求可以根据实际需要进行合理设置。例如，提交说明的格式要求可以包括如下至少一项：

<modle>:<type>:<subject>；

<提交解释>；

[jiraid]；

<signedoff>。

其中，modle表示模块名称，type表示提交的类型，subject表示提交目的的描述。可选的，上述类型(即type)可以包括如下至少一项：feat，fix，refactor，impl，style，docs，test，chore。上述jiraid表示用于缺陷管理的jira标识，上述signedoff表示签名。

可选的，当类型(即type)为feat或fix时，提交说明中需要添加jiraid，并要求有signedoff(即签名)。实际应用中，可以通过预设脚本程序解析提交说明，当发现该提交说明是feat或者fix类型时，会在提交说明里面寻找jiraid字段，如无该字段，则可以确定该项检查不通过。

在一些实施例中，若自动化检查包括提交说明检查，则可以在jenkins服务器中集成预设脚本程序，从而可以通过jenkins调用预设脚本程序对代码的提交说明进行检查。具体的，可以在代码的提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查。例如，在预设格式要求为提交说明中需要包括模块名称(也即modle)和类型(即type)，且当类型为feat或fix时，提交说明中需要添加jiraid的情况下，若代码的提交说明中包括模块名称(也即modle)和类型(即type)，且当类型为feat或fix时，提交说明中包括jiraid，则确定代码通过提交说明检查，否则代码未通过提交说明检查。

在一些实施例中，若自动化检查包括静态代码检查，则可以在jenkins服务器中集成静态代码检查工具，例如，sonar、coverity等。例如，可以将配置有sonar的服务器(以下简称为sonar服务器)或配置有coverity的服务器(以下简称为coverity服务器)等作为jenkins服务器的从服务器，从而jenkins服务器可以调用sonar服务器或coverity服务器等执行静态代码检查。

需要说明的是，静态代码检查规则可根据项目需求进行设置，例如，对于不同的项目，可以设置其对应的问题等级和阈值等，其中，上述阈值用于判断静态代码检查是否通过。

在一些实施例中，若自动化检查包括编译检查，则可以在jenkins服务器中集成编译服务器。例如，可以将编译服务器作为jenkins服务器的从服务器，从而jenkins服务器可以调用编译服务器执行编译检查。具体的，在代码编译成功的情况下，确定所述代码通过编译检查。

可选的，所述代码为增量代码；所述通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查，包括：

通过jenkins调用编译服务器从所述代码仓库下载所述代码的依赖代码；

对所述代码和依赖代码进行打包，得到待编译代码；

对所述待编译代码进行编译；

在所述待编译代码编译成功的情况下，确定所述代码通过编译检查。

本公开实施例中，当代码为增量代码(也即patch)时，编译服务器可以从代码仓库下载代码的依赖代码，对所述代码和依赖代码进行打包，得到待编译代码，并对所述待编译代码进行编译。其中，代码的依赖代码可以是指代码对应的已有版本的程序代码，例如，前一版本的程序代码。

可选的，所述自动化检查还包括自动化测试检查；

所述通过jenkins对所述代码执行自动化检查，还包括：

通过jenkins调用测试服务器对编译后的代码执行自动化测试。

本公开实施例中，若自动化检查包括编译检查，则可以在jenkins服务器中集成自动化测试服务器。例如，可以将自动化测试服务器作为jenkins服务器的从服务器，从而jenkins服务器可以调用自动化测试服务器执行自动化测试检查。其中，上述自动化测试可以包括功能测试、性能测试等。实际应用中，可以根据实际需求编写测试用例，以对编译后的代码执行自动化测试。

可选的，所述对所述代码执行目标检查之后，所述方法还包括：

在所述代码通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第一值；

在所述代码未通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第二值；

其中，所述第四检查为所述目标检查中的任一检查，所述代码未通过目标检查为：所述目标检查中存在至少一个检查对应的标签值为第二值。

本公开实施例中，上述第一值和第二值可以根据实际需求进行设置，例如，第一值为+1，第二值为-1。实际应用中，可以在代码通过某个检查的情况下，将该检查对应的标签值设置为第一值，在代码未通过某个检查的情况下，将该检查对应的标签值设置为第二值。

具体的，在目标检查中的全部检查对应的标签值均为第一值的情况下，也即代码通过目标检查所包括的全部检查的情况下，确定代码通过目标检查，在目标检查中存在至少一个检查对应的标签值为第二值的情况下，也即代码未通过目标检查中至少一项的情况下，确定代码未通过目标检查。

本公开实施例可以基于各个检查对应的标签值确定代码是否目标检查，实现较为简单便捷。

可选的，所述对所述代码执行目标检查，还包括：

向至少一个评审者发送代码审查的通知信息，所述代码审查的通知信息用于通知所述至少一个评审者对所述代码进行审查；

接收所述至少一个评审者针对所述代码的评审结果；

在所述评审结果指示所述代码未通过评审的情况下，确定所述代码未通过人工检查。

本公开实施例中，在接收到待向代码仓库提交的代码的情况下，可以向至少一个评审者发送代码审查的通知信息，以通知所述至少一个评审者对所述代码进行审查。例如，可以通过邮件、短信等方式向至少一个评审者发送代码审查的通知信息。上述至少一个评审者接收到通知信息后，可以对代码进行评审，并可以通过gerrit等提交评审结果。

在一些实施例中，可以为不同的评审者设置不同的评审权限等级，并仅在所有评审者提交的评审结果均指示代码通过评审，且所有评审者中包括评审等级大于或等于预设评审等级的评审者的情况下，确定代码未通过人工检查，否则确定代码未通过人工检查。

实际应用中，可以对不同的评审权限等级的评审者的评审结果，设置不同的标签值，例如，对于第一评审等级的评审者的评审结果，若代码通过评审，则评审结果对应的标签值为+2，若代码未通过评审，则评审结果对应的标签值为-2；对于第二评审等级的评审者的评审结果，若代码通过评审，则评审结果对应的标签值为+1，若代码未通过评审，则评审结果对应的标签值为-1。从而通过标签值可以较为简便的获知各个评审结果对应的评审者的评审权限等级，以及代码是否通过评审。

以下结合示例对本公开实施例提供的代码审查方法进行说明：

参见图2，本公开实施例提供的代码审查方法包括如下步骤：

步骤201、接收提交者提交的代码。

上述代码可以是指待提交至代码仓库的代码。具体的，提交者可以将代码提交至gerrit平台(也即gerrit服务器)。相应的，jenkins可以在监测到gerrit平台上的代码提交事件，可以进行自动化检查，也即提交说明检查、静态代码检查、自动编译检查和自动化测试检查。

步骤202、提交说明检查。

具体的，若通过该检查，则gerrit中该检查的相关标签值为+1，否则为-1。

步骤203、静态代码检查。

该步骤中，可以通过使用sonar等静态检查工具进行静态代码检查，可根据项目需要配置相关检查类型以及阈值，若通过该检查，则gerrit中该检查的相关标签值为+1，否则为-1。

步骤204、自动编译检查。

该步骤中的自动编译检查也即上述的编译检查。具体的，可以通过jenkins从代码仓库中下载代码，打入提交者提交的补丁(即patch)进行编译。上述补丁也即上述的代码。若编译成功，则gerrit中该检查的相关标签值为+1，否则为-1。

步骤205、自动化测试检查。

该步骤中，可以对步骤204编译后的代码进行自动化测试。具体的，可以根据项目需要进行自动化测试配置。若自动化测试成功，则gerrit中该检查的相关标签值为+1，否则为-1。

步骤206、评审者评审。

实际应用中，在提交者提交代码进行自动化检查的同时，也可以发送邮件给相关代码评审者，评审者评审后可在gerrit平台提交评审意见及评审结果，根据评审者权限不同，可对相应评审标签进行+1、-1、+2或-2操作。

步骤207、提交者本地验证确认。

实际应用中，代码的提交者也可以在gerrit平台上面进行代码的验证确认，表示本地已进行过本地的编译及测试，并对相应标签进行+1或-1操作。

步骤208、是否通过检查。

该步骤中，代码通过检查可以是指代码通过所有的检查项。在代码通过检查的情况下，执行步209，否则提交者可以根据检查项的提示信息，对代码进行修改，并重新提交。

例如，在以上检查项对应标签值均不存在-1及-2，且存在具有+2权限的评审者有+2操作的情况下，确定代码通过检查。

步骤209、提交者确认并提交。

该步骤中，仅在确定代码通过所有检查项的情况下，提交者才可以在gerrit平台确认并提交代码至代码仓库。

步骤210、冲突检查。

该步骤中，对代码进行冲突检查，如有冲突，则无法进行入库操作，也即将代码提交至代码仓库，需要提交者本地解决冲突后再次重新提交，否则可以执行步骤212。

步骤211、解决冲突。

步骤212、代码入代码仓库。

本公开实施例可自动化检查提交说明格式、编译、静态代码检查、测试等相关可自动化测试的检查项，同时评审者可把控需求等业务相关的检查。通过本公开实施例提供的代码审查方法，可以提高代码提交质量，减少由于代码提交者疏忽造成的编译失败、空指针访问等相关问题。

参见图3，图3是本公开实施例提供的代码审查装置的结构图。如图3所示，代码审查装置300包括：接收模块301、检查模块302和禁止模块303，其中：

接收模块301，用于接收待向代码仓库提交的代码；

检查模块302，用于对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；

禁止模块303，用于在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。

可选的，所述检查模块，包括：

第二检查单元，用于按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查；

其中，仅在所述代码通过第一检查的情况下，对所述代码执行第二检查，所述第一检查的优先级高于所述第二检查的优先级，所述第一检查和所述第二检查为所述目标检查中任意两个优先级相邻的检查。

可选的，所述装置还包括：

输出模块，用于所述对所述代码执行目标检查之后，在所述代码未通过所述目标检查中的第三检查的情况下，输出修改提示信息；

其中，所述第三检查为所述目标检查中任一检查，所述修改提示信息包括所述第一检查所检测出的错误信息和/或针对所检测出的错误信息的修改建议。

可选的，所述接收模块，包括：

第一接收单元，用于通过gerrit接收待向代码仓库提交的代码；

所述检查模块，包括：

第一检查单元，用于通过jenkins对所述代码执行自动化检查。

可选的，所述第一检查单元用于执行如下至少一项：

当所述自动化检查包括提交说明检查时，通过jenkins调用预设脚本程序，检查所述代码的提交说明的格式是否满足预设格式要求，并在所述提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查；

当所述自动化检查包括静态代码检查时，通过jenkins调用静态检查工具对所述代码执行静态代码检查；

当所述自动化检查包括编译检查时，通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查。

可选的，所述自动化检查还包括自动化测试检查；

所述第一检查单元还用于：

通过jenkins调用测试服务器对编译后的代码执行自动化测试。

可选的，所述装置还包括：

第一设置模块，用于所述对所述代码执行目标检查之后，在所述代码通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第一值；

第二设置模块，用于在所述代码未通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第二值；

其中，所述第四检查为所述目标检查中的任一检查，所述代码未通过目标检查为：所述目标检查中存在至少一个检查对应的标签值为第二值。

可选的，所述检查模块，还包括：

发送单元，用于向至少一个评审者发送代码审查的通知信息，所述代码审查的通知信息用于通知所述至少一个评审者对所述代码进行审查；

接收单元，用于接收所述至少一个评审者针对所述代码的评审结果；

确定单元，用于在所述评审结果指示所述代码未通过评审的情况下，确定所述代码未通过人工检查。

代码审查装置300能够实现图1至图2的方法实施例的代码审查方法的各个过程，并达到相同的效果为避免重复，这里不再赘述。

本公开实施例的代码审查装置300，接收模块301，用于接收待向代码仓库提交的代码；检查模块302，用于对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；禁止模块303，用于在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。由于对代码分别执行了自动化检查和人工检查，并在代码未通过检查的情况下，禁止向所述代码仓库提交所述代码，从而可以提高提交至代码仓库的代码的质量。

本公开实施例还提供一种代码审查装置，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述任一方法实施例的代码审查方法的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本公开实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的代码审查方法的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(read-onlymemory，简称rom)、随机存取存储器(randomaccessmemory，简称ram)、磁碟或者光盘等。

参见图4，图4是本公开又一实施提供的代码审查装置的结构图，如图4所示，代码审查装置400包括：处理器401、存储器402及存储在所述存储器402上并可在所述处理器上运行的计算机程序，代码审查装置400中的各个组件通过总线接口403耦合在一起，所述计算机程序被所述处理器401执行时实现如下步骤：

接收待向代码仓库提交的代码；

对所述代码执行目标检查，其中，所述目标检查包括自动化检查和人工检查，所述自动化检查包括提交说明检查、静态代码检查、编译检查和自动化测试检查中的至少两项；

在所述代码未通过目标检查的情况下，禁止向所述代码仓库提交所述代码。

可选的，所述计算机程序被所述处理器401执行时还用于：

按照所述目标检查中各个检查的优先级由高至低的顺序，对所述代码执行检查；

其中，仅在所述代码通过第一检查的情况下，对所述代码执行第二检查，所述第一检查的优先级高于所述第二检查的优先级，所述第一检查和所述第二检查为所述目标检查中任意两个优先级相邻的检查。

可选的，所述计算机程序被所述处理器401执行时还用于：

所述对所述代码执行目标检查之后，在所述代码未通过所述目标检查中的第三检查的情况下，输出修改提示信息；

其中，所述第三检查为所述目标检查中任一检查，所述修改提示信息包括所述第一检查所检测出的错误信息和/或针对所检测出的错误信息的修改建议。

可选的，所述计算机程序被所述处理器401执行时还用于：

通过gerrit接收待向代码仓库提交的代码；

所述对所述代码执行目标检查，包括：

通过jenkins对所述代码执行自动化检查。

可选的，所述计算机程序被所述处理器401执行时还用于执行如下至少一项：

当所述自动化检查包括提交说明检查时，通过jenkins调用预设脚本程序，检查所述代码的提交说明的格式是否满足预设格式要求，并在所述提交说明的格式满足预设格式要求的情况下，确定所述代码通过提交说明检查；

当所述自动化检查包括静态代码检查时，通过jenkins调用静态检查工具对所述代码执行静态代码检查；

当所述自动化检查包括编译检查时，通过jenkins调用编译服务器对所述代码进行编译，并在所述代码编译成功的情况下，确定所述代码通过编译检查。

可选的，所述自动化检查还包括自动化测试检查；

所述计算机程序被所述处理器401执行时还用于：

通过jenkins调用测试服务器对编译后的代码执行自动化测试。

可选的，所述计算机程序被所述处理器401执行时还用于：

所述对所述代码执行目标检查之后，在所述代码通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第一值；

在所述代码未通过所述目标检查中的第四检查的情况下，将与所述第四检查对应的标签值设置为第二值；

其中，所述第四检查为所述目标检查中的任一检查，所述代码未通过目标检查为：所述目标检查中存在至少一个检查对应的标签值为第二值。

可选的，所述计算机程序被所述处理器401执行时还用于：

向至少一个评审者发送代码审查的通知信息，所述代码审查的通知信息用于通知所述至少一个评审者对所述代码进行审查；

接收所述至少一个评审者针对所述代码的评审结果；

在所述评审结果指示所述代码未通过评审的情况下，确定所述代码未通过人工检查。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本公开实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以权利要求的保护范围为准。