Code review method and computer program product

Abstract

This application discloses a code review method and a computer program product. The method includes: obtaining target code and its description information; inputting the target code and description information into a code review model, and sequentially performing multiple review processes at different levels in ascending order of review level to obtain the review result of the target code; wherein, the review process includes reviewing the input of the review process based on the review indicators of the corresponding review level, identifying faulty code segments, the input of the first level of review process is the target code and description information, and the input of the remaining review processes is the faulty code segments output by the previous level of review process; the level of review is positively correlated with the severity of the fault represented by the review indicators corresponding to the review level. This method can effectively improve review efficiency while ensuring a comprehensive review of the target code and description information.

Description

Technical Field

[0001] This application relates to the field of large language model technology, and in particular to a code review method and a computer program product. Background Technology

[0002] Code review is a crucial step in software development to ensure software quality. Traditional code review primarily relies on manual review. Manual review is time-consuming, resource-intensive, and inefficient. As software projects grow in scale and code volume, the feasibility of manual review decreases. Furthermore, the results of manual review are significantly influenced by the reviewer's experience, knowledge level, and subjective factors, leading to lower accuracy.

[0003] With the development of artificial intelligence technology, large-scale model technology has also evolved. Currently, large models can be trained to learn from massive amounts of code data, understanding the semantics and structure of the code, thereby enabling automated code review. However, current pre-trained large models still suffer from relatively low review efficiency for complex code. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a code review method and computer program product that can effectively improve review efficiency while ensuring a comprehensive review of the target code and descriptive information.

[0005] Firstly, this application provides a code review method. The method includes: Obtain the target code and its description. Input the target code and description information into the code review model, and perform multiple different levels of review in ascending order of review level to obtain the review result of the target code; The audit process includes auditing the input based on the audit indicators of the corresponding audit level, and determining the fault code segment. The input for the first level of audit is the target code and descriptive information, while the input for the other audits is the fault code segment output by the previous level of audit. The audit level is positively correlated with the severity of the fault represented by the audit indicators corresponding to the audit level.

[0006] In conjunction with the first aspect, in one possible implementation, the code review method further includes: obtaining the review criteria of the target code input by the user, reviewing the faulty code segment based on the review criteria; if the faulty code segment meets the review criteria, ignoring the faulty code segment and recording the false alarm event.

[0007] In conjunction with the first aspect, in one possible implementation, the code review method further includes: obtaining the fault presentation format input by the user, and presenting the review result of the target code, including the fault code and fault code information, based on the fault presentation format.

[0008] In conjunction with the first aspect, in one possible implementation, multiple different levels of review processes are performed sequentially in ascending order of review level, including: performing basic compliance checks, executability checks, and fault tolerance checks on the target code and description information in ascending order of review level.

[0009] In conjunction with the first aspect, in one possible implementation, the audit result includes the severity of the faulty code segment, and the code audit method further includes: obtaining the fault severity classification rules input by the user, and determining the fault severity of the faulty code segment according to the fault severity classification rules.

[0010] In conjunction with the first aspect, in one possible implementation, the code review method further includes: if the severity of the same fault code segment output by different levels of review processing is different, then the severity of the fault code segment output by the higher-level review processing is determined as the severity of the fault code segment.

[0011] In conjunction with the first aspect, in one possible implementation, the audit result also includes repair suggestions for faulty code segments, and the code audit method further includes: inputting historical audit records corresponding to the target code and description information into the code audit model; the historical audit records include historical faulty code segments and repair suggestions corresponding to the historical faulty code segments; matching the faulty code segments in the historical audit records, determining the repair suggestions matching the faulty code segments, and generating audit results based on the faulty code segments and repair suggestions.

[0012] In conjunction with the first aspect, in one possible implementation, the target code and descriptive information are input into the code review model, including: performing natural language conversion on the target code to obtain code text; and inputting the target code, descriptive information, and code text into the code review model.

[0013] In conjunction with the first aspect, in one possible implementation, the code review method further includes: receiving user feedback on the review results; and, if the feedback indicates that the review results do not meet the user's requirements, training the code review model based on the target code and descriptive information to obtain an updated code review model.

[0014] Secondly, this application also provides a computer program product. This computer program product includes a computer program that, when executed by a processor, implements the method described in the first aspect.

[0015] This application provides a code review method and a computer program product, which can acquire target code and its description information. The target code and description information are input into a code review model, and multiple different levels of review processing are performed sequentially in ascending order of review level to obtain the review result of the target code. The review processing includes reviewing the input based on the review indicators of the corresponding review level to identify faulty code segments. The input for the first level of review processing is the target code and description information, and the input for the remaining review processing is the faulty code segments output from the previous level of review processing. The review level is positively correlated with the severity of the fault represented by the review indicators corresponding to the review level. The multi-level review processing method in this application can perform a first-round screening of faulty code segments with basic faults in the target code and description information, and then further review processing based on other dimensions on the screened faulty code segments with basic problems. This avoids the problem of low review processing efficiency caused by reviewing all target code and description information based on all dimensions of review indicators. In other words, this application can effectively improve review efficiency while ensuring comprehensive review of the target code and description information. Attached Figure Description

