Intelligent detection method and system for technical debt of legacy system code

Abstract

This invention discloses an intelligent detection method and system for legacy system code technical debt, belonging to the field of software engineering technology. The method includes: a multi-dimensional code knowledge graph construction step, a dynamic construction step of a structural debt pattern library, a topological constraint relaxation subgraph isomorphic matching step, a business impact score jointly driven by graph centrality and version history step, and a multi-objective priority ranking and refactoring strategy closed-loop recommendation step. This invention achieves deep modeling of code structure relationships by constructing a code knowledge graph, achieves systematic detection of architecture-level anti-patterns through subgraph isomorphic matching, achieves quantitative priority ranking of technical debt through business impact scoring, and achieves continuous adaptive optimization of detection accuracy through closed-loop feedback.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, and in particular relates to an intelligent detection method and system for legacy system code technical debt based on code knowledge graph construction and structural debt pattern matching. Background Technology

[0002] As large enterprise software systems undergo iterative evolution through multiple generations of development teams over a decade or more, a significant amount of technical debt inevitably accumulates in their codebases. This technical debt encompasses various types, including duplicate code blocks, excessively long functions, circular dependencies, obsolete interfaces, and inconsistent naming conventions. The root cause lies in the fact that development teams at each stage, under pressure to deliver projects, chose implementation strategies that were feasible in the short term but detrimental in the long run. The continuous accumulation of technical debt leads to a year-on-year decrease in the speed of new feature development and a year-on-year increase in maintenance costs, severely restricting the sustainable evolution capability of legacy systems. Therefore, accurately detecting and quantifying the technical debt in legacy systems has become a critical problem that urgently needs to be addressed in the field of software engineering.

[0003] In existing technologies, traditional static code analysis tools typically scan the codebase file by file using predefined, fixed rule sets, outputting tens of thousands of alerts. However, these alerts contain a large number of low-priority coding style issues, mixed in with architectural-level technical debt that truly impacts system maintainability and structural stability. This leaves development teams overwhelmed by the sheer volume of alerts, ultimately leading them to ignore all alerts and causing the technical debt to worsen. Furthermore, fixed rules can only perform local checks at the single-file or single-module level, failing to identify cross-module architectural-level debt. For example, implicitly distributed monolithic structures where core business logic is scattered across dozens of services—such systemic problems are beyond the detection range of traditional tools. While recent research has applied graph neural networks to anti-pattern detection in microservice architectures, these methods primarily focus on service call relationship graphs between microservices, lacking the ability to model multi-dimensional relationships at the code entity level within legacy monolithic systems. Moreover, they fail to correlate detection results with code modification history and defect records to quantify business impact.

[0004] In existing research on technical debt identification, patent application CN115329071A discloses a method and apparatus for identifying technical debt based on software development issues. The core idea of ​​this method is to obtain a set of development issues from a development issue tracking system, and then use an LSTM-based deep learning model to classify the text of these development issues to determine whether each issue involves technical debt. While this approach introduces deep learning to improve the accuracy of text classification, it has the following shortcomings: First, this method relies on text data from the development issue tracking system as input, essentially performing a classification task of natural language text. It cannot directly analyze the structural features of the code and the dependencies between modules, thus failing to detect architectural-level structural technical debt. Second, this method only outputs a binary classification result indicating whether each development issue involves technical debt, lacking the ability to quantitatively assess the severity of technical debt and the scope of its business impact. Development teams cannot use this information to determine the priority of debt management. Third, the LSTM model used in this method takes sequential text as input and cannot capture the complex graph structure relationships between code entities. It is completely powerless against architectural-level anti-patterns that require topological analysis to detect, such as God-like patterns, circular dependencies, and shotgun-like modifications.

[0005] In summary, existing technologies for technical debt detection suffer from three main shortcomings: First, detection methods are limited to text analysis or fixed-rule scanning, lacking the ability to deeply model code structural relationships and represent code entities and their multidimensional relationships as a unified, computable structure. Second, there is a lack of an architecture-level anti-pattern matching mechanism based on graph structures; existing tools can only detect code smells at the single-file level and cannot systematically discover cross-module structural technical debt. Third, there is a lack of a quantitative ranking mechanism that correlates detection results with business impact; existing methods output alert lists that lack priority distinctions and cannot effectively guide development teams to formulate optimal strategies for technical debt governance under limited resources. Therefore, there is an urgent need for a technical debt detection method that can perform deep modeling at the code structure level and intelligently rank based on business impact. This would help development teams accurately identify and prioritize the structural technical debt that has the greatest impact on system architecture health under limited time and human resources, fundamentally reversing the continuous deterioration of technical debt. Summary of the Invention

[0006] To address the limitations of existing technologies in legacy system code technical debt detection, including limitations in detection methods, lack of architectural-level anti-patterns, and lack of business impact ranking, this invention provides an intelligent method and system for detecting legacy system code technical debt. The core idea of ​​this invention is to transform the structural information of the legacy system codebase into a code knowledge graph. Within the graph, architectural-level anti-pattern instances are searched through subgraph isomorphic matching. Combined with graph centrality metrics and version control history information, a comprehensive business impact score for each technical debt instance is calculated. Finally, a priority-ranked list of technical debts and recommended refactoring strategies are output. The above steps form a two-way closed-loop collaborative architecture of forward data-driven and backward feedback adjustment, achieving a technical effect where detection accuracy continuously and adaptively improves with usage.

[0007] This invention discloses an intelligent method for detecting legacy system code debt, which includes the following steps:

[0008] Step S1, Multi-dimensional Construction of Code Knowledge Graph: Perform deep static analysis on the legacy codebase, extract classes, functions, interfaces and modules as graph nodes, extract call relationships, inheritance relationships, dependency relationships and data flow relationships as directed edges, and calculate the code line count, cyclomatic complexity, modification frequency and defect association count attributes for each node to construct the code knowledge graph.

[0009] Step S2, Dynamic Construction of the Structured Debt Pattern Library: Based on software engineering anti-pattern research, define pattern templates for various architecture-level anti-patterns. Each pattern template is formally expressed in the form of subgraph topology and node attribute constraints. The matching weight coefficients of each pattern template are dynamically adjusted according to the historical matching confirmation results fed back in step S5.

[0010] Step S3, Topological Constraint Relaxation Subgraph Isomorphic Matching Step: Using the subgraph topology of each pattern template in Step S2 as the query graph, perform constrained relaxation subgraph isomorphic matching in the code knowledge graph constructed in Step S1, output all matched technical debt instances and their matching degree scores, and adaptively adjust the constraint relaxation threshold according to the matching confirmation rate fed back in Step S5.

