Code architecture drift repair method and system, electronic equipment and computer storage medium

Abstract

The invention discloses a code architecture drift repair method and system, electronic equipment and a computer storage medium. The code architecture drift repair method comprises the steps that a dependency graph of target codes submitted to a version control system is constructed; performing architecture drift detection on the target code based on the architecture baseline model and the dependency graph to obtain a detection result; and when the detection result indicates that the target code violates at least one of the association rule, the layering rule and the loop dependency rule, repairing the target code to obtain a repaired code, and generating an architecture document of the repaired code. According to the method and the device, architecture drift detection is carried out on the target code based on the architecture baseline model and the dependency graph, real-time detection of architecture drift can be realized, and the timeliness and the accuracy of detection are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of code security analysis technology, and in particular to a code architecture drift repair method, system, electronic device, and computer storage medium. Background Technology

[0002] Software systems commonly face the challenge of architecture drift during long-term evolution. With changes in team members, frequent iterations of requirements, and urgent bug fixes, the originally clear architectural boundaries gradually blur, and the code implementation deviates from the design intent, resulting in "architectural erosion." This problem leads to increased system maintenance costs, increased difficulty in developing new features, performance degradation, and an increase in security vulnerabilities.

[0003] Current approaches primarily involve using rule-based architecture consistency checking tools (such as ArchUnit and Structure101) for detection. While rule-based architecture checking tools can automate the detection process, they require developers to predefine architectural constraints, such as "the presentation layer must not directly access the data layer" or "service A must not depend on service B," and they are prone to frequent false positives. This results in low real-time performance and accuracy in code detection. Summary of the Invention

[0004] In view of this, this application provides a code architecture drift repair method to solve the problem of architecture drift caused by submitting new code in traditional solutions.

[0005] The first aspect of this application provides a method for repairing code architecture drift, comprising: constructing a dependency graph of target code submitted to a version control system, wherein the dependency graph is used to indicate the dependency relationships between files in the target code; performing architecture drift detection on the target code based on an architecture baseline model and the dependency graph, and obtaining a detection result, wherein the architecture baseline model is trained based on historical code submissions in the version control system; when the detection result indicates that the target code violates at least one of association rules, hierarchical rules, and circular dependency rules, repairing the target code, obtaining repaired code, and generating an architecture document for the repaired code.

[0006] In one possible implementation, repairing the target code to obtain repaired code includes: generating at least one repair scheme based on the rules violated by the target code as indicated by the detection result; determining a target repair scheme from the at least one repair scheme; and reconstructing the target code according to the target repair scheme to generate the repaired code.

[0007] In one possible implementation, the method further includes: checking the hierarchical labels included in the target code; if the checking result indicates that the hierarchical labels of the target code are incorrect, then correcting the hierarchical labels of the target code.

[0008] In one possible implementation, the method further includes: generating a rule violation description document based on the rules violated by the target code, and outputting the rule violation description document.

[0009] In one possible implementation, the step of performing architecture drift detection on the target code based on the architecture baseline model and the dependency graph to obtain detection results includes: determining strongly connected components in the target code according to the dependency graph; if the strongly connected components include at least two nodes, generating a detection result indicating that the target code violates the circular dependency rule; determining the correspondence between the source layer and the dependency layer in the target code according to the dependency graph; if the correspondence violates the hierarchical constraint rule in the architecture baseline model, generating a detection result indicating that the target code violates the hierarchical rule; extracting itemsets from the target code; if the extracted itemsets satisfy the antecedent of the association rule in the architecture baseline model but do not satisfy the consequent of the association rule in the architecture baseline model, generating a detection result indicating that the target code violates the association rule.

[0010] In one possible implementation, generating a detection result indicating that the target code violates the association rule if the extracted itemset satisfies that the antecedent of the association rule in the architecture baseline model is true and the consequent is false includes: if the extracted itemset satisfies that the antecedent of the association rule in the architecture baseline model is true and the consequent is false, then labeling the severity of the association rule violation according to the confidence level and / or historical repair records corresponding to the violated association rule, and generating a detection result indicating that the target code violates the association rule.

[0011] In one possible implementation, the method further includes: outputting a health score based on the coupling degree between the detection result and the target code; and generating review suggestions based on the relationship between the health score and a score threshold.

[0012] In one possible implementation, constructing the dependency graph of the target code submitted to the version control system includes: generating a first transaction object set based on the target code, wherein the first transaction object set includes first transaction objects used to structurally describe the single code commit information corresponding to the target code; and constructing the dependency graph of the target code based on the first transaction object set.

[0013] In one possible implementation, the architecture baseline model is constructed as follows: historical commit code information within a first time period is extracted from the version control system, and a second transaction object set is generated based on the information corresponding to each commit in the historical commit code information, wherein the second transaction object set includes second transaction objects used to structurally describe the single code commit information corresponding to the historical commit code information; an itemset set is generated based on the second transaction object set; association rules are generated based on the itemset set, and the architecture baseline model is generated based on the association rules and the architecture constraints corresponding to the version control system.

[0014] In one possible implementation, the step of generating association rules based on the itemset set and generating the architecture baseline model based on the association rules and the architecture constraints corresponding to the version control system includes: mining frequent itemsets with support greater than a first threshold from the itemset set, and splitting the items included in the frequent itemsets to obtain multiple candidate rules, wherein the support is used to characterize the probability of the itemset being submitted within the first time period; calculating the confidence and lift of each candidate rule based on the support of the frequent itemsets, and determining the candidate rules with confidence greater than a second threshold and lift greater than a third threshold as the association rules; and generating the architecture baseline model based on the association rules and the architecture constraints corresponding to the version control system.

[0015] A second aspect of this application provides a code architecture drift repair system, comprising: a code analysis layer for constructing a dependency graph of target code submitted to a version control system, wherein the dependency graph indicates the dependencies between files in the target code; a detection layer for performing architecture drift detection on the target code based on an architecture baseline model and the dependency graph, and obtaining detection results, wherein the architecture baseline model is trained based on historical code submissions in the version control system; and a repair layer for repairing the target code when the detection results indicate that the target code violates at least one of association rules, hierarchical rules, and circular dependency rules, obtaining repaired code, and generating an architecture document for the repaired code.

[0016] A third aspect of this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform an operation corresponding to the method described in any one of the first aspects of the embodiments.

[0017] The fourth aspect of this application provides a computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect of the embodiments.

[0018] In this application, by constructing a dependency graph of the target code submitted to the version control system, architectural complexity can be evaluated using graph algorithms, improving the efficiency of subsequent code violation detection. By performing architectural drift detection on the target code based on the architectural baseline model and dependency graph, real-time detection of architectural drift can be achieved, significantly improving the timeliness and accuracy of detection. When the detection results indicate that the target code violates at least one of the rules of association, hierarchical relationships, and circular dependencies, the target code is repaired to obtain the repaired code, and an architectural document of the repaired code is generated, significantly improving repair efficiency and reducing human decision-making costs. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0020] Figure 1 This is a flowchart illustrating the steps of a code architecture drift repair method according to an embodiment of this application; Figure 2 This is a schematic diagram of a code architecture drift repair system according to an embodiment of this application; Figure 3 This is a schematic diagram of the code analysis layer according to an embodiment of this application; Figure 4 This is a schematic diagram of the detection layer according to an embodiment of this application; Figure 5 This is a schematic diagram of the repair layer according to an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0024] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. In the absence of conflict, the following embodiments and their technical features can be combined with each other.

[0025] Software systems commonly face the challenge of architecture drift during long-term evolution. With team member changes, frequent requirement iterations, and urgent bug fixes, the initially clear architectural boundaries gradually blur, and code implementation deviates from the design intent, resulting in "architectural erosion." This problem leads to increased system maintenance costs, increased difficulty in developing new features, performance degradation, and increased security vulnerabilities. Research and industry experience both indicate that architecture-related issues are often a significant source of technical debt, and their repair costs are typically far higher than those of ordinary defects, increasing exponentially with system size.

[0026] Current approaches primarily involve manual architecture reviews and rule-based architecture consistency checks, but both have fundamental limitations. Manual reviews rely on expert experience, resulting in high costs, low efficiency, and difficulty in achieving full coverage. For large projects, comprehensive reviews often require senior architects to spend days or even weeks, only allowing for sample analysis of certain modules. Furthermore, due to the lack of real-time updates, problems are often only discovered after they have impacted the system. In addition, inconsistent human judgment standards lead to highly subjective results.