[0016] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a code review method in one embodiment; Figure 2 This is another flowchart illustrating the code review method in one embodiment; Figure 3 This is another flowchart illustrating the code review method in one embodiment; Figure 4 This is another flowchart illustrating the code review method in one embodiment; Figure 5 This is another flowchart illustrating the code review method in one embodiment; Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0017] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0019] Code review is a crucial step in software development to ensure software quality. Traditional code review primarily relies on manual review. Manual review is time-consuming, resource-intensive, and inefficient. As software projects grow in scale and code volume, the feasibility of manual review decreases. Furthermore, the results of manual review are significantly influenced by the reviewer's experience, knowledge level, and subjective factors, leading to lower accuracy.

[0020] With the development of artificial intelligence technology, large-scale model technology has also evolved. Currently, large models can be trained to learn from massive amounts of code data, understanding the semantics and structure of the code, thereby enabling automated code review. However, current pre-trained large models still suffer from relatively low review efficiency for complex code.

[0021] Based on this, this application provides a code review method that can effectively improve review efficiency while ensuring a comprehensive review of the target code and description information.

[0022] In one embodiment, such as Figure 1 As shown, a code review method is provided. This embodiment illustrates the method by applying it to a server. It is understood that this method can also include systems with both a terminal and a server, and be implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps: Step 101: Obtain the target code and its description.

[0023] In this embodiment, the server's code review function is triggered when a code review instruction sent by a user terminal is received (e.g., the user clicks the "Code Review" button on the terminal interface). Alternatively, the server triggers the code review function when the user changes the code to meet product requirements (e.g., when the server receives instructions representing code changes such as Git Commit, Pull Request, Merge Request, etc.).

[0024] Once the server's code review function is triggered, it first retrieves the target code to be reviewed and its description. The target code can be modified code (e.g., newly added, modified, or deleted code) and / or the complete source code after the modification. The description can include the position of the modified code in the original complete code (represented by parameters such as starting line number and line number), or its position in the modified complete code. The description can also include the modified code's dependencies, i.e., files that call the modified code (e.g., interface layer code that calls the aes_encrypt function), files called by the currently modified code (e.g., pad utility function files that aes_encrypt depends on), configuration files for the modified code (e.g., database connection configuration, encryption key configuration, etc.), and interface definition files for the modified code (e.g., Swagger documentation and Proto files for API interfaces).

[0025] In one possible implementation, to increase data richness, the descriptive information of the target code can also include historical code versions of the modified code. The server can obtain historical code versions by calling Git's log or checkout commands. Specifically, historical code versions can be key historical code versions of the modified code, such as the last stable release or the last feature modification.

[0026] After a user submits modified code, the code hosting platform (such as GitHub, GitLab, etc.) performs version management and difference analysis on the code. For example, the code hosting platform stores the historical versions of the modified code in the code repository; it automatically analyzes the differences between the modified code and the code before the change (i.e., the previous version), generates relevant information about the modified code, and stores it in the code repository. Therefore, in this embodiment, the interface of the code hosting platform (such as the GitHub REST API) can be called to obtain the target code and its description from the code repository. For example, / repos / {owner} / {repo} / pulls / {pull_number} / files can be accessed to obtain the modified code and its description. The format of the modified code can be as shown in the following code: --- a / src / utils / encrypt.py +++ b / src / utils / encrypt.py @@ -12,7 +12,7 @@ def aes_encrypt(data, key): # Original code: Key length not validated -cipher = AES.new(key, AES.MODE_CBC, iv) # Modified code: Added key length validation +if len(key) not in (16, 24, 32): +raise ValueError("Key length must be 16, 24, or 32 bytes") +cipher = AES.new(key, AES.MODE_CBC, iv) return cipher.encrypt(pad(data, AES.block_size)) In one possible implementation, when the target code includes the modified complete source code, the server can use an Abstract Syntax Tree (AST) to perform structural parsing of the source code after obtaining the target code, splitting the source code into multiple code blocks according to units such as classes / functions, and associating the dependencies between each code block.

[0027] One possible implementation involves performing an integrity check on the target code after obtaining it. This check could include identifying issues such as incorrect line breaks or line numbering. If such issues are found, the code hosting platform's API would be called to retrieve the target code again, thus preventing incomplete code from affecting the accuracy of the review results.

[0028] In one possible implementation, information related to the software development task corresponding to the changed code can be obtained as part of the review criteria when the code review model reviews the target code and description files. A software development task is a task established to address the needs or defects of the software product before the change. Therefore, information related to the software development task can include task specification documents, requirement documents and / or defect documents, as well as the commit message filled in by developers when they complete and submit the changed code.

[0029] The task specification document may include at least one of the following: coding standards (e.g., Google Java Style Guide, Airbnb JavaScript Style Guide), security standards (OWASP Top 10, CWE vulnerability classification, etc.), architecture design documents (e.g., microservice boundary definition, database access specifications), and performance metrics (e.g., interface response time ≤ 500ms, memory usage ≤ 100MB). The server can specifically obtain the task specification document from a task knowledge base (e.g., Confluence, GitBook).