[0011] Step S4, Graph Centrality and Version History Jointly Drive Business Impact Score: Calculate the betweenness centrality and PageRank values ​​of the nodes involved in each technical debt instance output in Step S3 as structural impact indicators. Extract the modification frequency and defect association number from the version control history as active risk indicators. Weight and fuse the structural impact indicators and the active risk indicators to calculate the comprehensive business impact score.

[0012] Step S5, Multi-objective Priority Ranking and Restructuring Strategy Closed-Loop Recommendation Step: Based on the comprehensive business impact score output in Step S4, prioritize all technical debt instances, generate recommended restructuring strategies and estimated restructuring workload for each technical debt instance, and statistically analyze the historical matching confirmation results and matching confirmation rates of each anti-pattern based on the feedback from developers on the handling of technical debt instances. The historical matching confirmation results are sent back to Step S2 to dynamically adjust the matching weight coefficients of each pattern template, and the matching confirmation rates are sent back to Step S3 to adaptively adjust the constraint relaxation threshold.

[0013] Based on the same inventive concept, this invention also provides an intelligent detection system for legacy system code technical debt, including a code knowledge graph construction module, a structural debt pattern library construction module, a subgraph isomorphic matching module, a business impact scoring module, and a multi-objective priority ranking and refactoring strategy closed-loop recommendation module. The code knowledge graph construction module performs deep static analysis and constructs the code knowledge graph; the structural debt pattern library construction module maintains an architecture-level anti-pattern template set; the subgraph isomorphic matching module searches for matching instances in the graph; the business impact scoring module calculates a comprehensive score; and the multi-objective priority ranking and refactoring strategy closed-loop recommendation module ranks and generates refactoring strategies. Each module performs the corresponding steps in the above methods.

[0014] The beneficial effects of this invention are as follows: It achieves deep modeling of the structural relationships of legacy system code by constructing a code knowledge graph, unifying the call relationships, inheritance relationships, dependency relationships, and data flow relationships between classes, functions, interfaces, and modules into a computable directed attribute graph structure; it achieves systematic detection of architecture-level anti-patterns through a subgraph isomorphism-based pattern matching mechanism, capable of identifying structural technical debts that traditional tools cannot detect, such as "god classes," circular dependencies, shotgun-style modifications, and feature jealousy; it achieves quantitative priority ranking of technical debt through a business impact score jointly driven by graph centrality and version history, enabling development teams to eliminate the debts with the greatest impact on system health with minimal investment; and it achieves continuous adaptive optimization of pattern library weights and matching thresholds through a closed-loop feedback mechanism, continuously improving detection accuracy over time. Compared with CN115329071A, this invention analyzes from the perspective of code structure rather than text content, resulting in a fundamental difference in technical approach and significant performance improvements. Attached Figure Description

[0015] Figure 1 This is a flowchart of the legacy system code technology debt intelligent detection method provided in the embodiments of the present invention.

[0016] Figure 2 This is an architecture diagram of the legacy system code technology debt intelligent detection system provided in the embodiments of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are only used to illustrate the technical solution of the present invention and are not intended to limit the present invention.

[0018] This embodiment provides a method for intelligent detection of legacy system code technical debt, such as Figure 1 As shown, the method comprises five core steps, from S1 to S5, forming a deeply coupled closed-loop collaborative architecture. Specifically, the output of the previous step directly serves as the key input for the next step, while the result of step S5 inversely influences the pattern library weights in step S2 and the matching threshold parameters in step S3, thereby achieving dynamic adaptive optimization across the entire link. Each step is described in detail below.

[0019] Step S1: Multi-dimensional construction of the code knowledge graph. The core objective of this step is to transform the structural information of the legacy system codebase into a computable and queryable knowledge graph representation, providing a unified data foundation for subsequent structural debt pattern matching. In one embodiment of the present invention, the code knowledge graph is defined as a directed attribute graph. ,in Represents a set of nodes. Represents the set of directed edges. Represents the set of node attributes.

[0020] In the first stage of graph construction, abstract syntax tree (AST) parsing is performed on all source code files in the legacy codebase. Preferably, this invention employs a unified multi-language AST parsing framework, supporting mainstream programming languages ​​such as Java, C++, Python, and C#. The parsing process transforms the source code into an AST representation, extracting four types of graph nodes: class nodes represent class definitions in object-oriented programming, function nodes represent independent functions or member methods of classes, interface nodes represent interface definitions or abstract classes, and module nodes represent package or namespace-level organizational units. In one embodiment of this invention, for a typical enterprise-level legacy system containing approximately 5000 source code files, the total number of nodes that can be extracted after parsing is typically... to Between one.

[0021] In the second stage of graph construction, the relationships between nodes are extracted as directed edges. This invention defines four types of directed edges: call relationship edges, representing a function node calling another function node, extracted from the abstract syntax tree using function call graph analysis techniques, with the edge pointing from the caller to the callee; inheritance relationship edges, representing a class node inheriting from another class node or implementing a certain interface node, extracted through inheritance and implementation clauses in class declarations, with the edge pointing from the subclass to the parent class or interface; dependency relationship edges, representing a module node depending on another module node, extracted through import declaration resolution and symbolic reference analysis, with the edge pointing from the dependent to the dependent; and data flow relationship edges, representing data flowing from one function node to another, extracted using chain analysis techniques based on data definitions, with the edge pointing along the direction of data transmission. In one embodiment of this invention, for a typical medium-sized legacy system, the total number of extracted directed edges is typically... to Between the edges, the call relationship edge accounts for about 60%, the dependency relationship edge accounts for about 25%, the inheritance relationship edge accounts for about 10%, and the data flow relationship edge accounts for about 5%.

[0022] In the third stage of graph construction, four attribute values ​​are calculated for each node. The attribute is the number of lines of code. Through statistical nodes This retrieves the number of valid lines of code in the corresponding source code file or code segment, excluding blank lines and comment lines. Cyclomatic complexity attribute. Through statistical nodes The value is obtained by adding 1 to the number of conditional branches in the corresponding function body. The calculation formula is as follows:

[0023] ,

[0024] in: For nodes Cyclic complexity, dimensionless; This function controls the number of edges in the flow graph, in units of edges; This function controls the number of nodes in the flow graph, in units of nodes; This function controls the number of connected components in the flow graph; for a single function, it is typically set to 1. Cyclomatic complexity usually ranges from 1 to 100. This indicates low complexity. Indicates medium complexity. Cyclic complexity indicates high complexity. The technical basis for choosing cyclomatic complexity as a node attribute in this invention is that cyclomatic complexity can quantify the complexity of the code logic path and has a significant negative correlation with the testability and maintainability of the code.