[0027] In contrast, rule-based architecture checking tools (such as ArchUnit, Structure101, and SonarQube) differ significantly. ArchUnit, a Java bytecode analysis-based architecture testing framework, allows developers to define architecture rules using unit tests and automatically verify them in the CI process. Developers must manually write rules specifying package dependency constraints, layered architecture limitations, and naming conventions. Its fundamental limitation lies in its complete reliance on manually defined rules; complex systems may require hundreds of rules, resulting in a heavy maintenance burden. Rules must be updated synchronously as the project architecture evolves, otherwise, numerous false positives will occur. More importantly, it cannot detect implicit team coding constraints; it can only check explicitly defined rules and is powerless against unnoticed architectural issues. Structure101, a commercial architecture analysis tool, extracts dependencies through static code analysis and generates visual dependency graphs and complexity matrices. Users must manually define the desired architecture model, and the tool compares the actual dependencies with the desired architecture and highlights violations. Its main problem is that manually maintaining the architecture model is time-consuming and requires specialized knowledge; manual modeling for large projects can take weeks, and the model needs continuous updating as the project evolves. This tool is primarily used for periodic architectural reviews rather than real-time monitoring, and cannot provide immediate feedback upon code submission, resulting in a significant time lag between the occurrence of a violation and its discovery. SonarQube is a code quality management platform that uses static analysis based on predefined rule sets to detect code smells, potential bugs, and security vulnerabilities. Its architectural detection features include package dependency checks, class design principle verification, and complexity control, supporting multiple programming languages ​​and integrating with mainstream CI / CD tools. However, its architectural detection capabilities are relatively basic, focusing primarily on general code quality rather than deep architectural constraints. While its rule base is vast, it lacks the ability to learn for specific projects, resulting in a high false positive rate and detection often remaining at a superficial level. More importantly, it cannot automatically learn and adapt to project evolution; all rules are statically configured.

[0028] ArchUnit's core flaw lies in its requirement to predefine a complete set of rules, placing unreasonable demands on development teams. Real-world projects may have hundreds of architectural constraints, constantly evolving with the project. Requiring teams to manually write and maintain such a massive rule set is neither practical nor economical. A more serious problem is that many architectural constraints are implicit, followed by team members but never explicitly stated. For example, a project might have the habit of always ending files in the data access layer with "Repository," and the service layer rarely directly importing third-party HTTP libraries. These implicit constraints cannot be defined through explicit rules, but violations will disrupt project consistency. ArchUnit cannot detect these implicit constraints; it can only check rules that developers have thought of and written down. As the architecture evolves naturally, fixed rules generate numerous false alarms. For instance, if a project decides to introduce a new middleware layer, existing cross-layer access rules need to be adjusted; otherwise, the new code will be incorrectly flagged as violating the rules. Experience shows that abandoning architectural inspection tools due to excessive false alarms is not uncommon.

[0029] While Structure101 offers powerful visualization capabilities, the manual modeling and maintenance workload is prohibitive. For large systems with thousands of classes and tens of thousands of dependencies, manually building an architecture model can take weeks, and the model quickly becomes outdated. Whenever a project undergoes a major refactoring or adds a new module, the architecture model needs to be updated synchronously, a maintenance burden that often exceeds the team's capacity. A more fundamental problem is that Structure101 cannot automatically adapt to project evolution; all architecture definitions rely on manual input. This tool is primarily used for regular architecture review meetings and cannot achieve real-time continuous monitoring. Although it can run analyses and generate reports periodically, there is a significant time lag between the occurrence and discovery of architectural violations. By this time, the problematic code may already be depended upon by other modules, multiplying the cost of remediation. SonarQube's architecture detection capabilities are relatively limited; its rule base primarily targets general code quality rather than project-specific architectural constraints. While custom rules are possible, the configuration process is complex and requires a deep understanding of how the rule engine works. SonarQube cannot learn the team's coding patterns from project history; all detection is based on statically configured rule sets. This leads to two problems: first, it cannot adapt to the characteristics of different projects, with general rules being too strict in some projects and too lenient in others; second, it cannot capture implicit constraints within the team, only checking explicitly defined violation patterns. Furthermore, SonarQube has a relatively high false positive rate, especially in complex architectural scenarios, often judging reasonable designs as violations or overlooking genuine architectural problems.

[0030] As can be seen, while the tools mentioned above can automate detection, they require developers to define architectural constraints in advance, such as "the presentation layer must not directly access the data layer" or "service A must not depend on service B." This approach has three major limitations: (1) Rule writing requires deep architectural knowledge and a lot of time investment, which is a high threshold for small and medium-sized teams; (2) It can only detect explicitly defined rules and cannot discover implicit patterns formed in long-term team collaboration; (3) When the architecture evolves naturally, fixed rules will frequently generate false alarms and require manual configuration updates.

[0031] Many teams have introduced such tools in practice, but have gradually stopped using them due to excessive false alarms and heavy maintenance burden. Therefore, this application provides a code architecture drift repair method, system, electronic device and computer storage medium to at least partially solve the above problems.

[0032] Figure 1 This is a flowchart illustrating the steps of a code architecture drift repair method according to an embodiment of this application, as follows: Figure 1 As shown, the code architecture drift repair method includes the following steps: Step 101: Construct a dependency graph of the target code to be submitted to the version control system.

[0033] While the Git version control system meticulously records code change history, it lacks the ability to learn and detect architectural constraints. Git can only track file additions, deletions, and modifications; it cannot understand the semantic structure and dependencies of the code. Developers can view commit history and file differences, but manual analysis is required to identify architectural issues. Git lacks a proactive architectural monitoring mechanism and cannot automatically assess whether architectural constraints are violated during code commits. Although external inspection tools can be integrated through pre-commit hooks, Git itself does not provide any architectural analysis functionality.

[0034] Therefore, when a user submits code to a version control system, a dependency graph of the corresponding target code can be constructed. The target code is the newly submitted code by the user, and the dependency graph is used to indicate the dependencies between files in the target code.

[0035] In one possible implementation, the process of constructing the dependency graph of the target code to be submitted to the version control system may further include: generating a first set of transaction objects based on the target code, and constructing the dependency graph of the target code based on the first set of transaction objects.

[0036] The first transaction object set includes first transaction objects used to structurally describe the single code commit information corresponding to the target code. This single code commit information includes metadata such as commit_hash and timestamp. Next, the single code commit information is parsed, including AST extraction of dependencies and inference of the hierarchy based on file paths (e.g., paths containing "controllers" indicate the presentation layer, "services" indicate the business layer, and "models" or "repositories" indicate the data layer). This integrates the single code commit information into a first transaction object containing multi-dimensional information. The first transaction object can include all files modified during the single code commit, related import statements, and affected architectural layers. When the target code includes code from multiple commits, the first transaction object set will contain multiple first transaction objects. After obtaining the first transaction object set, the import statements within the first transaction objects are parsed to construct a file-dependency file mapping. Then, the dependencies of multiple first transaction object commits are merged to form the dependency graph of the target code. Nodes in the dependency graph indicate files or modules, and edges indicate the dependency direction.

[0037] Specifically, the process of constructing the dependency graph of the target code based on the first set of transaction objects may also include: extracting key fields from the first set of transaction objects and converting them into atomic items in key:value format (such as extracting file:xxx, layer:xxx, and import:xxx from changed_files_info), ultimately forming an itemset; obtaining an itemset set based on the formed itemset set; further analyzing the dependencies between the code based on the itemset set; and constructing the dependency graph of the target code.

[0038] Forming itemsets using the first transaction object enables a flattened transformation of structured data, simplifying the logic for generating dependency graphs. The dependency graph construction phase employs path compression and caching mechanisms, reducing query latency for high-frequency nodes by an order of magnitude, making real-time monitoring of large codebases possible.

[0039] Step 102: Perform architecture drift detection on the target code based on the architecture baseline model and dependency graph, and obtain the detection results.

[0040] After obtaining the dependency graph of the target code, the architecture drift detection is performed on the target code based on the architecture baseline model and the dependency graph. Specifically, the architecture baseline model can identify whether there are any violations in the target code newly submitted to the version control system. The architecture baseline model can perform multiple detections on the target code, such as association rule violation detection, layer rule violation detection, and circular dependency rule violation detection, and output the detection results.

[0041] In one possible implementation, the process of performing architecture drift detection on the target code based on the architecture baseline model and dependency graph, and obtaining the detection results, may further include: Based on the dependency graph, strongly connected components in the target code are determined. If a strongly connected component includes at least two nodes, a detection result indicating that the target code violates the circular dependency rule is generated.