[0030] The requirements document can be, for example, a Product Requirements Document (PRD), which may include information such as the functional definitions and interface constraints of the changed code; the defect document may include information such as the vulnerability phenomena recorded in the bug tracking system. Specifically, the server can retrieve the requirements document by calling a requirements management tool (such as Jira) based on the requirements document identifier (e.g., the identifier REQ-202405 written in the submission description); and retrieve the defect document by calling a defect management tool (such as Bugzilla) based on the defect document identifier (e.g., the identifier BUG-10086 written in the submission description).

[0031] The submission description information may include requirement document identifier and / or defect document identifier, requirement description and / or defect description, purpose of code change, and functional modules required for code change. Specifically, the server can obtain the submission description information from the code submission record and extract structured information from the submission description information using regular expressions (e.g., requirement document identifier: REQ-202405] Requirement description: Fix the login interface encryption vulnerability).

[0032] In one possible implementation, historical audit records can be obtained as part of the audit criteria when the code audit model audits the target code and description files to generate audit results. Historical audit records can include audit records for previous versions of the target code or other code. Audit records can include faulty code segments, the fault type of the faulty code segments, the fix, and the developer's audit comments (e.g., "Temporary use of the -deprecated method is allowed, but it needs to be replaced in the next iteration"). Specifically, the server can obtain historical audit record information from the storage space managed by the code hosting platform.

[0033] In one possible implementation, the relevant information of the software development task corresponding to the modified code that can serve as part of the review criteria, as well as the historical review record information, can be stored in the knowledge base on which the code review model depends, such as a knowledge base based on Retrieval Augmented Generation (RAG) technology, so that the code review model can review the target code and description information based on the data in the knowledge base it depends on.

[0034] Step 102: Input the target code and description information into the code review model, and perform multiple different levels of review in ascending order of review level to obtain the review result of the target code.

[0035] The code review model can be trained using a large language model from the code domain (such as Code Llama or StarCoder) as the initial model, based on historical code versions and review records of the target code. Using a large model from the code domain as the initial model effectively improves the code review model's ability to analyze the target code, thereby significantly increasing the accuracy of the review results. The code review model can be deployed privately to prevent target code and other data from being uploaded to the public cloud, thus improving data security. The code review model can run on a high-performance GPU cluster (such as NVIDIA A100) to improve the efficiency of reviewing both the target code and its description information.

[0036] In this embodiment, after the server is triggered to perform code review and obtains the target code to be reviewed and its description information, it inputs the target code and description information into a trained code review model. In one possible implementation, before inputting the target code and description information into the code review model, a data volume assessment can be performed. If the data volume of the target code and description information exceeds a preset threshold, key content extraction is performed on the target code and description information (e.g., extracting historical code modules related to changed code from historical code versions). Finally, the target code and description information after key content extraction are input into the code review model to reduce the amount of data processed by the code review model, improve the model's attention, and thus improve the accuracy of the review results.

[0037] In this embodiment, the code review model is used to perform review processing on target code and descriptive information from different dimensions based on corresponding review standards, determining information such as faulty code segments and fault types, thereby obtaining the review results of the target code and descriptive information. Specifically, for the code review model, multiple rounds of review processing at different levels can be set. Different levels of review processing are used to review the target code and descriptive information from different dimensions based on the corresponding level of review indicators, so as to achieve a comprehensive review of the target code and descriptive information and improve the comprehensiveness and accuracy of the review results. That is, the review processing includes reviewing the input of the review processing based on the review indicators of the corresponding level of review processing to determine faulty code segments.

[0038] Furthermore, the multi-level review process is sequential, meaning the input to the first-level review is the target code and descriptive information, while the input to the subsequent reviews is the fault code segments output from the previous level. This multi-level review process effectively filters fault code segments from the target code and descriptive information before applying other dimensions (other-level review indicators) to the filtered fault code segments. This avoids the inefficiency caused by reviewing all target code and descriptive information based on all dimensions of review indicators. In other words, this application effectively improves review efficiency while ensuring comprehensive review of target code and descriptive information.

[0039] Taking a multi-level audit process with three levels as an example: The input to the first level of audit processing is the target code and descriptive information. The output is the first faulty code segment determined by the audit of the target code and descriptive information based on the corresponding audit indicators of the first level. The input to the second level of audit processing is the first faulty code segment determined by the first level of audit processing. The output is the second faulty code segment determined by the audit of the first faulty code segment based on the corresponding audit indicators of the second level. The input to the third level of audit processing is the second faulty code segment determined by the second level of audit processing. The output is the third faulty code segment determined by the audit of the second faulty code segment based on the corresponding audit indicators of the third level. Finally, audit results are generated and output based on information such as the fault type of each faulty code segment and its location in the source code. It is understandable that a faulty code segment can have multiple fault types. For example, a faulty code segment may not meet multiple audit standards of the same level or multiple audit standards of different levels. The level of audit is positively correlated with the severity of the fault represented by the audit indicators corresponding to that level. For example, if a code segment does not meet the first-level review criteria, it is considered a faulty code segment with a relatively low fault severity; if a code segment does not meet the third-level review criteria, it is considered a faulty code segment with a relatively high fault severity.