[0025] Modify frequency attribute By analyzing the nodes from the commit logs of the version control system In the most recently set time window The number of times modifications have been submitted within a given timeframe. Preferably, a time window is used. The time window is set to 180 days, which means it tracks the modification frequency over the past six months. This time window is chosen because a window that is too short may miss infrequent but important modification patterns, while a window that is too long may introduce historical noise that is no longer active. The typical range for modification frequency is 0 to 200 times. Typically identified as frequently modified nodes. Defect association frequency attribute. Through statistical nodes The number of defect work orders associated in the defect tracking system typically ranges from 0 to 50. This invention incorporates modification frequency and defect association counts as node attributes into a knowledge graph, achieving integrated modeling of code structure information and development history information. This allows subsequent debt detection to simultaneously consider structural features and historical risk characteristics.

[0026] Furthermore, this invention adds an edge type label and a weight attribute to each directed edge. The edge type label is used to distinguish four relationship types, and the weight attribute is calculated based on the interaction strength between the two nodes connected by the edge. Preferably, the weight of the relationship edge is called. Equals the number of calls, and the weight of the inheritance edge. The weight of the dependency edge is fixed at 1.0. Equal to the number of statements importing this module, and the weight of the data flow relation edges. This is equal to the number of variables transmitted in the data. Through the above three-stage construction process, this invention transforms the legacy system codebase into a structured code knowledge graph, which fully encodes the multidimensional relationships between code entities and the multidimensional attribute information of each entity. It should be particularly noted that the code knowledge graph constructed in step S1 provides a unified data foundation for subsequent steps S2 to S5. Step S2 defines pattern templates on this graph, step S3 performs matching searches in this graph, and step S4 calculates the centrality metric using the graph's topological structure. The steps achieve tight data coupling by sharing the same graph data structure. This multi-step collaborative mechanism based on a unified graph is the core architectural innovation that distinguishes this invention from existing technologies.

[0027] Step S2: Dynamic Construction of the Structured Debt Pattern Library. The core objective of this step is to construct a formalized structured technical debt pattern library, transforming architecture-level anti-patterns verified in software engineering research into subgraph templates that can be matched and searched in code knowledge graphs. In one embodiment of the present invention, the pattern library defines 12 architecture-level anti-patterns, of which four core anti-patterns are described in detail below.

[0028] The formal definition of the God class pattern is a class node Star-shaped subgraph template as the core The topology constraints of this template require core nodes... out of degree Exceeding the first out-degree threshold And in degree Exceeding the first in-degree threshold Node attribute constraints Exceeding the second threshold and Exceeding the cyclomatic complexity threshold Preferably, Set to 15. Set to 20, Set to 1000 rows. Set to 50. The above threshold is selected based on Martin Fowler's classic study on code smells and empirical analysis results from large-scale open-source projects in recent years. The settings referenced statistical analysis of over 500 open-source Java projects, which showed that the median number of lines of code for the God class was approximately between 850 and 1200 lines.

[0029] The formal definition of a circular dependency pattern is a subgraph template containing directed loops. The topological constraints of this template require that there be sub-module nodes in the subgraph. After passing through several intermediate module nodes, it finally returns to... A directed path, and the length of the loop. Not exceeding the set upper limit Preferably, Setting it to 8 means only detecting circular dependencies with a length of no more than 8 modules. The technical basis for this is that very long circular dependencies are usually indirect and weakly coupled relationships, and their actual impact on system maintainability is significantly lower than that of short circular dependencies. This invention uses an improved version of the Tarjan strongly connected component algorithm for detecting circular dependencies, with a time complexity of O(log n). ,in This represents the number of nodes in the graph. The number of directed edges is such that all strongly connected components can be identified in linear time.

[0030] The formal definition of the shotgun-style modification pattern is a scatter subgraph template triggered by a set of changes. The topology constraint of this template requires that the number of distributed modules associated with a single requirement change exceeds a third threshold. Furthermore, there are no direct dependencies between these modules. Preferably, A setting of 5 indicates that a single change requires modifying more than 5 independent modules simultaneously, which is considered a shotgun-style modification. Identifying this pattern requires combining commit records from the version control history, mapping the files involved in a single commit to module nodes in the code knowledge graph, and counting the number of different modules involved.

[0031] The formal definition of the jealousy pattern is a function node Cross-class call subgraph template as the core The topological constraints of this template require function nodes... Number of edges called on outer class methods Number of edges that call methods of this class The ratio exceeds the fourth threshold Preferably, The threshold is set to 3.0, meaning that a function is considered to be jealous when the number of calls to an outer class exceeds three times the number of calls to its own class. This threshold was selected based on the metric-based detection strategy proposed by Lanza and Marinascu in their classic work, *Object-Oriented Metrics in Practice*.

[0032] In one embodiment of the present invention, in addition to the four core anti-patterns mentioned above, the pattern library also includes the following eight anti-patterns: data class pattern (i.e., a class that only contains getter and setter methods), rejection of inheritance pattern (i.e., a subclass that extensively overrides parent class methods but does not actually use the inherited functionality), man-in-the-middle pattern (i.e., most methods of a certain class are only forwarded to another class), parallel inheritance pattern (i.e., classes in two inheritance hierarchies always appear and are modified in pairs), over-coupling pattern (i.e., the density of dependency edges between modules exceeds a threshold), knowledge silo pattern (i.e., a module is modified by only a single developer, leading to the risk of knowledge concentration), interface bloat pattern (i.e., the number of methods defined in the interface is too large), and dead code accumulation pattern (i.e., the cumulative proportion of functions and classes that have not been called for a long time exceeds a threshold).

[0033] The key innovation of this step lies in the matching weight coefficients of each pattern template. It is dynamically adjustable. In one embodiment of the present invention, when the historical matching confirmation result fed back in step S5 indicates that the confirmation rate of a certain anti-pattern is high, the corresponding matching weight coefficient will be adjusted according to the set increment value. The false alarm rate of a certain anti-pattern will be increased; conversely, when the false alarm rate of a certain anti-pattern is high, the corresponding matching weight coefficient will be decreased according to the set value. To reduce. Preferably, Set to 0.05, Set to 0.03, weighting coefficient The effective range is constrained to be between 0.1 and 2.0, with an initial default value of 1.0. This dynamic weight adjustment mechanism enables the pattern library to continuously optimize the detection sensitivity of each anti-pattern based on actual usage feedback, thereby achieving adaptive improvement in detection accuracy.