[0042] The purpose of circular dependency detection is to identify closed dependencies between modules (such as A→B→C→A). These closed dependencies originate from the architectural baseline model. The dependency graph can be traversed using the Tarjan algorithm, Kosaraju algorithm, or a simpler depth-first search method to locate all strongly connected components (SCCs). The time complexity of the Tarjan algorithm, Kosaraju algorithm, and the simpler depth-first search method is O(V+E) or close to it, and the detection accuracy is the same. Strongly connected components are a core concept in graph theory describing bidirectional reachability between vertices in a directed graph. A SCC is defined as a maximal subgraph in a directed graph where any two vertices are bidirectionally reachable. If a strongly connected component contains ≥2 nodes, a detection result indicating that the target code violates the layering rule is generated. For example, if the dependency graph contains user_controller→user_service→user_model→user_controller, the Tarjan algorithm identifies this 3-node strongly connected component and generates a detection result indicating that the target code violates the circular dependency rule.

[0043] The correspondence between the source layer and the dependency layer in the target code is determined based on the dependency graph. If the correspondence violates the layering constraint rules in the architecture baseline model, a detection result indicating that the target code violates the layering rules is generated.

[0044] The purpose of layered rule detection is to identify dependencies that violate the hierarchical access order (such as reverse dependencies and cross-layer access). The hierarchical access order is the layered constraint rules in the architecture baseline model. For example, if the layered constraint rule in the architecture baseline model is Presentation Layer → Business Layer → Data Layer, and the correspondence between the source layer and the dependent layer in the target code is Data Layer → Business Layer (i.e., data layer files are imported into the business layer), then the target layer is upstream of the source layer in the legal dependency chain, resulting in a reverse dependency violation, because the normal dependency direction should be top-down. If the correspondence between the source layer and the dependent layer in the target code is Presentation Layer → Data Layer (i.e., presentation layer files are directly imported into the data layer, skipping the business layer), then the source layer and the target layer skip the intermediate layer, resulting in cross-layer access, which is considered a cross-layer access violation. Both of these situations will generate detection results indicating that the target code violates the layered rules.

[0045] Extract itemsets from the target code. If the extracted itemsets satisfy the antecedent of the association rule in the architecture baseline model but do not satisfy the consequent of the association rule in the architecture baseline model, then generate a detection result indicating that the target code violates the association rule.

[0046] The purpose of association rule detection is to identify behaviors that violate the team's implicit architectural habits (such as the presentation layer depending on the data layer but not on the business layer). First, extract the itemsets from the target code, such as {layer:presentation layer, import:data layer}. Then, traverse the association rules in the baseline architecture model, checking for situations where the antecedent A of a rule is true but the consequent B is false. For example, rule A = {layer:presentation layer, import:data layer} → B = {import:business layer}. If the itemset to be checked contains A but not B, a detection result indicating that the target code violates the association rule is generated. Alternatively, based on the historical association rule "modifying controllers and importing models usually involves service calls," if the target code does not contain service layer calls, it will be determined that it violates implicit architectural constraints, generating a detection result indicating that the target code violates the association rule.

[0047] It should be noted that the detection results of the above-mentioned rule violation detection, hierarchical rule violation detection, and circular dependency rule violation detection can all be accompanied by detailed violation information. The violation information can specifically include the path of the violating file, the dependent file, the type of violation, and the severity of the violation, which helps to quickly understand the rule violation scenario and reduce misunderstandings and logical jumps.

[0048] In this embodiment of the application, by performing association rule violation detection, layer rule violation detection, and circular dependency rule violation detection on the target code, the target code can be detected from multiple dimensions, thereby providing an accurate basis for the repair of the target code.

[0049] In one possible implementation, if the extracted itemset satisfies the antecedent being true and the consequent being false in the association rule in the architecture baseline model, the process of generating a detection result indicating that the target code violates the association rule may further include: If the extracted itemset satisfies the condition that the antecedent of the association rule in the architecture baseline model is true and the consequent is false, then the severity of the association rule violation is marked according to the confidence level and / or historical repair records corresponding to the violated association rule, and a detection result indicating that the target code violates the association rule is generated.

[0050] When generating detection results indicating that target code violates association rules, the confidence level of association rules in the architecture baseline model and historical remediation records can be combined to label the severity. Confidence level reflects the credibility of a rule, indicating the probability that the consequent will be true if the antecedent is true. The higher the confidence level, the more generally the team adheres to the rule, and the higher the risk and severity of the violation. For example, a rule with a confidence level of 77.5% can be labeled as medium-risk. Historical remediation records reflect architectural habits that are not documented but generally followed by the team. Historical remediation records can reflect the cost and scope of remediation for similar violations, avoiding the one-sidedness of judging solely by confidence level. If the historical remediation rate for similar violations is high (e.g., 90% were remediated), the remediation time is long (e.g., an average of 4 hours), or it has caused online issues, the severity can be upgraded (e.g., from medium-risk to high-risk). If similar violations are mostly marked as reasonable evolutions (e.g., temporary violations during architecture refactoring) and have low remediation costs (e.g., 10 minutes), the severity can be downgraded (e.g., from high-risk to medium-risk). By employing a combined judgment mechanism of confidence level and historical remediation records, rather than a single indicator, misjudgments that may arise from relying solely on confidence level can be avoided. For example, a rule might have a high confidence level, but historical violations have all been marked as reasonable evolutions (such as temporary dependencies during architecture refactoring). Marking it as high-risk based solely on confidence level would increase unnecessary remediation costs. By combining historical remediation records with key information such as the violation's remediation rate, remediation time, and whether it caused online issues, the actual risk level of the violation can be reflected. Severity is calculated using a weighted approach of dual indicators (e.g., severity = confidence level × 0.6 + historical risk indicated by historical remediation records × 0.4), genuine violations and false positives can be effectively distinguished. Violations with high confidence and high actual risk are prioritized for marking, allowing developers to focus on core issues and improving governance efficiency.

[0051] In this embodiment, by annotating the severity of target code violations of association rules, abstract association rules are transformed into violation governance actions that developers can understand and implement, ensuring both objectivity and practicality in detection. When generating detection results indicating target code violations of association rules, a severity score is calculated based on the rule's support, confidence, historical impact range, and the importance of the violating module. This prioritizes anomaly patterns with the highest potential risk among a large number of violations, improving developers' remediation efficiency.

[0052] In one possible implementation, the process of detecting architectural drift in the target code may also include: outputting a health score based on the detection results and the coupling degree of the target code, and generating review recommendations based on the relationship between the health score and the score threshold.

[0053] After obtaining the detection results for various violations in the target code, a health score can be calculated by combining the severity of the violations, the specific rules violated, and the coupling degree of the target code. Code coupling degree is a core quality indicator of architecture.

[0054] Specifically, when conducting health assessments, weights can be assigned to the coupling degree between various violations and the target code. For example, the weight for violating association rules is 40%, with points deducted based on the severity of the violation: a base score of 100 points minus (number of high-risk violations × 15 + number of medium-risk violations × 8 + number of low-risk violations × 3). The coupling degree of the target code has a weight of 30%, calculated based on the dependency density between modules (lower coupling results in a higher score): coupling degree ≤ 0.3 → 30 points, 0.3~0.6 → 15 points, > 0.6 → 0 points. The weight for violating layering rules is 20%, calculated as (1 - number of violations / layering constraint rules in the architecture baseline model) × 20. The weight for violating circular dependency rules is 10%, calculated based on the complexity of strongly connected components. Target code with excessively low health scores can be rejected or prompted for manual review. The weights of the coupling degree between various violations and the target code are determined based on the project's historical statistical distribution or industry experience and support adaptive adjustment. Specifically, the weighting criteria can include: 1. Industry experience-based weighting benchmarks, referencing the SEI architecture complexity assessment model, setting initial weights of 40% for rule compliance, 30% for coupling, 20% for layered violations, and 10% for circular dependencies; 2. Historical statistical calibration of projects, analyzing violation remediation data from the past 12 months, automatically increasing the weight of a certain type of violation (such as circular dependencies) by 5%-10% if the remediation cost exceeds 30%. Adaptive adjustment mechanisms can include: quarterly correlation analysis between historical scores and actual architectural issues to dynamically optimize weight allocation. For example, if the false positive rate of layered violations remains below 5% and is strongly correlated with the degree of architectural corruption (correlation coefficient ≥ 0.8), its weight will be appropriately increased.

[0055] In this embodiment of the application, a health score is output based on the coupling degree between the detection results and the target code, which can quantify the abstract architecture governance and thus generate review suggestions that are more user-oriented.

[0056] Specifically, the architecture baseline model is trained based on historical code commits in the version control system. In particular, the architecture baseline model is constructed in the following way: Historical commit code information within a first time period is extracted from the version control system. A second transaction object set is generated based on the information corresponding to each commit in the historical commit code information. The second transaction objects in this set are used to structurally describe the single code commit information corresponding to the historical commit code information. An itemset set is generated from the second transaction object set. Association rules are generated from the itemset set, and an architecture baseline model is generated based on the association rules and the architecture constraints corresponding to the version control system.