[0040] In one possible implementation, the multi-level review process of the code review model can include basic compliance checks, executability checks, and fault tolerance checks, with these three ordered in ascending order of review level. That is, the review level of fault tolerance checks is higher than that of executability checks, which are higher than that of compliance checks. The code review model first performs compliance checks on the target code and description information to identify the first faulty code segment that does not meet the corresponding review standards for compliance checks; then, it performs executability checks on the first faulty code segment to identify the second faulty code segment that does not meet the corresponding review standards for executability checks; finally, it performs fault tolerance checks on the second faulty code segment to identify the third faulty code segment that does not meet the corresponding review standards for fault tolerance checks.

[0041] Basic compliance checks can include audit dimensions such as syntax correctness checks, coding standardization checks, and logical reasoning checks. Syntax correctness checks are used to verify whether the target code and description information contain compilation or runtime syntax errors (e.g., missing semicolons in Java, abnormal indentation in Python, and undefined variables used directly). Coding standardization checks are used to verify whether the target code and description information conform to the coding standards in the audit criteria. Specifically, this can be done by comparing the target code and description information with the task specification document to check for issues such as non-camelCase variable naming, missing function comments, magic values, and hard coding. Logical reasoning checks are used to verify whether the target code and description information contain logical vulnerabilities, such as using '=' instead of '==" in if conditional statements, array index out-of-bounds risks (e.g., accessing a dynamically length array with a fixed index), and try blocks without catch / finally exception handling. Magic values ​​refer to numeric or string constants that appear directly in the code without clear semantic interpretation; hard coding refers to writing configurable or variable data directly in the source code without management through variables, constants, configuration files, or external resources. The aforementioned magic values ​​and hard-coding result in poor code readability and maintainability. If the target code and description information contain code segments with these problems, they are designated as the first faulty code segment. The code review model can mark the first faulty code segment based on the fault type (syntax error, coding style violation, etc.).

[0042] The code review model removes all data from the target code and description information except for the first faulty code segment and its corresponding description. Then, it performs executability checks on the first faulty code segment and its corresponding description. These executability checks can include review dimensions such as requirement consistency checks, interface compatibility checks, dependency rationality checks, and security risk checks. Requirement consistency checks verify whether the target code contains the content specified in the requirements document (e.g., the login interface must verify the validity of the verification code, order amounts must retain two decimal places, and the login interface encryption key must be obtained from environment variables). Interface compatibility checks verify whether the interface information of the first faulty code (e.g., Swagger definition) is consistent with the interface definition file in the description information (e.g., the interface definition file requires a "User ID (String type)", while the code receives an "Integer type", indicating a faulty code). The dependency rationality detection is used to check the rationality of the interaction logic between the first fault code and related modules (the calling module and the called module). For example, when calling a utility function, do the parameters meet the function's preconditions? Before calling a file upload function, is the file size checked to ensure it doesn't exceed the limit? When modifying a public variable, is the impact of other code logic referencing that variable considered? The security risk detection is used to check if the first fault code has security vulnerabilities. This can be achieved by comparing it with security standards and other documents in the task specification document. For example, it can be used to determine if there is SQL injection by combining the SQL statement concatenation method and parameter source; to check if passwords or keys are printed to the log; and to determine if there is sensitive information leakage by checking if the returned result contains sensitive fields such as the user's ID number. If the first fault code segment and its corresponding description have the above problems, it is designated as the second fault code segment. The code review model can re-mark the second fault code segment based on the fault type (requirement mismatch, interface incompatibility, security risk, etc.). It can also associate the second fault code segment with its fault judgment criteria (e.g., Chapter 5 of the requirements document requires: the order timeout time is 30 minutes, while the current code sets it to 60 minutes).

[0043] The code review model performs fault tolerance testing on the second faulty code segment and its corresponding description. Fault tolerance testing can include review dimensions such as missing indicator detection, extreme scenario compatibility testing, and defect correlation detection. Specifically, missing indicator detection is used to review the second faulty code based on audit indicators not used in basic compliance and executability testing. For example, it checks whether frequently created database connections in loops are not reused to determine if performance risks are introduced, and whether shared variables in multi-threaded operations are locked to determine if concurrency security issues exist. Extreme scenario compatibility testing checks whether the second faulty code can respond to extreme conditions, such as whether it throws a null pointer exception when an empty string is passed, whether there is a retry mechanism when a database connection fails, and whether deadlocks occur under a large number of concurrent requests. Defect correlation detection checks whether the second faulty code contains previously fixed defects, specifically by comparing historical audit records. For example, if a vulnerability was caused three months ago due to "unverified user permissions," it checks whether newly added interfaces again fail to perform permission verification. If the second faulty code segment and its corresponding description contain the above issues, it is considered a third faulty code segment. The code review model can re-mark the third faulty code segment based on the fault type. It can also associate the third faulty code segment with the criteria used to determine the fault.

[0044] Finally, the code review model integrates information from all faulty codes, such as the code's identifier, function, fault type (multiple types), and fault judgment criteria, to generate and output the review results. The server can associate the review results output by the model with metadata such as the review task identifier, review time, code review model version, the version of the knowledge base the code review model depends on, and review result processing logs (e.g., filtering one false alarm and correcting two severity levels), and then store them in a database (e.g., MySQL, Elasticsearch).