[0034] Step S3: Topological constraint relaxation subgraph isomorphic matching step. The core objective of this step is to search the code knowledge graph constructed in step S1 for instances that match the structure of each anti-pattern subgraph template defined in step S2. Since the technical debt in real-world legacy systems often does not strictly conform to the idealized anti-pattern definition, this invention innovatively introduces a constraint relaxation mechanism to improve the recall rate of pattern matching.

[0035] In one embodiment of the present invention, subgraph isomorphic matching is implemented based on the VF3 algorithm framework. The VF3 algorithm is an improved version of the classic VF2 algorithm, and its core idea is to find subgraphs that are topologically isomorphic to the query graph in the target graph through state-space search. The present invention introduces a constraint relaxation factor based on the VF3 algorithm. This factor adaptively scales the attribute thresholds of each node in the pattern template. Specifically, for a given node attribute threshold defined in the pattern template... The effective threshold used in actual matching Calculate as follows:

[0036] ,

[0037] in: The effective threshold used in actual matching, whose units and dimensions are the same as the original threshold. Maintain consistency; The threshold value for the original attribute defined in the pattern template; The constraint relaxation factor is dimensionless, with an initial value of 1.0 and an effective range of [missing value]. .when When indicates tightening constraints to improve matching accuracy, The time interval indicates that the constraints are relaxed to improve the match recall rate. (Constraint relaxation factor) Based on the matching confirmation rate reported in step S5 The adaptive adjustment is performed, and its update formula is:

[0038] ,

[0039] in: The updated constraint relaxation factor is dimensionless. Let be the current constraint relaxation factor, which is dimensionless; The learning rate is dimensionless and preferably set to 0.1. This value is chosen because an excessively large learning rate will cause the constraint relaxation factor to oscillate violently, while an excessively small value will result in slow convergence. 0.1 strikes a good balance between the two. The target confirmation rate is dimensionless and preferably set to 0.75, meaning that at least 75% of the matching results are expected to be confirmed by the developers as genuine technical debt. The actual matching confirmation rate for the current period is dimensionless and is calculated in step S5 based on the developers' handling feedback. When the actual confirmation rate is lower than the target confirmation rate, the constraint slack factor will decrease to tighten constraints and reduce false alarms; when the actual confirmation rate is higher than the target confirmation rate, the constraint slack factor will increase to relax constraints and discover more potential debts.

[0040] During the matching process, for each successfully matched instance of technical debt, this invention calculates its matching score. The score considers both topological matching and attribute matching, and its calculation formula is as follows:

[0041] ,

[0042] in: The overall matching score for this technical debt instance is given, with a value range of [value missing]. Dimensionless; The topology matching weight coefficient is dimensionless and preferably set to 0.6. The basis for its selection is that topological features have a higher weight in the determination of architecture-level anti-patterns. The topology matching score is given, and the value range is: It is obtained by normalizing the graph edit distance between the query graph and the matching subgraph; The attribute matching score is given, and the value range is: This is obtained by normalizing the deviation between the attribute values ​​of the matching node and the template threshold. In one embodiment of the present invention, only... The matching results are used as valid technical debt instances, and this threshold can be adjusted between 0.3 and 0.8 as needed.

[0043] In one embodiment of the present invention, for including Each node and For a typical legacy system code knowledge graph with edges, the matching process in step S3 takes approximately 45 to 120 seconds, depending on the number of anti-patterns in the pattern library and the complexity of each anti-pattern subgraph template. To improve matching efficiency, this invention also employs a pre-filtering strategy based on node degree. That is, before performing isomorphic matching of the complete subgraph, the search space is pruned based on the degree of candidate nodes, thereby reducing the number of candidate subgraphs that actually need to be tested for isomorphism by approximately 70% to 85%.

[0044] Step S4: The business impact scoring step is jointly driven by graph centrality and version history. The core objective of this step is to calculate a comprehensive business impact score for all technical debt instances output in Step S3, in order to quantify the degree of impact of each technical debt instance on the overall health of the system. This invention innovatively integrates the centrality measure in graph theory with the activity and risk indicators in the software version control history to form a multi-dimensional business impact evaluation system.

[0045] First, a structural influence index is calculated for the set of nodes involved in each technical debt instance. In one embodiment of the present invention, the structural influence index includes two sub-indicators: betweenness centrality. and PageRank value .

[0046] Betweenness centrality Quantization Node The pivotal position in all shortest paths of the code knowledge graph is calculated using the following formula:

[0047] ,

[0048] in: For nodes The betweenness centrality value of is dimensionless and takes values ​​in the range of . ,in This represents the total number of nodes in the graph; For nodes To the node The total number of shortest paths, expressed in terms of paths. and Traversing the graph except for nodes All node pairs except those mentioned above; For nodes To the node The shortest path passes through the nodes The betweenness centrality value indicates the number of paths a node can take, expressed in terms of paths. A higher betweenness centrality value indicates that the node is on more critical paths between code modules, meaning that if the technical debt associated with the node leads to modifications or refactoring, its impact will propagate along these paths to more modules. Preferably, the betweenness centrality value is normalized before use, i.e., divided by the theoretical maximum value. Normalize its value range to Interval.

[0049] PageRank value Quantization Node The importance ranking in the code knowledge graph dependency network is calculated using the classic PageRank iterative algorithm, with the following iterative formula:

[0050] ,

[0051] in: For nodes In the The PageRank value at the next iteration is dimensionless. The damping coefficient is dimensionless and set to 0.85. This value is the classic recommendation value of the PageRank algorithm, which means that there is an 85% probability of jumping along the link and a 15% probability of randomly jumping to any node. This represents the total number of nodes in the graph; For all nodes that exist, point to them. The set of source nodes of directed edges; For nodes The out-degree is expressed in lines. The iterative process reaches a convergence threshold when the maximum difference between two consecutive iterations is less than the maximum convergence threshold. The process terminates after 20 to 50 iterations in practice. A higher PageRank value indicates that the node is depended on by more other nodes, and it can be regarded as a core node in the code knowledge graph.

[0052] Structural influence Obtained through a weighted fusion calculation of betweenness centrality and PageRank value:

[0053] ,

[0054] in: For nodes The structural influence score is dimensionless and its value range is [value range missing]. ; The normalized betweenness centrality value is dimensionless and takes values ​​in the range of 1 / 2. ; The normalized PageRank value is dimensionless and its range is [value missing]. ; and The weighting coefficients are dimensionless and satisfy the following conditions: Preferably , In other words, betweenness centrality and PageRank each account for half of the weight. The basis for this equal weighting is that betweenness centrality reflects the bridging role of a node, while PageRank reflects the degree to which a node is depended upon. The two characterize the structural importance of a node from different dimensions, and neither dimension should be given too much weight.