[0057] To construct the architecture baseline model, historical commit code information within a first time period can be extracted from the version control system. For example, the first time period could be the three months prior to the build date. After obtaining the historical commit code information, a second transaction object set corresponding to the information for each commit can be generated. This historical commit code information includes hashes, timestamps, authors, commit messages, and a list of changed files. When the change type is adding or modifying files, syntax-level parsing can be performed. Then, an Abstract Syntax Tree (AST) is used to analyze import statements and dependent modules, while inferring the architecture layer from file paths. For example, paths containing "controllers" indicate the presentation layer, "services" indicate the business layer, and "models" or "repositories" indicate the data layer. All information is integrated into a second transaction object {commit_id, files, imports, layers}. Next, an itemset set is generated based on the second transaction object set to facilitate association rule mining. Finally, association rules are generated based on the itemset set, and the architecture baseline model is generated based on these association rules and the corresponding architecture constraints of the version control system.

[0058] In this embodiment of the application, by extracting historical code commit information within the first time period from the version control system, the extraction efficiency and consistency of architecture data are significantly improved, providing a unified data foundation for the subsequent construction of the architecture baseline model. Furthermore, through the data processing of version history and the mining of association rules, the implicit dependency patterns formed by the team in long-term collaboration can be automatically learned, and the constructed architecture baseline model can reduce a large number of false alarms compared to traditional manual rule systems.

[0059] In one possible implementation, the process of generating association rules based on the itemset set and generating an architecture baseline model based on the association rules and the architecture constraints corresponding to the version control system may further include: Frequent itemsets with support greater than a first threshold are mined from the itemset set, and the items included in the frequent itemsets are split to obtain multiple candidate rules. The support is used to characterize the probability of an itemset being submitted in the first time period. The confidence and lift of each candidate rule are calculated based on the support of the frequent itemsets, and the candidate rules with confidence greater than a second threshold and lift greater than a third threshold are identified as association rules. An architecture baseline model is generated based on the association rules and the architecture constraints corresponding to the version control system.

[0060] When generating the baseline architecture model, after obtaining the itemset set, frequent itemset mining can be performed first to identify frequently co-occurring architectural feature combinations. For example, algorithms such as Apriori, FP-Growth, or Eclat can be used. These algorithms are based on the same frequent pattern mining principle, and the output frequent itemsets and association rules are semantically equivalent. The appropriate algorithm can be selected based on data scale and performance requirements. For instance, when performing frequent itemset mining, a support threshold can be set as the first threshold (default 30%) to filter out itemsets that appear more frequently than the first threshold (e.g., {layer: presentation layer, import: business layer} appears in 40% of submissions, becoming a frequent itemset). Then, iterative generation of higher-order frequent itemsets (from 1-itemset → 2-itemset → … → k-itemset) is performed until no new frequent itemsets can be generated (e.g., stopping when the support of all 3-itemsets is <30%). Next, the items in the frequent itemsets are split, and multiple candidate rules are extracted from them. Then, the confidence and lift of each candidate rule are calculated based on the support of the frequent itemsets. Highly reliable and strongly correlated association rules are selected. For example, for each frequent itemset, all antecedent-consequence combinations are enumerated (e.g., the frequent itemset {A,B} is split into A→B and B→A). Then, the confidence (probability of the consequent occurring when the antecedent occurs) and lift (the promoting effect of the antecedent on the consequent) of each candidate rule are calculated. Finally, association rules with a confidence ≥70% and a lift >1 are retained. The selected association rules are then integrated with hierarchical constraints (e.g., presentation layer → business layer → data layer) and circular dependency baselines (maximum strongly connected component size = 1) to form a structured architectural baseline model.

[0061] Specifically, the architecture baseline model can be updated regularly. The update can be triggered weekly or when the number of new commits reaches a threshold.

[0062] The architecture baseline model is not statically fixed, but rather employs a dual-trigger dynamic update mechanism based on either a time window or the number of commits, ensuring that the model always remains synchronized with the project's architectural evolution. Automatic update trigger conditions can include: 1. Time window trigger: by default, updates are automatically executed every Monday morning, covering nearly 90 days of historical commit data; 2. Commit count trigger: when the number of new code commits reaches 100 (configurable), an incremental update is triggered; 3. Manual trigger: users can manually trigger a full update based on major project refactoring needs.

[0063] Specifically, incremental updates to the rule model are triggered by a sliding time window or by setting a threshold for the number of submissions. Statistical learning is performed on newly added association rules, hierarchical dependency frequencies, and change patterns. The changes in support and confidence before and after the update are compared to determine the direction of project architecture evolution. Based on this mechanism, the system can automatically adapt to project structure adjustments and maintain the stability and accuracy of the detection results even after the architecture evolves.

[0064] By periodically updating the baseline architecture model through incremental learning, the detection results can reflect the latest evolution of the project, thereby significantly reducing misjudgments caused by natural changes in the architecture.

[0065] The process of updating the architecture baseline model may include: generating a temporary baseline model based on new historical data; comparing the rule drift (calculating the ratio of rule additions / deletions / confidence changes) between the temporary model and the currently effective model; if the drift exceeds 20%, generating a rule change report for user review; if the drift is ≤20%, automatically replacing the effective model and retaining historical versions for rollback.

[0066] Furthermore, the baseline model can retain the most recent five versions, supporting time-stamped rollback and allowing for quick revert to any historical version, avoiding detection anomalies caused by unreasonable updates. This dynamic update mechanism enables the architecture baseline model to adapt to the reasonable evolution of the project architecture, solving the problem of frequent false alarms caused by traditional static rule tools and ensuring the timeliness and accuracy of detection rules.

[0067] In this embodiment of the application, multiple candidate rules are obtained by mining frequent itemsets, and an architecture baseline model is constructed based on the filtered association rules to ensure that the architecture baseline model is data-driven, objective, reliable, and dynamically adaptable, providing a solid benchmark support for subsequent drift detection.

[0068] Step 103: When the detection result indicates that the target code violates at least one of the association rule, the hierarchical rule, and the circular dependency rule, the target code is repaired to obtain the repaired code and generate the architecture document of the repaired code.

[0069] When the detection results indicate that the target code violates at least one of the rules of association, layering, and circular dependencies, it proves that the newly submitted target code will cause an architecture drift problem. Therefore, the target code needs to be fixed to resolve the architecture drift issue. After fixing the target code, the fixed code is obtained, and then an architecture document for the fixed code can be generated. The architecture document for the fixed code can include an overview of the fixed code's architecture, layer definitions, key constraints, common patterns, and evolution trends. The key constraints list the core rules that the team must follow, such as "controllers must not directly access the data model" and "circular dependencies are prohibited." The evolution trend section indicates the trend of architecture changes and potential risk points. The architecture document can be updated periodically or automatically generated after the fixed code is submitted to ensure that the architecture document is consistent with the actual code state.

[0070] In this embodiment, by constructing a dependency graph of the target code submitted to the version control system, architectural complexity can be evaluated using graph algorithms, improving the efficiency of subsequent code violation detection. By performing architectural drift detection on the target code based on the architectural baseline model and dependency graph, real-time detection of architectural drift can be achieved, significantly improving the timeliness and accuracy of detection. When the detection results indicate that the target code violates at least one of the rules of association, hierarchical relationships, and circular dependencies, the target code is repaired to obtain the repaired code, and an architectural document of the repaired code is generated, significantly improving repair efficiency and reducing human decision-making costs.

[0071] In one possible implementation, the process of repairing the target code to obtain the repaired code may also include: Based on the rules violated by the target code as indicated by the detection results, at least one remediation plan is generated. From the at least one remediation plan, a target remediation plan is determined, and the target code is refactored according to the target remediation plan to generate the remediated code.

[0072] For rule violations in the target code, multi-level refactoring solutions can be generated for each violation, such as simple fixes, moderate fixes, and full refactoring. Simple fixes involve minimizing code modifications, such as changing direct imports to calls through intermediate layers; moderate fixes include logic extraction or module reorganization; full refactoring is suitable for situations requiring a redefinition of module boundaries. Each fix can include exemplary code differences, expected effects, workload assessment, and potential risk warnings. The fix priority can also be assessed based on the impact of the rule violation and the importance of the module containing the violation. After identifying at least one fix, a target fix can be determined from these, and the target code is refactored according to the target fix to generate the fixed code. The target fix can be determined by user specification or by default modes, such as default moderate fix.

[0073] By generating at least one remediation scheme, developers can be provided with multi-level, selectable remediation options, which significantly improves remediation efficiency and reduces human decision-making costs.

[0074] In one possible implementation, the process of repairing the target code may also include: checking the hierarchical labels included in the target code, and if the checking result indicates that the hierarchical labels of the target code are incorrect, then correcting the hierarchical labels of the target code.