[0045] In one possible implementation, developers could also build a special fault library. This special fault library stores fault items for the current target code (e.g., SQL injection pattern "SELECT"). The `FROM user WHERE name = '" + username + "'")` directive states that if a non-audited code contains an item in this special fault database, the code is not necessarily faulty. The special fault database can also store fault items frequently ignored during historical code version audits (e.g., checking for null pointer exceptions before object calls). This special fault database is stored in the knowledge base upon which the audited model depends, instructing the audited model to audit the target code and description information (or faulty code segments in the audit results) based on the special fault database.

[0046] The following example illustrates the application of a code review model to a large language model, which includes a prompt module and relies on the RAG knowledge base: The prompt module retrieves descriptive information related to the target code from the local server where the target code runs and from the knowledge base. Based on the target code and descriptive information, it generates audit standard instructions and inputs them into the code audit model. Responding to the audit standard instructions, the code audit model extracts audit indicators for the software development task corresponding to the target code at each audit level from the knowledge base, based on the target code and descriptive information. The code audit model then performs basic compliance checks, executability checks, and fault tolerance checks on the target code and descriptive information sequentially according to the audit indicators corresponding to each audit level, obtaining the audit results for the target code. The audit levels corresponding to the basic compliance checks, executability checks, and fault tolerance checks are arranged in ascending order, with the higher the audit level, the more positively correlated with the severity of the fault represented by the audit indicators corresponding to that level. The audit results include faulty code segments in the target code segment and fault information for each faulty code segment. The audit results are output and presented according to a predefined fault presentation format.

[0047] In other words, before the large language model reviews the target code, the prompt module first determines the input content of the large language model by combining the RAG knowledge base (i.e., it retrieves descriptive information related to the target code from the RAG knowledge base and generates review standard instructions to be input into the large language model). Then, the large language model refers to the RAG knowledge base to determine the review level, review indicators, output format of the review results, and other relevant review information of the target code, and reviews the target code according to the review level upgrade order based on the above review information, and outputs the review results according to the predefined output format.

[0048] In other words, the aforementioned large language model can improve the accuracy and efficiency of target code review through multi-level review, and combine the prompt module and RAG knowledge base to determine the input of the large language model (target code related information), ensuring the comprehensiveness of the review content of the large language model and improving the reliability of the review results.

[0049] The method provided in this application embodiment can obtain target code and its description information. The target code and description information are input into a code review model, and multiple different levels of review processing are performed sequentially in ascending order of review level to obtain the review result of the target code. The review processing includes reviewing the input based on review indicators of the corresponding review level to determine faulty code segments. The input for the first level of review processing is the target code and description information, while the input for the remaining review processing is the faulty code segments output from the previous level. The review level is positively correlated with the severity of the fault represented by the review indicators corresponding to that level. The multi-level review processing method in this application embodiment can perform a first-round screening of faulty code segments with basic faults in the target code and description information, and then further review processing based on other dimensions on the screened faulty code segments with fundamental problems. This avoids the problem of low review processing efficiency caused by reviewing all target code and description information based on all dimensions of review indicators. In other words, this application can effectively improve review efficiency while ensuring a comprehensive review of the target code and description information.

[0050] The embodiments described above introduce a scheme for reviewing target code and description information to determine the review result containing fault code segments. In another embodiment of this application, the review result can be reviewed based on specific review criteria input by the user. This embodiment includes, for example... Figure 2 The steps shown are as follows: Step 201: Obtain the review criteria for the target code input by the user, and review the fault code segment based on the review criteria.

[0051] In this embodiment of the application, developers can also build a special audit standard library. This special audit standard library stores audit standards for the current target code, that is, standards that, although the target code does not meet the audit standards in the knowledge base on which the code audit model depends, do not affect the code's operation, functionality, etc.

[0052] Users (i.e. developers) can use a special audit criteria library along with the target code and description information as input to the code audit model, instructing the code audit model to review faulty code segments in the audit results based on the audit criteria in the special audit criteria library.

[0053] Step 202: If the fault code segment meets the audit criteria, ignore the fault code segment and record the false alarm event.

[0054] In this embodiment, after the code review model generates faulty code segments by performing different levels of review on the target code and description information, it can sequentially match each faulty code segment with the review standards in a special review standard library. If a faulty code segment exists that meets the review standards in the special review standard library, it is determined that the faulty code segment does not affect the target code and is not an actual fault. Therefore, the faulty code segment can be ignored, and a false alarm event can be recorded. For example, a code segment with the problem of "a function is not commented" is a faulty code segment, but if the review standard library contains the review standard "comments can be omitted for utility functions", then the faulty code segment is ignored, and a false alarm event is recorded.

[0055] In one possible implementation, the code review model can calculate the confidence level of the faulty code segment. If the confidence level of the faulty code segment is less than a preset confidence threshold (e.g., 0.6) and there is no fault type corresponding to the faulty code segment in the historical review records, then the faulty code segment is ignored and a false alarm event is recorded.

[0056] The method provided in this application can obtain the review criteria for the target code input by the user and review the faulty code segment based on the review criteria. If the faulty code segment meets the review criteria, it is ignored and a false alarm event is recorded. This application embodiment can combine user experience to review the review results, further improving the accuracy of the review results.

[0057] In one embodiment, developers can also define fault severity judgment rules. When reviewing target code and description information, the code review model can determine the fault severity of each faulty code based on the defined fault severity classification rules and write it into the review results. This embodiment includes the following steps: Obtain the fault severity classification rules input by the user, and determine the fault severity of the fault code segment according to the fault severity classification rules.