[0055] Next, the activity risk index of the nodes involved in each technical debt instance is calculated. In one embodiment of the present invention, for a technical debt instance... The set of nodes involved Activity risk level The calculation formula is:

[0056] ,

[0057] in: Examples of technical debt Activity risk score, dimensionless, with a value range of [value missing]. ; This is the normalized value of the average modification frequency of the nodes involved in this instance. It is dimensionless and calculated by first taking... Modification frequency of each node The average value is then normalized by dividing by the global maximum modification frequency; This is a normalized value for the average number of defect associations of the nodes involved in this instance. It is dimensionless and calculated in a similar way. and The weighting coefficients are dimensionless and satisfy the following conditions: Preferably , The reason why the modification frequency weight is slightly higher than the defect association frequency weight is that code areas with high modification frequency are the areas that the development team is currently actively focusing on, and their technical debt has a more direct and urgent impact on daily development efficiency.

[0058] Finally, the structural impact index and the active risk index are weighted and fused together to calculate the comprehensive business impact score. :

[0059] ,

[0060] in: Examples of technical debt The overall business impact score is dimensionless and ranges from [value range missing]. ; The structural impact score of the nodes involved in this instance is calculated by taking... Each node The maximum value, that is, the structural influence of the instance represented by the node with the greatest influence; Assign an activity risk score to this instance; and The first and second weight values ​​are dimensionless and satisfy the following conditions: , The value range is from 0.4 to 0.7. Preferably, , In other words, the weight of structural impact is slightly higher than that of active risk. This weighting is based on the fact that structural impact reflects the long-term impact of technical debt on the health of the system architecture, while active risk reflects the impact on short-term development efficiency. Long-term impact should be given priority in the strategic planning of technical debt governance.

[0061] Through the above calculation process, step S4 calculates a comprehensive business impact score between 0 and 1 for each technical debt instance output in step S3. The larger the value, the greater the impact of the technical debt on the system and the higher the priority of governance.

[0062] Step S5: Multi-objective Prioritization and Restructuring Strategy Closed-Loop Recommendation Step. The core objective of this step is to finally rank all technical debt instances based on the comprehensive business impact score output from Step S4, and generate actionable restructuring strategy recommendations for each technical debt instance. More importantly, this step achieves closed-loop linkage with Steps S2 and S3 by introducing a developer feedback mechanism.

[0063] During the prioritization phase, this invention scores all instances of technical debt according to their overall business impact. Sort from largest to smallest. In one embodiment of the invention, the sorted list of technical debts is arranged according to... The values ​​are divided into four priority levels: the emergency level corresponds to... The example indicates that the debt severely impacts the core system architecture and is located in a frequently modified area, suggesting immediate refactoring; high priority level corresponds to For instances of this type, it is recommended to schedule a refactoring in the most recent iteration cycle; medium priority level corresponds to... Examples of these should be included in the technology debt repayment plan; lower priority levels correspond to... For such cases, it is recommended to continue monitoring but not to rush into action.

[0064] During the refactoring strategy recommendation phase, this invention automatically generates corresponding refactoring strategies based on the anti-pattern types matched for each technical debt instance. Preferably, for technical debt instances with the "God-class" pattern, a class splitting strategy is recommended, whereby the "God-class" is split into multiple single-responsibility classes according to their responsibility boundaries. The splitting suggestions are automatically generated based on the community detection results of the method call subgraph of the class in the knowledge graph, maximizing the cohesion within each subclass and minimizing the coupling between subclasses after splitting. For technical debt instances with the circular dependency pattern, a strategy of reversing the dependency direction or extracting abstract interfaces is recommended, that is, breaking the key links in the circular dependency by introducing an interface layer. For technical debt instances with the "shotgun modification" pattern, an inline movement or extraction of common services strategy is recommended, that is, concentrating related logic scattered across multiple modules into a common service module. For technical debt instances with the "feature jealousy" pattern, a method relocation strategy is recommended, that is, moving the jealousy method to the target class that it calls most frequently.

[0065] Estimated Restructuring Workload Based on the number of nodes involved in this technical debt instance Number of edges The quantitative calculation is performed using the following formula:

[0066] ,

[0067] in: To estimate the workload of the refactoring, the unit is person-hour. This represents the number of nodes involved in this instance of technical debt, expressed in units. This represents the average number of lines of code for the nodes involved in this instance, in lines. This represents the number of edges involved in this instance, in units of edges; The average refactoring time coefficient per line of code is expressed in person-hours per line. It is preferably set to 0.02, which means that on average, every 50 lines of code requires about 1 hour of refactoring work. This value is based on publicly available industry benchmark data for code refactoring efficiency. The average reconstruction time coefficient for each relation edge is expressed in person-hours per edge, and is preferably set to 0.5, meaning that each dependency that needs to be adjusted requires an average of about 0.5 hours of reconstruction work.

[0068] In the closed-loop feedback phase, this step collects feedback from developers regarding the handling of each technical debt instance in the ranking results. Feedback types include confirmed handling and false alarm marking. When a developer performs a confirmed handling operation on a technical debt instance, the system sends back the anti-pattern type and matching parameters matched for that instance to step S2. Step S2 then assigns the matching weight coefficient of the corresponding pattern template. Increase This gives the pattern a higher weight in subsequent detection. After the developer performs a false positive marking operation on a technical debt instance, the system returns the instance's detailed information to steps S2 and S3: Step S2 assigns the matching weight coefficient of the corresponding pattern template. Decrease Step S3: Recalculate the target confirmation rate based on the current cumulative false alarm rate. And adjust the constraint relaxation factor accordingly. The value of .

[0069] Furthermore, this step generates a partial knowledge graph visualization for each technical debt instance. Preferably, the visualization centers on the core node involved in the technical debt instance, extending outwards to related nodes and edges within a two-hop range, forming a local subgraph. Different colors are used to identify different types of nodes in the subgraph, different line types are used to identify different types of edges, and node size encodes the structural influence score of the node. Through this visualization, the development team can intuitively understand the specific scope and relationships involved in each technical debt instance.