[0075] During the repair process of the target code, it can also be analyzed to determine the code's layer, such as the presentation layer (handling HTTP requests), business layer (implementing business logic), data layer (operating the database), and utility layer (general functions). The analysis results are compared with the initial layer labels in the target code. If they are different, the verification result indicates that the layer label of the target code is incorrect, and the layer label of the target code will be corrected.

[0076] By modifying the hierarchical tags of the target code, it can be further ensured that the target code will not cause architecture drift.

[0077] In one possible implementation, the process of fixing the target code may also include: generating a rule violation description document based on the rules violated by the target code, and outputting the rule violation description document.

[0078] During the code remediation process, the semantic understanding capabilities of large language models can be leveraged to generate personalized rule violation documentation tailored to the developer's experience level, explaining the rule violations in the target code. For less experienced developers, the rule violation documentation can provide detailed explanations, outlining the reasons for the violation, the violated architectural principles, potential technical debt, and possible impacts. The documentation can also employ a guiding approach to help them understand the importance of architectural constraints. For experienced developers, the documentation can provide concise technical descriptions, directly pointing to the location of the violation and the direction for remediation.

[0079] Furthermore, when generating rule violation documentation, similar cases from the project's history can be cited to illustrate the team's past solutions, thereby enhancing the relevance and persuasiveness of the explanation. For example, for cross-layer access violations, the rule violation documentation could generate the following explanation: In this submission, the controller directly imported the model module, bypassing the business layer. Based on historical analysis, the team typically accesses the model indirectly through the service layer to maintain logical encapsulation. It is recommended to follow the existing pattern and implement data access through the business layer.

[0080] The generated rule violation documentation enhances the understandability and operability of violation feedback through semantic interpretation, reducing the cognitive burden on developers and promoting consistent implementation of architectural specifications.

[0081] Figure 2 This is a schematic diagram of a code architecture drift repair system according to an embodiment of this application, as shown below. Figure 2 As shown, the code architecture drift repair system 20 includes: The code analysis layer 21 is used to construct a dependency graph of the target code submitted to the version control system 30, wherein the dependency graph indicates the dependencies between files in the target code. The detection layer 22 is used to perform architecture drift detection on the target code based on the architecture baseline model and the dependency graph, obtaining detection results, wherein the architecture baseline model is trained based on historical code submissions in the version control system 30. The repair layer 23 is used to repair the target code when the detection results indicate that the target code violates at least one of the association rule, hierarchical rule, and circular dependency rule, obtaining the repaired code and generating an architecture document for the repaired code.

[0082] When a user submits code to the version control system 30, the code analysis layer 21 constructs a dependency graph of the target code. The target code is the newly submitted code, and the dependency graph indicates the dependencies between files within the target code. After obtaining the dependency graph, the detection layer 22 performs architecture drift detection on the target code based on the architecture baseline model and the dependency graph. Specifically, the architecture baseline model can identify whether the newly submitted target code exhibits any violations. The architecture baseline model can perform multiple checks on the target code, including association rule violations, layering rule violations, and circular dependency rule violations, and outputs the detection results. When the detection results indicate that the target code violates at least one of the association rule, layering rule, and circular dependency rule, it proves that the newly submitted target code will cause an architecture drift problem. Therefore, the repair layer 23 needs to repair the target code to resolve the architecture drift problem. After repairing the target code, the repair layer 23 obtains the repaired code, and then generates an architecture document for the repaired code. The architecture document for the repaired code may include an overview of the architecture, layer definitions, key constraints, common patterns, and evolutionary trends. The key constraints section lists the core rules that the team must follow, such as "controllers must not directly access the data model" and "circular dependencies are prohibited." The evolution trend section indicates the trend of architectural changes and potential risks. The architecture document can be updated regularly or automatically generated after code fixes are committed, ensuring that the architecture document is consistent with the actual code state.

[0083] In this embodiment, the code analysis layer 21 constructs a dependency graph of the target code submitted to the version control system 30, enabling the evaluation of architectural complexity using graph algorithms and improving the efficiency of subsequent code violation detection. The detection layer 22 performs architectural drift detection on the target code based on the architectural baseline model and dependency graph, achieving real-time detection of architectural drift and significantly improving the timeliness and accuracy of detection. The repair layer 23 repairs the target code when the detection results indicate that the target code violates at least one of the association rule, hierarchical rule, and circular dependency rule, obtaining the repaired code and generating an architectural document of the repaired code, which significantly improves repair efficiency and reduces human decision-making costs.

[0084] In one possible implementation, before calling the large language model to generate explanations or fixes, the code architecture drift repair system 20 can first construct a semantic summary based on the abstract syntax tree to identify the true responsibility boundaries of the target code. The repair layer 23 can select the corresponding prompt template to generate explanation text based on different violation types detected by the detection layer 22, and automatically adjust the information granularity according to the developer's experience level. After the repair layer 23 generates the refactored code, syntax tree consistency checks and static analysis can also be performed to ensure that the refactoring result can be correctly compiled and conforms to modularity constraints. In one possible implementation, such as... Figure 3 As shown, the code analysis layer 21 includes: a history mining tool 211, a code analysis engine 212, and an intelligent rollback module 213.

[0085] History mining 211 is used to generate a first set of transaction objects based on the target code, and code analysis engine 212 is used to construct a dependency graph of the target code based on the first set of transaction objects.

[0086] Git history contains a wealth of valuable information about team coding patterns, but this information has never been systematically mined and utilized. Implicit architectural constraints formed during long-term team collaboration—for example, modifying a module often involves modifying related test files, or the controller layer rarely directly accesses the data model—are buried deep within Git history, undiscovered. Therefore, the history miner 211 can first retrieve a period of historical code commit records from the Git version control system 30. This period is balanced between data freshness and statistical representativeness, defaulting to a time period close to the current moment, such as the time period from three days ago to the current moment. The history miner 211 obtains the target code based on the historical code commit records, generates the first set of transaction objects, and the code analysis engine 212 constructs the dependency graph of the target code.

[0087] Specifically, the first transaction object set includes first transaction objects used to structurally describe the single code commit information corresponding to the target code. This single code commit information includes metadata such as commit_hash and timestamp. The single code commit information is then parsed, including AST extraction of dependencies and inference of layers based on file paths (e.g., paths containing "controllers" indicate the presentation layer, "services" indicate the business layer, and "models" or "repositories" indicate the data layer). This integrates the single code commit information into a first transaction object containing multi-dimensional information. The first transaction object can include all files modified during the single code commit, relevant import statements, and affected architectural layers. When the target code includes code from multiple commits, the first transaction object set generated by the history mining engine 211 will contain multiple first transaction objects. After obtaining the first transaction object set, the code analysis engine 212 parses the import statements in the first transaction objects within the set, constructs a file-dependency file mapping, and then merges the dependencies of multiple first transaction object commits to form the dependency graph of the target code. Nodes in a dependency graph indicate files or modules, and edges in a dependency graph indicate the direction of dependency.

[0088] The intelligent rollback module 213 is used to generate rollback suggestions when the target code causes architectural drift, resulting in a failure or serious violation of the version control system 30.

[0089] Situations where target code causes architectural drift, leading to malfunctions or serious violations in version control system 30, can include: violations in the target code causing online failures (such as deadlocks due to circular dependencies, or data inconsistencies due to cross-layer access). In this case, the intelligent rollback module 213 automatically associates "fault log → architecture detection record," locates "the commit version that caused the failure + the violating code," quickly assesses the rollback scope (e.g., only rollback the code in the commit where "the presentation layer directly depends on the data layer," retaining other functional modifications), and generates a rollback suggestion indicating that a rollback is necessary. If the drift detection blocking mechanism of detection layer 22 is bypassed (e.g., high-violation commits are manually allowed during emergency repairs), detection layer 22 will monitor the architecture health in real time. If the score drops sharply (e.g., from 90 points to 50 points) and the danger level corresponding to the violation type is high (e.g., circular dependencies in core modules), a rollback suggestion indicating that a rollback is necessary will be generated. When the user instructs a rollback, the intelligent rollback module 213 will perform a rollback operation on the target code committed in version control system 30.

[0090] Specifically, the code analysis engine 212 can extract key fields from the first transaction object and convert them into atomic items in key:value format (such as extracting file:xxx, layer:xxx, and import:xxx from changed_files_info), ultimately forming itemsets. Based on these itemsets, a set of itemsets is obtained, and the dependencies between code segments are further analyzed to construct a dependency graph of the target code. Forming itemsets from the first transaction object enables a flattening transformation of structured data, making the logic for generating the dependency graph relatively simple.

[0091] In this embodiment of the application, by setting up an intelligent rollback module 213, rollback suggestions can be provided to developers in a timely manner, and when the developer indicates that a rollback is required, the intelligent rollback module 213 can perform a full / partial rollback, accurately associate the rollback range when performing a partial rollback, and improve rollback efficiency.