[0058] In this embodiment of the application, the developer can also define fault severity classification rules, for example, as shown below: Critical: The code could cause production environment crashes, data loss, or serious security vulnerabilities (such as unauthorized access), and must be fixed immediately. High (High Risk): The code contains obvious defects / vulnerabilities that may cause functional failures or severe performance degradation, and needs to be fixed in this iteration; Medium risk: The code has non-standard or potential problems that do not affect the core functionality, but may increase the cost of subsequent maintenance and need to be fixed before the next iteration; Low (Low Risk): The code has minor non-standard practices (such as missing comments), with no functional / performance impact, and can be selectively fixed.

[0059] Users can use custom fault severity classification rules along with target code and description information as input to the code review model. This instructs the code review model to identify faulty code segments during each level of review, determine the fault severity of each faulty code segment according to the fault severity classification rules, associate it with the corresponding faulty code segment, and then write it into the review result.

[0060] In one possible implementation, if the severity of the same fault code segment output by different levels of audit processing is different, then the severity of the fault code segment output by the higher-level audit processing is determined as the severity of the fault code segment.

[0061] In this implementation, considering the possibility that the same fault code segment may be determined to have different fault severity levels in different levels of review and processing, the fault severity determined by the higher level of review and processing should be used as the standard to avoid the fault code segment being ignored or not being processed in time due to a lower fault severity rating, which would affect the target code.

[0062] For example, if a code segment has a "function without comments" issue during the basic compliance check, the corresponding severity level is "Low"; while during the executability check, the same faulty code segment also has a "variable is an interface parameter and conflicts with the documentation definition" issue, the corresponding severity level is "Medium". In this case, the code review model should correct the severity level "Low" marked for the faulty code segment during the basic compliance check to "Medium".

[0063] In one possible implementation, the server can also modify the audit results based on a user-defined severity mapping. This severity mapping can include the correspondence between different user-defined audit criteria and fault severity levels. For example, it could include a mapping between "plaintext storage of user passwords" and "Critical". For a faulty code segment with the "plaintext storage of user passwords" problem, if the code audit model determines the fault severity to be "High", it will be modified to "Critical".

[0064] The method provided in this application can determine and promptly correct the severity of faulty code segments, so that developers can process faulty code segments with high verification levels based on the severity of the fault, thereby ensuring the security of the target code.

[0065] In one embodiment, the code review model can also provide remediation suggestions for faulty code segments and include them in the review results. This embodiment includes, for example: Figure 3 The steps shown are as follows: Step 301: Input the historical review records corresponding to the target code and description information into the code review model.

[0066] The historical review records include historical faulty code segments, the fault types of historical faulty code segments, the corresponding repair solutions for historical faulty code segments, and the review comments from developers (such as "the -deprecated method is allowed to be used temporarily, but it needs to be replaced in the next iteration").

[0067] The code review model can receive user input or retrieve historical review records directly from the code repository of the code hosting platform, and process the historical review records together with the target code and description information as input.

[0068] In one possible implementation, historical review records can be stored in a knowledge base on which the code review model depends, as described above, for the code review model to call during the review process.

[0069] Step 302: Match the fault code segment with the historical audit records, determine the repair suggestions for the matched fault code segment, and generate the audit results based on the fault code segment and the repair suggestions.

[0070] In this embodiment of the application, after the code review model identifies the faulty code segment during the review process at each level, it can match the faulty code segment with the historical review records, determine the repair suggestions that match the faulty code segment in the historical review records, and write the repair suggestions with the faulty code segment into the review results.

[0071] In one possible implementation, after identifying the recommended fixes for the faulty code segment, feasibility verification can be performed. For example, if the suggestion is to "use PreparedStatement to prevent SQL injection," it needs to be confirmed whether the project has already included the relevant dependencies; if the suggestion is to "add caching to reduce database queries," it needs to be confirmed whether the cache key design will lead to cache penetration or cache breakdown.

[0072] The code review model provided in this application embodiment can also generate repair suggestions for faulty code segments for developers to refer to, effectively improving the repair efficiency of faulty codes.

[0073] In one embodiment, to improve the standardization and readability of the audit results, requirements can be imposed on the output format of the audit results. This embodiment includes the following steps: Obtain the fault presentation format input by the user, and present the audit results of the target code, including the fault code and fault code information, based on the fault presentation format.

[0074] Developers can also define the output format of the audit results, i.e., the failure presentation format. For example, as shown below: { "audit_results": [ { "issue_type": "string", / / Issue type, which must be selected from "Security Vulnerability / Code Defect / Performance Issue / Standardization / Maintainability / Document Integrity". "severity": "string", / / Severity level, must be selected from "Critical / High / Medium / Low" "file_path": "string", / / Problematic file path "line_start": number, / / The starting line number of the problem "line_end": number, / / End line number of the question "description": "string", / / Brief description of the problem (≤50 characters) "explanation": "string", / / Detailed explanation of the problem (must be in context, ≥100 words) "suggestion": "string", / / Suggested fix (must be specific and actionable, such as code snippets) "evidence": "string", / / Reference to the problematic code snippet (copy the problematic line of code and indicate the line number). "confidence": number / / Confidence level (0-1, representing the degree of certainty of the large model regarding the problem) } ], "summary": { "total_issues": number, / / Total number of issues "severity_distribution": { / / Number of issues at each severity level "Critical": number, "High": number, "Medium": number, "Low": number }, "key_risk_points": ["string"] / / Key risk points (e.g., "There are 2 critical-level security vulnerabilities that need to be fixed first") } } Users can use a custom fault presentation format, along with the target code and description information, as input to the code review model. This allows the code review model to output the fault presentation format according to the user-defined format after completing the review process, identifying the faulty code segment, and generating the review results.