[0070] In one embodiment of the present invention, for a comprising approximately Each node and The test was conducted on an enterprise-level legacy Java system codebase. The total execution time for steps S1 to S5 was approximately 180 to 300 seconds. In this test system, step S3 detected 127 instances of technical debt, including 23 instances of the "God-like" pattern, 31 instances of the circular dependency pattern, 18 instances of the shotgun-like modification pattern, 22 instances of the "feature jealousy" pattern, and 33 other types of instances. After sorting by steps S4 and S5, there were 12 urgent instances, 28 high-priority instances, 45 medium-priority instances, and 42 low-priority instances. The development team verified that the actual structural technical debt accounted for approximately 87% of the urgent and high-priority instances, while traditional static analysis tools generated a significantly lower total number of alerts on the same codebase. Of the alerts, only 3.2% were related to architectural-level technical debt. This comparative result shows that the method of the present invention has a significant improvement in accuracy and operability compared with the prior art in terms of structural technical debt detection.

[0071] Compared to the technical solution of CN115329071A, the core difference of the method in this invention lies in the following: CN115329071A uses natural language text from a development issue tracking system as input and performs text binary classification using an LSTM model; while this invention uses the legacy system codebase itself as input and performs structural technical debt detection through code knowledge graph construction and subgraph isomorphic matching. This invention can detect architectural anti-patterns such as God-like behavior, circular dependencies, shotgun-like modifications, and feature jealousy, which are unrecognizable by the text classification method of CN115329071A. Furthermore, this invention achieves quantitative priority ranking of technical debt through a business impact score jointly driven by graph centrality and version history, while CN115329071A only outputs binary classification results and lacks priority ranking capabilities. Further, this invention achieves continuous adaptive optimization of pattern library weights and matching thresholds through the closed-loop feedback mechanism in step S5, while the LSTM model of CN115329071A remains fixed after training and lacks adaptive update capabilities.

[0072] Based on the same inventive concept, such as Figure 2 As shown, this embodiment provides an intelligent detection system for legacy system code technical debt. The system includes a code knowledge graph construction module, a structural debt pattern library construction module, a subgraph isomorphic matching module, a business impact scoring module, and a multi-objective priority ranking and reconstruction strategy closed-loop recommendation module. Each module corresponds one-to-one with steps S1 to S5 in Embodiment 1.

[0073] The code knowledge graph construction module receives source code files and version control logs from legacy codebases as input, performs deep static analysis, and outputs a code knowledge graph. Preferably, this module internally includes an abstract syntax tree (AST) parsing submodule, a relation extraction submodule, and an attribute calculation submodule. The AST parsing submodule is responsible for parsing each source code file into an AST and extracting four types of nodes from it. The relation extraction submodule is responsible for extracting four types of directed edges based on the AST and symbol reference table. The attribute calculation submodule is responsible for calculating four attribute values ​​for each node based on the source code files and version control logs. The output of this module is a complete code knowledge graph. It is stored in a graph database to support efficient graph query operations.

[0074] The Structured Debt Pattern Library Construction Module is used to maintain and manage the set of pattern templates for architectural-level anti-patterns. This module contains a pattern definition submodule and a weight dynamic adjustment submodule. The pattern definition submodule is responsible for storing and managing the subgraph topology, node attribute constraints, and initial matching weight coefficients for 12 anti-patterns. The weight dynamic adjustment submodule is responsible for receiving matching confirmation feedback from the multi-objective priority ranking and reconstruction strategy closed-loop recommendation module, and updating the matching weight coefficients of each pattern template accordingly.

[0075] The subgraph isomorphic matching module searches the code knowledge graph for technical debt instances that match various anti-pattern templates. This module contains a pre-filtering submodule, a VF3 matching submodule, and a constraint relaxation control submodule. The pre-filtering submodule prunes the search space based on node degree to improve matching efficiency. The VF3 matching submodule executes a subgraph isomorphic matching algorithm with constraint relaxation. The constraint relaxation control submodule adaptively adjusts the constraint relaxation factor based on the matching confirmation rate fed back by the multi-objective priority ranking and reconstruction strategy closed-loop recommendation module. The output of this module is a list of all matched technical debt instances and their matching scores.

[0076] The Business Impact Scoring module is used to calculate the comprehensive business impact score for each instance of technical debt. This module internally includes a structural impact calculation submodule and an activity risk calculation submodule. The structural impact calculation submodule is responsible for performing betweenness centrality calculation and PageRank iterative calculation on the code knowledge graph, while the activity risk calculation submodule is responsible for extracting modification frequency and defect association quantity from the version control history. The outputs of the two submodules are weighted and fused to obtain the comprehensive business impact score, as described in detail in step S4 of Example 1.

[0077] The multi-objective priority ranking and reconstruction strategy closed-loop recommendation module is used to perform final ranking of all technical debt instances and generate reconstruction strategy recommendations. This module includes a priority ranking submodule, a reconstruction strategy generation submodule, and a feedback collection submodule. The priority ranking submodule sorts all instances in descending order based on their comprehensive business impact score and assigns them priority levels. The reconstruction strategy generation submodule automatically generates corresponding reconstruction strategies and estimated workloads based on the anti-pattern types matched to each instance, as described in detail in step S5 of Example 1, including the strategy generation method and workload calculation formula. The feedback collection submodule is responsible for collecting confirmation and handling feedback from developers and false alarm marking feedback, and sending the feedback information back to the structural debt pattern library construction module and the subgraph isomorphic matching module, respectively, to achieve closed-loop dynamic updates of weight coefficients and constraint relaxation factors. The data flow between the above five functional modules constitutes a forward pipeline from input to output and a reverse adjustment loop from output feedback to intermediate modules. The forward pipeline ensures the systematicness and integrity of the detection process, while the reverse adjustment loop ensures the continuous adaptive optimization capability of the detection accuracy. Together, they constitute the closed-loop collaborative architecture of the system of this invention.

[0078] In terms of system deployment, in one embodiment of this invention, the code knowledge graph construction module and the subgraph isomorphic matching module are deployed on server nodes with high computing performance. The business impact scoring module can be deployed on independent computing nodes to support parallel processing. The multi-objective priority ranking and refactoring strategy closed-loop recommendation module can be deployed on an application server integrated with the development team's workflow, and asynchronous communication between modules is achieved through message queues. The entire system can be integrated with continuous integration and continuous deployment pipelines, automatically triggering incremental technical debt detection after each code commit.