[0092] In one possible implementation, such as Figure 4 As shown, the detection layer 22 includes: an architecture baseline model 221 and a drift detection module 222.

[0093] The drift detection module 222 is used to perform architectural drift detection on the target code based on the architectural baseline model 221 and the dependency graph, and obtain the detection results.

[0094] Specifically, the drift detection module 222 is also used to determine the strongly connected components in the target code based on the dependency graph. If the strongly connected components include at least two nodes, a detection result indicating that the target code violates the circular dependency rule is generated.

[0095] The purpose of circular dependency detection is to identify closed dependencies between modules (such as A→B→C→A). These closed dependencies originate from the architectural baseline model. The dependency graph can be traversed using the Tarjan algorithm, Kosaraju algorithm, or a simpler depth-first search method to locate all strongly connected components (SCCs). The time complexity of the Tarjan algorithm, Kosaraju algorithm, and the simpler depth-first search method is O(V+E) or close to it, and the detection accuracy is the same. A strongly connected component is a core concept in graph theory describing bidirectional reachability between vertices in a directed graph. It is defined as a maximal subgraph in a directed graph where any two vertices are bidirectionally reachable. If a strongly connected component contains ≥2 nodes, a detection result indicating that the target code violates the layering rule is generated. For example, if the dependency graph contains user_controller→user_service→user_model→user_controller, the Tarjan algorithm identifies this 3-node strongly connected component and generates a detection result indicating that the target code violates the circular dependency rule.

[0096] The drift detection module 222 is also used to determine the correspondence between the source layer and the dependency layer in the target code based on the dependency graph. If the correspondence violates the layering constraint rules in the architecture baseline model 221, a detection result indicating that the target code violates the layering rules is generated.

[0097] The purpose of layered rule detection is to identify dependencies that violate the hierarchical access order (such as reverse dependencies, cross-layer access, etc.), where the hierarchical access order is defined by the layered constraint rules in the architecture baseline model 221. For example, if the layered constraint rule in the architecture baseline model 221 is presentation layer → business layer → data layer, and the correspondence between the source layer and the dependent layer in the target code is data layer → business layer, then the target layer is upstream of the source layer in the legal dependency chain, resulting in a reverse dependency. If the correspondence between the source layer and the dependent layer in the target code is presentation layer → data layer, skipping the business layer, then the source layer and the target layer skip the intermediate layer, resulting in cross-layer access. Both of these situations will generate detection results indicating that the target code violates the layered rules.

[0098] The drift detection module 222 is also used to extract itemsets in the target code. If the extracted itemsets satisfy the antecedent of the association rule in the architecture baseline model but do not satisfy the consequent of the association rule in the architecture baseline model 221, a detection result indicating that the target code violates the association rule is generated.

[0099] The purpose of association rule detection is to identify behaviors that violate the team's implicit architectural habits (such as the presentation layer depending on the data layer but not on the business layer). First, extract the itemsets from the target code, such as {layer:presentation layer, import:data layer}. Then, traverse the association rules in the baseline architecture model, checking for situations where the antecedent A of a rule is true but the consequent B is false. For example, rule A = {layer:presentation layer, import:data layer} → B = {import:business layer}. If the itemset to be detected contains A but not B, a detection result indicating that the target code violates the association rule is generated.

[0100] It should be noted that the detection results of the above-mentioned multiple detections, such as association rule violation detection, layer rule violation detection, and circular dependency rule violation detection, can all be accompanied by detailed violation information. The violation information can specifically include the path of the violating file, the dependent file, the type of violation, and the severity of the violation.

[0101] In this embodiment of the application, the drift detection module 222 can detect the target code from multiple dimensions by performing association rule violation detection, hierarchical rule violation detection, and circular dependency rule violation detection on the target code, thereby providing an accurate basis for the repair of the target code.

[0102] In one possible implementation, the drift detection module 222 is further configured to, if the extracted itemset satisfies the antecedent of the association rule in the architecture baseline model and satisfies the consequent, mark the severity of the association rule violation based on the confidence level and / or historical repair records corresponding to the violated association rule, and generate a detection result indicating that the target code violates the association rule.

[0103] When generating detection results indicating that the target code violates association rules, the confidence level of the association rules in the architecture baseline model 221 and the severity level of historical remediation records can be combined. Confidence level reflects the credibility of the rule, indicating the probability that the consequent will be true when the antecedent is true. The higher the confidence level, the more generally the team follows the rule, and the higher the risk and severity of the violation. For example, a rule with a confidence level of 77.5% can be marked as medium-risk. Historical remediation records reflect architectural habits that are not documented but generally followed by the team. Historical remediation records can reflect the cost and scope of remediation for similar violations, avoiding the one-sidedness of judging solely by confidence level. If the historical remediation rate for similar violations is high (e.g., 90% were remediated), the remediation time is long (e.g., an average of 4 hours), or it has caused online issues, the severity level can be upgraded (e.g., from medium-risk to high-risk). If similar violations are mostly marked as reasonable evolution (e.g., temporary violations during architecture refactoring) and the remediation cost is low (e.g., 10 minutes), the severity level can be downgraded (e.g., from high-risk to medium-risk).

[0104] In this embodiment, the drift detection module 222 transforms the abstract association rules into actionable violations that developers can understand and implement by marking the severity of the target code's violation of association rules. This ensures both the objectivity of the detection and its practicality.

[0105] In one possible implementation, the drift detection module 222 is also used to output a health score based on the coupling degree between the detection result and the target code, and to generate review suggestions based on the relationship between the health score and the score threshold.

[0106] After the drift detection module 222 obtains the detection results of various violations in the target code, it can combine the severity of the violation / the specific rule violated, and the coupling degree of the target code to calculate a health score. Code coupling degree is a core quality indicator of the architecture.

[0107] Specifically, when performing health scoring, the drift detection module 222 can assign weights to the coupling degree between various violations and the target code. For example, the weight for violating association rules is 40%, and points are deducted based on the severity of the violation: base score 100 points - (number of high-risk violations × 15 + number of medium-risk violations × 8 + number of low-risk violations × 3). The coupling degree of the target code has a weight of 30%, calculated based on the inter-module dependency density (the lower the coupling degree, the higher the score): coupling degree ≤ 0.3 → 30 points, 0.3~0.6 → 15 points, > 0.6 → 0 points. The weight for violating layering rules is 20%, calculated as (1 - number of violations / layering constraint rules in the architecture baseline model) × 20. The weight for violating circular dependency rules is 10%, and the health score is calculated based on the complexity of strongly connected components. Target code with a low health score can be rejected for submission or prompted for manual review.

[0108] It should be noted that the weights assigned to the health score can be determined through statistical analysis of historical violation records, repair costs, module coupling, and scope of impact. The weights of different types of violations are dynamically adjusted based on their risk level in the system's evolution.

[0109] In this embodiment, a health score is output based on the coupling degree between the detection results and the target code. This quantifies abstract architectural governance, resulting in more user-oriented review recommendations. Adjustable weights reflect the real impact of different architectural issues in the project, making the health score interpretable and objective.

[0110] In one possible implementation, such as Figure 5 As shown, the repair layer 23 includes: a code intent classification module 231, a violation explanation module 232, a repair suggestion generation module 233, a code refactoring module 234, and an architecture document generation module 235.

[0111] The code intent classification module 231 is used to check the hierarchical labels included in the target code. If the check result indicates that the hierarchical labels of the target code are incorrect, the hierarchical labels of the target code are corrected.

[0112] During the repair process of the target code, the code intent classification module 231 can also analyze the target code to determine its layer, such as the presentation layer (handling HTTP requests), business layer (implementing business logic), data layer (operating the database), and utility layer (general functions). The code intent classification module 231 compares the analysis results with the initial layer labels in the target code. If they are different, the verification result indicates that the layer label of the target code is incorrect, and the code intent classification module 231 will correct the layer label of the target code.

[0113] In static rule systems for architecture detection, the determination of file / module hierarchy (e.g., presentation layer, business layer, data layer) typically relies on directory paths (e.g., controllers / belongs to the presentation layer, services / belongs to the business layer) or file naming prefixes (e.g., UserController.java belongs to the presentation layer). This formalized approach has significant flaws, leading to a high false positive rate. Correcting the hierarchy labels of target code through the code intent classification module 231 further ensures that the target code does not cause architecture drift. The code intent classification module 231 analyzes the code structure and naming semantics in the target code to determine the true responsibility of files, thereby correcting erroneous hierarchy judgments caused by irregular directory structures or inconsistent naming. This significantly reduces common false positives in conventional static rule systems and improves the accuracy of detecting hierarchical violations and rule breaches.