[0075] In one possible implementation, after generating and formatting the review results, the code review model can perform a second format validation based on a user-defined fault presentation format. For example, if the fault presentation format is a JSON structure, the review results can be validated using JSON Schema to ensure they conform to the JSON structure (specifically, checking for the existence of fields such as `issue_type` and `severity`, and whether these fields meet their definitions). If the format of the review results does not conform to the fault presentation format, the review results are considered invalid, and a new review result is generated based on the fault code information and the fault presentation format. Format validation can also include verifying the compliance of the fault judgment criteria for the fault code segment (e.g., whether the fault judgment evidence comes from the specified file `file_path`) and verifying whether the fault code segment matches its associated fault severity level.

[0076] In one possible implementation, developers can also define the review dimensions for the target code and descriptive information. For example, as shown below: Security vulnerabilities: Are there malicious SQL injection vulnerabilities, cross-site scripting (XSS) attacks, sensitive information leakage, encryption logic flaws, etc. (refer to OWASP Top 10 2024). Code defects: Does it contain null pointer exceptions, array out-of-bounds errors, logical infinite loops, or unreleased resources (such as file streams and database connections)? Performance issues: Are there redundant calculations, large objects not being garbage collected, database queries without indexes, or circular API calls? Standardization: Does it conform to the "Project Coding Standards" (such as naming rules, comment completeness, code indentation); Maintainability: Does it contain hard-coded code, duplicated code, excessively long functions (more than 80 lines), or overly coupled logic? Documentation completeness: Have interface comments, parameter descriptions, and change notes been added (e.g., README updates)?

[0077] After completing multiple levels of review and generating review results, the code review model can divide faulty code segments and their related information into review result sub-modules that conform to different dimensions based on the review dimensions defined by the developers, and present them modularly according to the review dimensions defined by the developers.

[0078] In one embodiment, the code review model can perform language processing on the target code and descriptive information, and then use the processing result as input to the model for review. That is, the aforementioned "inputting the target code and descriptive information into the code review model," this embodiment includes, for example... Figure 4 The steps shown are as follows: Step 401: Perform natural language conversion on the target code to obtain the code text.

[0079] In this embodiment of the application, the server can use "code-natural language mapping" technology to convert the target code and description information into natural language descriptions, thereby obtaining the code text corresponding to the target code and description information. For example, the code language can be converted into "Lines 12-18: Read the AES key from the configuration file; if the read fails, throw a null pointer exception".

[0080] Step 402: Input the target code, description information, and code text into the code review model.

[0081] In this embodiment, the server can use the code text, target code, and description information together as input to the code review model, so as to instruct the code review model to review the target code and description information with reference to the code logic described in the code text, so as to ensure that the large model accurately understands the code function.

[0082] In one embodiment, the code review model can be optimized based on user feedback. This embodiment includes, for example... Figure 5 The steps shown are as follows: Step 501: Receive user feedback on the review results.

[0083] In this embodiment of the application, the server can receive user feedback on the review results. The feedback may include user ratings, likes, dislikes, and suggestions for improvement.

[0084] Step 502: If the feedback information indicates that the review results do not meet the user's requirements, the code review model is trained based on the target code and description information to obtain an updated code review model.

[0085] In this embodiment of the application, if the feedback information indicates that the review result does not meet the user's requirements, the code review model can be iteratively trained based on the target code, description information, review result, improvement suggestions provided by the user, and other data until the maximum number of iterations is reached or the model accuracy reaches the preset accuracy, at which point training is stopped and an updated code review model is obtained.

[0086] In one possible implementation, the code review model can be trained using a fine-tuning approach. For example, Domain-Adaptive Fine-Tuning (DAFT) can be employed to train the code review model. The fine-tuning parameters can be as follows: Learning rate: 5e-5~1e-4; Number of training epochs: 3-5 (to avoid overfitting); Batch size: Adjusted according to GPU memory (e.g., 8-16).

[0087] If the fine-tuned code review model meets the update conditions (e.g., false positive rate reduced by ≥10%, false negative rate reduced by ≥8%), then the model will be updated based on the fine-tuned code review model.

[0088] In one possible implementation, to improve the accuracy and efficiency of the code review model, the knowledge base on which the code review model relies can be periodically optimized and updated. For example, outdated specifications (such as obsolete coding standards) and invalid fixes (such as code inapplicable to the current framework version) can be cleaned up periodically (e.g., monthly) in the knowledge base. For instance, when the knowledge base is a RAG knowledge base, Sentence-BERT from the code domain can be used as the semantic retrieval model for RAG to improve the accuracy of RAG in retrieving review standards related to the target code.