[0079] Preferably, in incremental detection mode, the code knowledge graph construction module only performs incremental parsing and graph updates on the source code files involved in the current commit, without needing to re-perform a full analysis of the entire codebase. The incremental update process includes: first, obtaining the list of files modified and the difference information from the version control system; then, re-performing abstract syntax tree parsing and node attribute recalculation only on the modified files; and finally, incrementally merging the updated nodes and edges into the existing code knowledge graph. The time complexity of incremental updates is proportional to the number of modified files. For a typical scenario involving 10 to 50 files in a single commit, incremental updates take approximately 2 to 15 seconds, reducing the time compared to a full build by more than 95%, thus making real-time detection of technical debt in continuous integration pipelines a feasible solution. Preferably, incremental detection mode also supports difference analysis in cross-branch merging scenarios, i.e., performing incremental technical debt detection on the merged code knowledge graph before merging code branches, providing an automated basis for architectural quality assessment for code review.

[0080] To verify the effectiveness of the method of the present invention, a comparative experiment was conducted using three enterprise-level legacy system codebases of different sizes and languages ​​in one embodiment of the present invention. The test environment was a server equipped with an Intel Xeon Gold 6248R processor and 128GB of memory, with Ubuntu 22.04 LTS as the operating system.

[0081] The first test project is an enterprise resource planning system developed using the Java language, whose codebase contains approximately [number missing]. The source code file, and the code knowledge graph constructed in step S1, contains... Each node and There are 10 directed edges. Step S3 detected a total of 89 technical debt instances on the graph, including 18 God-like patterns, 25 circular dependency patterns, 12 shotgun-style modification patterns, 15 feature jealousy patterns, and 19 other types. After sorting in steps S4 and S5 and verification by the development team, the true debt confirmation rate for urgent and high-priority instances was 89.3%.

[0082] The second test project is a data processing platform developed using the Python language, with a codebase containing approximately... One source code file. After executing the entire process from S1 to S5, 63 instances of technical debt were detected, with an 85.7% confirmation rate for urgent and high-priority instances.

[0083] The third test item was an industrial control system developed using the C++ language, with a codebase containing approximately... One source code file. The project's code knowledge graph contains... Each node and With directed edges, step S3 detected 156 instances of technical debt, with an 87.2% confirmation rate for urgent and high-priority instances.

[0084] As a benchmark, the three test projects were analyzed using both the traditional static code analysis tools SonarQube and PMD. SonarQube produced the following results for each of the three projects. strip, Tiaohe Of the alerts, only 2.8%, 3.5%, and 2.3% were related to architecture-level structural technical debt, respectively. PMD's detection results were similar to SonarQube's, with architecture-level debt-related alerts accounting for less than 5%. This indicates that the vast majority of alerts generated by traditional tools are related to coding style issues, while truly architecture-impacting structural technical debt is buried in a sea of ​​low-value alerts.

[0085] Compared with the solution in CN115329071A, the advantages of the method in this invention are reflected in the following aspects: In terms of detection dimensions, CN115329071A can only detect self-acknowledged technical debt in the development issue text, and its detection scope is limited by whether the developers actively recorded relevant information about technical debt in the issue tracking system. In contrast, this invention directly discovers technical debt from the code structure, without relying on any manual annotation or text description. Therefore, it can discover implicit structural technical debt that exists but has never been realized or recorded by the developers. In terms of detection accuracy, the LSTM model in CN115329071A has an accuracy of 75.6% and an F1 score of 63.1% on its test set, while the method in this invention has an average confirmation rate of 87.4% for urgent and high-priority instances on three actual enterprise-level legacy systems, indicating that this invention has higher detection accuracy in practical applications. In terms of output operability, CN115329071A only outputs the probability value of whether each development problem involves technical debt, while the present invention outputs complete decision support information including priority level, recommended refactoring strategy, estimated workload and partial visualization of knowledge graph, enabling the development team to immediately formulate an executable debt management plan based on this.

[0086] Furthermore, after three rounds of iteration, the closed-loop feedback mechanism in step S5 effectively adjusted the pattern library weights in step S2 and the constraint relaxation factor in step S3. The confirmation rate of urgent and high-priority instances on the three test items increased from an average of 84.1% in the first round to an average of 91.6% in the third round, an increase of approximately 7.5 percentage points, verifying the effectiveness of the closed-loop adaptive optimization mechanism.

[0087] Regarding the computational performance of each step, the analysis is based on the first test project. Step S1, code knowledge graph construction, takes approximately 35 seconds, including approximately 20 seconds for abstract syntax tree parsing, 10 seconds for relation extraction, and 5 seconds for attribute calculation. Step S2, pattern library loading and initialization, takes less than 1 second. Step S3, subgraph isomorphic matching, takes approximately 65 seconds, including approximately 8 seconds for the pre-filtering stage, which reduces the candidate search space by approximately 78%. Step S4, business impact score calculation, takes approximately 25 seconds, including approximately 15 seconds for betweenness centrality calculation, 8 seconds for iteration calculation, and 2 seconds for weighted fusion calculation. Step S5, priority sorting and refactoring strategy generation, takes approximately 5 seconds. The total process time is approximately 131 seconds, meeting the timeliness requirements for periodic technical debt detection in enterprise-level legacy systems. Compared with traditional tools, the method of this invention has achieved a qualitative breakthrough in detecting architectural-level structural technical debt, freeing development teams from massive amounts of low-value alerts and enabling them to focus on dealing with the most critical structural issues that affect system health.

[0088] The embodiments of the present invention are not limited to the specific embodiments described above. Those skilled in the art can make various equivalent changes or substitutions based on the technical solutions of the present invention, and all such changes or substitutions should be included within the protection scope of the present invention.

Claims

1. A method for intelligent detection of legacy system code technical debt, characterized in that, Includes the following steps: Step S1, Multi-dimensional construction steps of code knowledge graph: Perform deep static analysis on legacy code library, extract classes, functions, interfaces and modules as graph nodes, extract call relationship, inheritance relationship, dependency relationship and data flow relationship as directed edges, and calculate the code line number, cyclomatic complexity, modification frequency and defect association number attributes for each node to construct code knowledge graph; Step S2, Dynamic Construction Steps of the Structured Debt Pattern Library: Based on software engineering anti-pattern research, define pattern templates for various architecture-level anti-patterns. Each pattern template is formally expressed in the form of subgraph topology and node attribute constraints. Step S3, topological constraint relaxation subgraph isomorphic matching step: using the subgraph topology of each pattern template in step S2 as the query graph, perform constraint relaxation subgraph isomorphic matching in the code knowledge graph constructed in step S1, and output all matched technical debt instances and their matching degree scores. Step S4, Graph Centrality and Version History Jointly Drive Business Impact Score: Calculate the betweenness centrality and PageRank values ​​of the nodes involved in each technical debt instance output in Step S3 as structural impact indicators. Extract the modification frequency and defect association number of the code corresponding to the nodes involved in each technical debt instance from the version control history as active risk indicators. Calculate the comprehensive business impact score by weighting and fusing the structural impact indicators and the active risk indicators. Step S5, Multi-objective Priority Ranking and Restructuring Strategy Closed-Loop Recommendation Step: Based on the comprehensive business impact score output in Step S4, prioritize all technical debt instances, generate recommended restructuring strategies and estimated restructuring workload for each technical debt instance, and statistically analyze the historical matching confirmation results and matching confirmation rates of each anti-pattern based on the developers' feedback on the handling of technical debt instances. The historical matching confirmation results are sent back to Step S2 to dynamically adjust the matching weight coefficients of each pattern template, and the matching confirmation rates are sent back to Step S3 to adaptively adjust the constraint relaxation threshold.

2. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S1, the node attributes are calculated as follows: the number of lines of code is obtained by counting the valid lines of code in the source code file corresponding to each node; the cyclomatic complexity is obtained by counting the number of conditional branches of the function corresponding to each node plus 1; the modification frequency is obtained by counting the number of times the node has been modified within the most recent set time window from the version control log; and the number of defect associations is obtained by counting the number of defect work orders associated with the node in the defect tracking system.

3. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S2, architectural anti-patterns include the following types: God-like pattern, whose topological constraint is that the out-degree and in-degree of a single class node both exceed the first threshold and the number of lines of code exceeds the second threshold; Circular dependency pattern, whose topological constraint is that there are directed loops between module nodes and the length of the loop does not exceed a set upper limit; Shotgun modification pattern, whose topological constraint is that the number of scattered modules associated with a single change exceeds the third threshold; Feature jealousy pattern, whose topological constraint is that the ratio of the number of edges calling methods of an external class to the number of edges calling methods of its own class exceeds the fourth threshold.

4. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S4, the weighted fusion method for the comprehensive business impact score is as follows: the weight coefficient of the structural impact index is the first weight value, the weight coefficient of the activity risk index is the second weight value, the sum of the first weight value and the second weight value is 1, and the value range of the first weight value is 0.4 to 0.

7.

5. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S1, constructing the code knowledge graph also includes: performing abstract syntax tree parsing on each source code file in the legacy code library to extract class nodes and function nodes; extracting dependency edges between modules through import declaration parsing and symbolic reference analysis; extracting inheritance edges through class inheritance declarations and interface implementation declarations; extracting call relationship edges through function call graph analysis; and extracting data flow relationship edges through data definition usage chain analysis.

6. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S3, the subgraph isomorphic matching with constraint relaxation includes: performing subgraph isomorphic matching based on the VF3 algorithm framework. During the matching process, a constraint relaxation factor is introduced to scale the node attribute thresholds in the pattern template. When the threshold of a certain node attribute in the pattern template is the original threshold, the original threshold multiplied by the constraint relaxation factor is used as the effective threshold during actual matching. The initial value of the constraint relaxation factor is 1.0 and is adaptively adjusted within a set range according to the matching confirmation rate fed back in step S5.

7. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S4, the betweenness centrality is calculated as follows: for each node in the code knowledge graph, the ratio of the number of paths passing through that node to the total number of shortest paths is calculated. The PageRank value is calculated as follows: using the directed edges of the code knowledge graph as the link relationship, the PageRank value of each node is calculated through iterative convergence, with the damping coefficient set to 0.85 and the iterative convergence threshold set to 0.0001.

8. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S5, the closed-loop adaptive update process includes: when a developer performs a confirmation and handling operation on a certain technical debt instance, the anti-pattern type and matching parameters matched for that instance are returned to step S2, and step S2 increases the matching weight coefficient of the corresponding pattern template by a set increment value; when a developer performs a false alarm marking operation on a certain technical debt instance, the anti-pattern type and matching parameters matched for that instance are returned to steps S2 and S3, step S2 decreases the matching weight coefficient of the corresponding pattern template by a set decrement value, and step S3 adjusts the value of the constraint relaxation factor according to the false alarm rate.

9. The intelligent detection method for legacy system code technology debt according to claim 1, characterized in that, In step S5, the recommended refactoring strategies are generated as follows: for technical debt instances of the God-like pattern, a class splitting strategy is recommended; for technical debt instances of the circular dependency pattern, a strategy of reversing the dependency direction or extracting abstract interfaces is recommended; for technical debt instances of the shotgun-style modification pattern, an inline move or extraction of common services strategy is recommended; and for technical debt instances of the feature-jealousy pattern, a relocation method strategy is recommended. The estimated refactoring workload is quantified based on the number of nodes and edges involved in the technical debt instance.

10. A legacy system code technology debt intelligent detection system, used to implement the legacy system code technology debt intelligent detection method according to any one of claims 1-9, characterized in that, include: The code knowledge graph construction module is used to perform deep static analysis on legacy code bases, extract classes, functions, interfaces and modules as graph nodes, extract call relationships, inheritance relationships, dependency relationships and data flow relationships as directed edges, and calculate the code line count, cyclomatic complexity, modification frequency and defect association count attributes for each node to construct the code knowledge graph; The structural debt pattern library construction module is used to define pattern templates for various architecture-level anti-patterns based on software engineering anti-pattern research, and dynamically adjust the matching weight coefficients of each pattern template according to the historical matching confirmation results fed back by the multi-objective priority ranking and refactoring strategy closed-loop recommendation module. The subgraph isomorphic matching module is used to perform constrained relaxation subgraph isomorphic matching in the code knowledge graph using the subgraph topology of each pattern template as the query graph. It outputs all matched technical debt instances and their matching scores, and adaptively adjusts the constraint relaxation threshold based on the matching confirmation rate fed back by the multi-objective priority sorting and reconstruction strategy closed-loop recommendation module. The Business Impact Scoring Module is used to calculate the betweenness centrality and PageRank values ​​of the nodes involved in each technical debt instance as structural impact indicators, extract the modification frequency and defect association number from the version control history as active risk indicators, and calculate the comprehensive business impact score by weighting and integrating the structural impact indicators and active risk indicators. The multi-objective priority ranking and reconstruction strategy closed-loop recommendation module is used to prioritize all technical debt instances based on the comprehensive business impact score, generate recommended reconstruction strategies and estimated reconstruction workload for each technical debt instance, and statistically analyze the historical matching confirmation results and matching confirmation rates of each anti-pattern based on the feedback from developers on the handling of technical debt instances. The historical matching confirmation results are sent back to the structural debt pattern library construction module to dynamically adjust the matching weight coefficients of each pattern template, and the matching confirmation rate is sent back to the subgraph isomorphic matching module to adaptively adjust the constraint relaxation threshold.

Images