[0114] The violation explanation module 232 is used to generate a rule violation explanation document based on the rules violated by the target code, and output the rule violation explanation document.

[0115] During the code remediation process, the violation explanation module 232 can also leverage the semantic understanding capabilities of a large language model to generate personalized rule violation documentation tailored to the developer's experience level, explaining the rule violations in the target code. The large language model can be GPT-4, Claude, Gemini, or open-source models such as Llama. Different models vary in accuracy, quality, and speed, but all can accomplish the code understanding and generation tasks. A hybrid strategy can be employed to balance effectiveness and cost, and temperature parameters can be adjusted as needed. For less experienced developers, the rule violation documentation provides detailed explanations, outlining the reasons for the violation, the violated architectural principles, potential technical debt, and possible impacts. The documentation can also provide guidance to help them understand the importance of architectural constraints. For experienced developers, the documentation outputs concise technical descriptions, directly pointing out the location of the violation and the direction for remediation. Specifically, for developers with less experience (e.g., 1-2 years), the rule violation documentation can include: 1. Structure: Violation → Architectural Principles → Potential Risks → Remedial Steps → Sample Code; 2. Content: Use plain language, avoid jargon, and provide detailed step-by-step guidance, such as "Step 1: Remove the direct import of UserRepository in UserController; Step 2: Inject UserService; Step 3: Call the query method through UserService"; 3. Enhancement: Add relevant architectural principle explanations, such as "This violation violates the 'layered architecture isolation principle,' business logic should be concentrated in the service layer, and the controller is only responsible for request forwarding." For experienced developers (3+ years), rule violation documentation can include: 1. Structure: Violation location → Violation type → Remediation direction → Performance impact; 2. Content: Concise technical description highlighting core information, such as "UserController directly depends on UserRepository (cross-layer access), it is recommended to forward through UserService, with no performance loss"; 3. Enhancement: Provide a comparison of the advantages and disadvantages of multiple remediation solutions, such as "Solution A: Service layer forwarding (low development cost, good compatibility); Solution B: Refactor the data access interface (better for long-term maintenance, requires modification of 3 related modules)". Generation control can be used when generating rule violation documentation. For example, a Prompt template can be used to solidify the generation structure, and temperature parameters (less experienced developers → temperature 0.3, experienced developers → temperature 0.1) can be used to control output stability and ensure consistent explanation style for similar violations.

[0116] Furthermore, when generating rule violation documentation, similar cases from the project's history can be cited to illustrate the team's past solutions, thereby enhancing the relevance and persuasiveness of the explanation. For example, for cross-layer access violations, the rule violation documentation could generate the following explanation: In this submission, the controller directly imported the model module, bypassing the business layer. Based on historical analysis, the team typically accesses the model indirectly through the service layer to maintain logical encapsulation. It is recommended to follow the existing pattern and implement data access through the business layer.

[0117] The generated rule violation documentation enhances the understandability and operability of violation feedback through semantic interpretation, reducing the cognitive burden on developers and promoting consistent implementation of architectural specifications.

[0118] The repair suggestion generation module 233 is used to generate at least one repair scheme based on the rules violated by the target code indicated by the detection results, and to determine the target repair scheme from the at least one repair scheme.

[0119] For rule violations in the target code, the remediation suggestion generation module 233 can generate multi-level refactoring solutions for each rule violation, such as simple remediation, medium remediation, and full refactoring. Simple remediation solutions involve minimizing code modifications, such as changing direct imports to calls through intermediate layers; medium remediation solutions include logic extraction or module reorganization; full refactoring solutions are suitable for situations requiring a redefinition of module boundaries. Each remediation solution can include exemplary code differences, expected effects, workload assessment, and potential risk warnings. It can also assess remediation priority based on the impact scope of the rule violation and the importance of the module containing the violation. After determining at least one remediation solution, the remediation suggestion generation module 233 can determine the target remediation solution from among them. The remediation suggestion generation module 233 can determine the target remediation solution by user specification or by default mode, such as default medium remediation. The applicable conditions for simple remediation (minimum modification) are: violation impact scope ≤ 1 file, number of lines of modified code ≤ 10 lines, and no cross-module dependency changes. It is preferred when the project is in the iteration sprint phase (≤ 7 days before release) or when the violating module is a core stable module. Medium-level remediation (logic restructuring) is suitable when: the violation affects 2-3 files, 10-50 lines of code need to be modified, and module dependencies need to be adjusted. This is the preferred option when the project is in a regular iteration scenario and the violation involves core business logic. Full-scale refactoring (architectural adjustment) is suitable when: the violation affects ≥4 files, ≥50 lines of code need to be modified, and module boundaries or dependencies need to be adjusted. This is the preferred option when the project is in a refactoring phase and the violation has caused severe architectural decay (health score ≤60).

[0120] For multiple remediation options, the remediation suggestion generation module 233 can sort the options based on historical remediation records, modification intrusion and scope of impact, so that the remediation suggestions have decision-making basis and reproducibility.

[0121] By generating at least one remediation scheme, developers can be provided with multi-level, selectable remediation options, which significantly improves remediation efficiency and reduces human decision-making costs.

[0122] The code refactoring module 234 is used to repair the target code and obtain the repaired code when the detection result indicates that the target code violates at least one of the association rule, the hierarchical rule, and the circular dependency rule.

[0123] When the detection results indicate that the target code violates at least one of the association rule, hierarchical rule, and circular dependency rule, it proves that the newly submitted target code will cause an architecture drift problem. Therefore, the code refactoring module 234 needs to repair the target code to resolve the architecture drift problem. After repairing the target code, the code refactoring module 234 obtains the repaired code.

[0124] Specifically, the code refactoring module 234 can refactor the target code based on the target repair scheme generated by the repair suggestion generation module 233, and generate the repaired code.

[0125] To ensure the generated refactored code is executable and error-free, a closed-loop process of generation, verification, and optimization can be established: In the code generation phase, based on the violation type and repair plan, a large language model is invoked to generate refactored code, while simultaneously providing project coding standards (such as naming style, comment requirements, and dependency import rules). Then, in the syntax verification phase, the corresponding programming language's syntax parser (e.g., Java → javac, Python → pyflakes) is invoked for syntax checking. If syntax errors are found, error information is extracted and fed back to the large language model, generating correction instructions. The functionality of the code before and after refactoring is then compared, and functional consistency is verified through unit test cases (requiring a test pass rate ≥ 95%). In the static analysis phase, tools such as SonarQube are used to detect code smells (such as duplicate code and excessive coupling), and the consistency of the refactored code with the existing project code style (such as indentation format and variable naming) is checked. Finally, in the optimization feedback phase, if syntax verification or static analysis fails, the problem list is converted into natural language instructions to drive the large language model to iteratively optimize the code, supporting up to three iterations. If it still fails, a semi-finished code requiring manual completion and a problem description are output.

[0126] Architecture document generation module 235 is used to generate architecture documents for the repaired code based on the repaired code.

[0127] The architecture document generation module 235 can generate an architecture document for the patched code based on the patched code. This document can include an overview of the patched code's architecture, layer definitions, key constraints, common patterns, and evolution trends. The key constraints list the core rules the team must adhere to, such as "controllers must not directly access the data model" and "circular dependencies are prohibited." The evolution trend section indicates the trend of architectural changes and potential risks. The architecture document generation module 235 can periodically update or automatically generate the architecture document after the patched code is committed, ensuring that the architecture document remains consistent with the actual code state. The architecture document generated by the module 235 can be output to the user terminal 40.

[0128] The code architecture drift repair system 20 provided in this application embodiment achieves significant technical performance improvements through multi-dimensional technological innovation, specifically including: 1. Dependency graph query performance optimization: By adopting a combination of path compression and LRU caching mechanism, the node query response time of the dependency graph is reduced by more than 60%. In a large project with 1000+ files, the time taken for a single complete dependency traversal is controlled within 50ms, which meets the real-time detection requirements of CI / CD process. 2. Enhanced configuration parsing reliability: By using a deep merging strategy to process multi-level YAML (a highly readable format used to express data serialization) configuration files, it automatically identifies and retains valid configurations when there are subkey conflicts, avoiding the subkey loss problem caused by traditional merging, and improving the configuration parsing accuracy to 99.8%; 3. Service continuity assurance: A hot-reloading mechanism is introduced to dynamically update the architecture baseline model and rule set. New configurations can be applied without restarting the detection service. The model update window is shortened from minutes to seconds, greatly improving the system's real-time response capability. 4. Improved Repair Efficiency: By generating directly executable refactoring code through repair layer 23, combined with automated syntax checking and static analysis, the repair time for simple violation scenarios is reduced from an average of 30 minutes to within 5 minutes, and the decision-making efficiency for repairing complex scenarios is improved by 70%. 5. Reduced false positive rate: Combining a dual judgment mechanism of confidence weighting and historical repair records, the false positive rate of rule violation detection has been reduced from 25%-35% of traditional tools to below 8%, significantly reducing the cost of ineffective investigation for developers.