[0089] One possible implementation involves how the review results are displayed on the user's front end. Different fault code segments or fault code segments of different severity can be displayed using different colors. For example, Critical: red, High: orange, Medium: yellow, Low: blue. When the user hovers the mouse over the window containing the fault code segment, the server responds to the user's action by displaying detailed information about the corresponding fault code segment in a pop-up window, as shown below:

[0090] The server can also support user filtering (by severity of fault, etc.) and clicking to jump (e.g., jumping to the location of the fault code in the source code) on the front end.

[0091] One possible implementation is to use tools such as webhooks and APIs from the code hosting platform to add the review results as "PR comments" to the Pull Request / Merge Request page for display. The display could include the following: grouping by severity level (Critical levels can be pinned), supporting collapsing or expanding detailed information (location of the faulty code segment, suggested fixes, etc.); allowing developers to provide feedback in the comments (e.g., replying "fixed," "this issue is not applicable to the current scenario," "fix solution," etc.), with feedback synchronized to the server so that the server can instruct the code review model to update based on the feedback.

[0092] In one possible implementation, the server can also generate audit reports and send them to developers, testers, and other relevant personnel via email, enterprise communication platforms (such as Slack, DingTalk, etc.). Audit reports can include two types: single audit reports and periodic statistical reports. Single audit reports can be in HTML or PDF format and may include the audit results of the target code and description information, a pie chart of severity level distribution, and key risk point alerts. Periodic statistical reports can be published daily, weekly, or monthly and include the trend distribution of the number of fault types for each fault code segment, the sorting of fault types by the number of fault code segments from largest to smallest, and changes in false alarm rates.

[0093] It should be noted that although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0094] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing terminal devices or servers in the embodiments of this application.

[0095] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0096] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0097] In particular, according to embodiments of this disclosure, the above references Figure 1-5 The described process can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing instructions for performing... Figure 1-5 The program code for the method. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611.

[0098] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0100] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0101] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 1-5 The steps of the method shown are as follows.

[0102] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 1-5 The steps of the method shown are as follows.

[0103] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0104] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A code review method, characterized in that, The method includes: Obtain the target code and its description information; The target code and the description information are input into the code review model, and multiple different levels of review are performed in ascending order of review level to obtain the review result of the target code. The audit process includes auditing the input of the audit process based on the audit indicators of the corresponding audit level, and determining the fault code segment. The input of the first level audit process is the target code and the description information, and the input of the other audit processes is the fault code segment output by the previous level audit process. The level of audit is positively correlated with the severity of the fault represented by the audit indicators corresponding to the audit level.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the review criteria for the target code input by the user, and review the fault code segment based on the review criteria; If the fault code segment meets the audit criteria, the fault code segment is ignored and a false alarm event is recorded.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the fault presentation format input by the user, and present the audit result of the target code, including the fault code and fault code information, based on the fault presentation format.

4. The method according to claim 1, characterized in that, The process of sequentially performing multiple levels of review in ascending order of review level includes: The target code and the description information are subjected to basic compliance testing, executability testing, and fault tolerance testing in ascending order of review level.

5. The method according to claim 1, characterized in that, The audit result includes the severity of the fault code segment, and the method further includes: Obtain the fault severity classification rules input by the user, and determine the fault severity of the fault code segment according to the fault severity classification rules; If the severity of the same fault code segment output by different levels of audit processing is different, then the severity of the fault code segment output by the higher-level audit processing shall be determined as the severity of the fault code segment.

6. The method according to claim 1, characterized in that, The audit results also include repair suggestions for the faulty code segment, and the method further includes: Input the historical audit records corresponding to the target code and the description information into the code audit model; the historical audit records include historical faulty code segments and corresponding repair suggestions for the historical faulty code segments; The fault code segment is matched against the historical audit records to determine the corresponding repair suggestions, and the audit result is generated based on the fault code segment and the repair suggestions.

7. The method according to claim 1, characterized in that, The step of inputting the target code and the description information into the code review model includes: The target code is converted into natural language to obtain the code text; The target code, the description information, and the code text are input into the code review model.

8. The method according to claim 1, characterized in that, The method further includes: Receive user feedback on the review results; If the feedback information indicates that the review result does not meet the user's requirements, the code review model is trained based on the target code and the description information to obtain an updated code review model.

9. The method according to any one of claims 1-8, characterized in that, The code review model is a large language model, including a prompt module. The code review model relies on a knowledge base based on retrieval-enhanced generation technology. The method also includes: The prompt module retrieves descriptive information related to the target code from the local server where the target code runs and the knowledge base, and generates review standard instructions based on the target code and the descriptive information, which are then input into the code review model. The code review model responds to the review standard instructions by extracting review indicators for the software development task corresponding to the target code at each review level from the knowledge base based on the target code and the description information. The code review model performs basic compliance checks, executability checks, and fault tolerance checks on the target code and the description information sequentially according to the review indicators corresponding to each review level, to obtain the review result of the target code; the review levels corresponding to the basic compliance checks, executability checks, and fault tolerance checks are arranged in ascending order, and the level of the review is positively correlated with the severity of the fault represented by the review indicator corresponding to the review level; the review result includes faulty code segments in the target code segment and fault information of each faulty code segment; The audit results are output and presented according to a predefined fault presentation format.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images