[0129] In this embodiment, an electronic device 600 is provided, such as... Figure 6 As shown, the electronic device 600 may include: a processor 601, a communications interface 602, a memory 603, and a communication bus 604. Wherein: The processor 601, communication interface 602, and memory 603 communicate with each other via communication bus 604.

[0130] Communication interface 602 is used for communication with other electronic devices or servers.

[0131] The processor 601 is used to execute program 605, specifically to execute the relevant steps in the aforementioned code architecture drift repair method embodiment.

[0132] Specifically, program 605 may include program code that includes computer operation instructions.

[0133] Processor 601 may be a CPU, an Application Specific Integrated Circuit (ASIC), or configured as one or more integrated circuits. A smart device may include one or more processors, which can be of the same type, such as one or more CPUs; or they may be of different types, such as one or more CPUs and one or more ASICs.

[0134] Memory 603 is used to store program 605. Memory 603 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0135] Specifically, program 605 can be used to cause processor 601 to execute the code architecture drift repair method in the foregoing embodiments.

[0136] The specific implementation of each step in program 605 can be found in the corresponding steps and units described in the aforementioned code architecture drift repair method embodiment, and will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here.

[0137] The electronic device 600 of this application embodiment, by constructing a dependency graph of the target code submitted to the version control system, can evaluate architectural complexity in the form of a graph algorithm and improve the efficiency of subsequent code violation detection. By performing architectural drift detection on the target code based on the architectural baseline model and dependency graph, real-time detection of architectural drift can be achieved, significantly improving the timeliness and accuracy of detection. By repairing the target code when the detection result indicates that the target code violates at least one of the rules of association, hierarchical, and circular dependency, obtaining the repaired code, and generating an architectural document of the repaired code, the repair efficiency can be significantly improved and the cost of human decision-making can be reduced.

[0138] In this embodiment, a computer-readable storage medium is provided to store instructions for causing a machine to execute the code architecture drift repair method as described herein. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0139] In this case, the program code read from the storage medium can itself implement the functions described in the above method embodiments, so the program code and the storage medium storing the program code constitute a part of this application.

[0140] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0141] In this embodiment, a computer program product is provided, including computer instructions that instruct a computing device to perform the operations corresponding to the above method embodiments.

[0142] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0143] The methods described above according to embodiments of this application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or implemented as computer code originally stored on a remote recording medium or a non-transitory machine-readable medium and to be stored on a local recording medium after being downloaded over a network. Thus, the methods described herein can be stored on such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for performing the methods shown herein. Although this application has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art based on a reading and understanding of this specification and the accompanying drawings. This application includes all such modifications and variations and is limited only by the scope of the appended claims. In particular, with respect to the various functions performed by the aforementioned components, the terminology used to describe such components is intended to correspond to any component (unless otherwise indicated) that performs the specified function of said component (e.g., is functionally equivalent to it), even if it is not structurally equivalent to the disclosed structure that performs the functions in the exemplary implementations of this specification shown herein.

[0144] That is, the above description is only an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made using the content of this application’s specification and drawings, such as the combination of technical features between different embodiments, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of this application.

[0145] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0146] The above description is provided to enable any person skilled in the art to implement and use this application. Various details are set forth in the above description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other embodiments, well-known processes will not be described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0147] It should be noted that, without conflict, the various embodiments and / or technical features described in this application can be arbitrarily combined with each other, and the resulting technical solutions should also fall within the protection scope of this application.

[0148] It should be understood that the specific examples in the embodiments of this application are only for the purpose of helping those skilled in the art to better understand the embodiments of this application, and are not intended to limit the scope of the embodiments of this application. Those skilled in the art can make various improvements and modifications based on the above embodiments, and all such improvements or modifications fall within the protection scope of this application. The above descriptions are merely specific implementations of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for repairing code architecture drift, characterized in that, include: Construct a dependency graph of the target code to be submitted to the version control system, wherein the dependency graph is used to indicate the dependencies between files in the target code; The target code is subjected to architecture drift detection based on the architecture baseline model and the dependency graph to obtain the detection results. The architecture baseline model is obtained by training based on the historical commit code in the version control system. When the detection result indicates that the target code violates at least one of the association rule, the hierarchical rule, and the circular dependency rule, the target code is repaired to obtain the repaired code, and an architecture document of the repaired code is generated.

2. The method according to claim 1, characterized in that, The step of repairing the target code to obtain the repaired code includes: Based on the rules violated by the target code as indicated by the detection results, generate at least one remediation plan; A target repair scheme is determined from the at least one repair scheme, and the target code is refactored according to the target repair scheme to generate the repaired code.

3. The method according to claim 2, characterized in that, The method further includes: The hierarchical tags included in the target code are checked. If the check result indicates that the hierarchical tags of the target code are incorrect, the hierarchical tags of the target code are corrected.

4. The method according to claim 2, characterized in that, The method further includes: Based on the rules violated by the target code, generate a rule violation description document and output the rule violation description document.

5. The method according to claim 1, characterized in that, The architecture drift detection of the target code based on the architecture baseline model and the dependency graph, and the resulting detection results, include: Based on the dependency graph, strongly connected components in the target code are determined. If the strongly connected components include at least two nodes, a detection result indicating that the target code violates the circular dependency rule is generated. The correspondence between the source layer and the dependency layer in the target code is determined based on the dependency graph. If the correspondence violates the layering constraint rules in the architecture baseline model, a detection result indicating that the target code violates the layering rules is generated. Extract itemsets from the target code. If the extracted itemsets satisfy the antecedent of the association rule in the architecture baseline model but do not satisfy the consequent of the association rule in the architecture baseline model, then generate a detection result indicating that the target code violates the association rule.

6. The method according to claim 5, characterized in that, If the extracted itemset satisfies the condition that the antecedent is true and the consequent is false in the association rule of the architecture baseline model, then a detection result indicating that the target code violates the association rule is generated, including: If the extracted itemset satisfies the condition that the antecedent is true and the consequent is false in the association rule in the baseline model of the architecture, then the severity of the association rule violation is marked according to the confidence level and / or historical repair records corresponding to the violated association rule, and a detection result indicating that the target code violates the association rule is generated.

7. The method according to claim 5, characterized in that, The method further includes: Based on the coupling degree between the detection results and the target code, a health score is output; Review suggestions are generated based on the relationship between the health score and the score threshold.

8. The method according to claim 1, characterized in that, The dependency graph of the target code submitted to the version control system includes: A first transaction object set is generated based on the target code, wherein the first transaction object set includes a first transaction object used to structurally describe the single code commit information corresponding to the target code; Construct a dependency graph of the target code based on the first set of transaction objects.

9. The method according to claim 1, characterized in that, The baseline architecture model is constructed in the following manner: Historical commit code information within a first time period is extracted from the version control system, and a second transaction object set is generated based on the information corresponding to each commit in the historical commit code information. The second transaction object set includes a second transaction object used to structurally describe the single code commit information corresponding to the historical commit code information. Generate an itemset set based on the second set of transaction objects; Association rules are generated based on the itemset set, and the architecture baseline model is generated based on the association rules and the architecture constraints corresponding to the version control system.

10. The method according to claim 9, characterized in that, The step of generating association rules based on the itemset set and generating the architecture baseline model based on the association rules and the architecture constraints corresponding to the version control system includes: Frequent itemsets with support greater than a first threshold are mined from the set of itemsets, and the items included in the frequent itemsets are split to obtain multiple candidate rules, wherein the support is used to characterize the probability of an itemset being submitted within the first time period. The confidence and lift of each candidate rule are calculated based on the support of the frequent itemsets, and the candidate rules with confidence greater than the second threshold and lift greater than the third threshold are determined as the association rules. The architecture baseline model is generated based on the association rules and the architecture constraints corresponding to the version control system.

11. A code architecture drift repair system, comprising: The code analysis layer is used to construct a dependency graph of the target code submitted to the version control system, wherein the dependency graph is used to indicate the dependency relationships between files in the target code; The detection layer is used to perform architecture drift detection on the target code based on the architecture baseline model and the dependency graph, and obtain the detection result. The architecture baseline model is obtained by training based on the historical commit code in the version control system. The repair layer is used to repair the target code when the detection result indicates that the target code violates at least one of the association rule, the hierarchical rule, and the circular dependency rule, to obtain the repaired code, and to generate the architecture document of the repaired code.

12. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus communicate with each other through the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the method as described in any one of claims 1-10.

13. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-10.

14. A computer program product comprising computer instructions that instruct a computing device to perform an operation corresponding to the method described in any one of claims 1-10.

Images