A method and system for identifying redundant code based on a dataflow graph

Abstract

The application provides a kind of redundant code identification method and system based on data flow graph, solve the problem that prior art cannot comprehensively identify multiple types of redundant code. Through the set operation processing of interface access log, full station scanning result and code repository information, a set of abandoned interfaces is identified;Based on static analysis tool and abstract syntax tree, dynamic call detection and data flow analysis are carried out to identify a set of internal useless codes;Then, through the state check and log analysis of consumer running state, script execution record and task scheduling configuration, a set of abandoned scripts and a set of abandoned consumers are identified and merged to form a set of abandoned components;Further, a system call graph is constructed to perform reverse reachability analysis, to identify a set of cascading abandoned codes;Finally, based on the above various sets, a complete redundant code report containing statistical data, detailed list and risk assessment is generated.

Description

Technical Field

[0001] This invention relates to the field of software engineering, specifically to a method and system for identifying redundant code based on data flow graphs, and particularly to a technical solution that can identify redundant code in a software system through multi-dimensional analysis. Background Technology

[0002] During software development and maintenance, as projects expand and business processes iterate, a large amount of redundant code (dead code) inevitably accumulates in the system. This code not only increases system complexity but may also lead to potential security vulnerabilities, while increasing maintenance costs and reducing system performance.

[0003] Currently, commonly used code quality testing tools in the industry mainly rely on static analysis techniques. For example, tools like SonarQube analyze the source code structure through Abstract Syntax Trees (ASTs) to identify unreferenced variables, methods, and classes; while tools like JaCoCo detect unexecuted code paths through code coverage. These tools can, to some extent, discover redundant parts in the code.

[0004] More advanced techniques attempt to combine static analysis and symbolic execution, identifying code blocks that are unreachable from any execution path by analyzing the control and data flow of the code. This approach constructs a possible execution state space by simulating program execution, thereby determining which code will never be executed.

[0005] However, existing technologies still have significant limitations. They primarily rely on static analysis and AST structures, making them ineffective in handling dynamic invocation scenarios (such as reflection and dynamic method name invocation); furthermore, they struggle to accurately identify dead code in conditional branches (such as branches where the condition is always false) without executing the code. Furthermore, most existing methods are limited to single-dimensional analysis, lacking end-to-end tracing capabilities from the interface layer to the method layer, resulting in an inability to comprehensively identify all redundant code types in the system. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for identifying redundant code based on data flow graphs, aiming to solve the technical problem that existing technologies cannot fully identify multiple types of redundant code in a system.

[0007] To achieve the above objectives, the technical solution provided by the present invention is as follows:

[0008] A method for identifying redundant code based on data flow graphs, comprising:

[0009] Based on interface access logs, site-wide scan results, and code repository information, a set of obsolete interfaces was identified through set operations.

[0010] Based on static analysis tools and abstract syntax trees, dynamic call detection and data flow analysis are performed to identify sets of useless internal code;

[0011] Based on the consumer's running status, script execution records, and task scheduling configuration, status checks and log analysis are performed to identify the abandoned script set and the abandoned consumer set, and the abandoned consumer set and the abandoned script set are merged to form the abandoned component set;

[0012] Based on the set of obsolete interfaces, the set of internal useless code, and the set of obsolete components, a full system call graph is constructed to perform reverse reachability analysis and identify the cascading obsolete code set.

[0013] Based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the set of cascaded obsolete code, a complete redundant code report containing statistical data, a detailed list, and a risk assessment is generated.

[0014] Preferably, the step of identifying a set of obsolete interfaces based on interface access logs, site-wide scan results, and code repository information through set operations includes:

[0015] Based on the interface access logs, extract the URLs of the interfaces that have been called and the number of times they have been called, and generate an active interface set based on the URLs of the interfaces that have been called and the number of times they have been called;

[0016] Based on the full site scan results, extract the target visible interface URLs from all externally exposed pages, and generate a set of visible interfaces based on the target visible interface URLs;

[0017] Based on the code repository information, the public methods, routing configuration files, and API annotations in the controller class are analyzed, and a theoretical interface set is generated based on the analysis results.

[0018] Perform a union operation on the active interface set and the visible interface set to obtain the used interface set;

[0019] The discarded interface set is obtained by performing a difference operation on the theoretical interface set and the used interface set.

[0020] Preferably, the step of performing dynamic call detection and data flow analysis based on static analysis tools and abstract syntax trees to identify a set of internally useless code includes:

[0021] Based on the static analysis tool, predefined detection rules are set to scan unused methods, classes, and variables, generating a preliminary set of useless code;

[0022] Based on the abstract syntax tree, dynamic call patterns are identified, and the identified dynamic call points are marked as target nodes to be analyzed. A preliminary call relationship graph is then constructed based on the target nodes.

[0023] For the target node, a def-use analysis is performed to construct a data flow graph with variable definitions and usages as nodes and data dependencies as directed edges;

[0024] Based on the data flow graph, the initial call relationship graph is updated, and based on the updated call relationship graph, the initial set of useless code is corrected to obtain the internal set of useless code.

[0025] Preferably, the step of performing status checks and log analysis based on consumer running status, script execution records, and task scheduling configuration to identify a set of obsolete scripts and a set of obsolete consumers, and merging the set of obsolete consumers and the set of obsolete scripts to form a complete set of obsolete components, includes:

[0026] Based on the definition information of all consumer components in the system, check the running status and active processes of each consumer component to generate a set of abandoned consumers;

[0027] Based on the information of all script files in the system, check the configuration status of the corresponding scripts in the task scheduling system, analyze the task execution logs, and generate a set of obsolete scripts.

[0028] The abandoned consumer set and the abandoned script set are merged to obtain the complete abandoned component set.

[0029] Preferably, the step of constructing a full system call graph based on the set of obsolete interfaces, the set of internal unused code, and the set of obsolete components to perform reverse reachability analysis and identify the cascading obsolete code set includes:

[0030] Based on the updated call relationship graph, a full system call graph containing interfaces, functions, and classes is constructed; the nodes in the full system call graph are divided into entry nodes and internal nodes.

[0031] The elements in the set of obsolete interfaces and the set of obsolete components are marked as obsolete entries in the system call graph.

[0032] Starting from all non-abandoned entry nodes, perform a depth-first search and mark all reachable internal nodes as active nodes;

[0033] Starting from the abandoned entry node, perform a depth-first search to mark all reachable but not marked as active internal nodes;

[0034] The cascaded obsolete code set is obtained by merging and deduplicating only the internal nodes reachable from the obsolete entry point.

[0035] Preferably, before updating the initial call relationship graph based on the data flow graph, the method further includes:

[0036] Based on the data flow graph, the conditional branches and loop structures in the abstract syntax tree are traversed, each branch condition is converted into a Presburger arithmetic expression, and the path constraints of the program execution path are extracted based on the Presburger arithmetic expression.

[0037] Identify all possible constraints on dynamically invoked variables, construct a Presburger formula representing the range of variable values, and establish a variable constraint model;

[0038] Construct a Hardy field representing the program execution state, apply the monotonically decreasing property of the Hardy field function to the flow path of each variable, and determine the reachability of the execution path;

[0039] Solve the Presburger arithmetic constraint system based on the Presburger formula, exclude values ​​that are unreachable under any execution path, and obtain the precise set of values ​​for the target variable for dynamic invocation;

[0040] Based on the precise set of values, update the dynamic call parsing results and output a mathematically verified set of high-confidence dynamic call targets.

[0041] The step of updating the preliminary call relationship graph based on the data flow graph includes:

[0042] Based on the high-confidence dynamic call target set, update the preliminary call relationship graph.

[0043] Preferably, the method for generating the complete redundant code report includes:

[0044] Obtain the identified redundant code entries, construct a feature vector for each identified redundant code entry that includes code complexity, last modification time, and call path depth, and standardize the features to a uniform numerical range;

[0045] A discrimination model is constructed based on historical data, and the model is trained using the saddle point approximation method to evaluate the misclassification probability of each redundant code entry.

[0046] Calculate the negative moment of the false positive probability distribution, optimize the parameters of the redundant code recognition algorithm by minimizing the negative moment, and determine the edge cases of high-risk false positives;

[0047] A risk score is assigned to each of the redundant code entries. Based on the risk score, each of the redundant code entries is classified into risk categories, including high risk, medium risk, and low risk. Redundant code entries belonging to the high-risk category are marked as entries to be manually reviewed.

[0048] Based on the system scale and code characteristics, an objective function is constructed, and the optimal equilibrium point is solved using the saddle point method. The threshold parameter corresponding to the optimal equilibrium point is then used as the adjusted threshold parameter.

[0049] Preferably, after forming the collection of discarded components, the method further includes:

[0050] For each code entity, structural features are extracted from static analysis, behavioral features are extracted from dynamic analysis, evolutionary features are extracted from code repository history, and semantic features are extracted from code documentation to construct multimodal features corresponding to each code entity.

[0051] The multimodal features corresponding to each code entity are converted into a unified vector representation of that code entity. A global multidimensional feature matrix is ​​constructed based on the unified vector representation of all code entities. Dimensionality reduction is performed on the global multidimensional feature matrix to output a simplified feature representation. The simplified feature representation is input into a gating function to filter low-confidence features. Then, an attention mechanism is used to assign weights to the remaining filtered features. Based on the weighted features, a routing network dynamically routes them to the corresponding analysis branches. Conflict resolution is performed on the output results of each analysis branch to generate a comprehensive feature representation. Finally, an activity score for each code entity is generated based on the comprehensive feature representation.

[0052] Identify and filter common code noise patterns, apply adaptive thresholds to adjust the judgment criteria for different noise levels, and generate a confidence score for each code entity.

[0053] Based on the activity score and the confidence score, a comprehensive code usage status report is generated after noise filtering and cross-modal fusion.

[0054] The step of constructing a full system call graph based on the set of obsolete interfaces, the set of internal unused code, and the set of obsolete components to perform reverse reachability analysis and identify cascading obsolete code sets includes:

[0055] Based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the comprehensive code usage status report, a full system call graph is constructed to perform reverse reachability analysis and identify the cascading obsolete code set.

[0056] Preferably, the step of extracting structural features from static analysis, behavioral features from dynamic analysis, evolutionary features from code repository history, and semantic features from code documentation for each code entity, and constructing multimodal features corresponding to each code entity, includes:

[0057] For each code entity, the call relationships, inheritance hierarchy, and module dependencies of that code entity are analyzed to extract structural features that reflect the complexity and coupling of the code structure.

[0058] Based on the analysis of runtime call frequency, execution path distribution and resource consumption patterns, behavioral features reflecting code execution behavior are extracted.

[0059] By analyzing the frequency of code entity modifications, the number of authors who submitted the code, and the version span, and combining this with code change scale and stability indicators, we can extract evolutionary features that reflect the code lifecycle.

[0060] The code comments, function names, and docstrings are parsed, and natural language processing techniques are used to extract keywords and semantic tags to construct semantic features that reflect the functional intent of the code.

[0061] The structural features, behavioral features, evolutionary features, and semantic features are standardized, and multimodal features corresponding to each code entity are constructed through a weighted fusion mechanism.

[0062] The present invention also provides a redundant code identification device based on a data flow graph, comprising:

[0063] The obsolete interface identification module is used to identify the set of obsolete interfaces based on interface access logs, full site scan results, and code repository information through set operations.

[0064] The useless code identification module is used to perform dynamic call detection and data flow analysis based on static analysis tools and abstract syntax trees to identify the internal useless code set;

[0065] The obsolete component formation module is used to perform status checks and log analysis based on consumer running status, script execution records and task scheduling configuration, identify obsolete script sets and obsolete consumer sets, and merge the obsolete consumer sets and obsolete script sets to form obsolete component sets;

[0066] The cascading obsolete code identification module is used to construct a full system call graph based on the obsolete interface set, the internal useless code set, and the obsolete component set, perform reverse reachability analysis, and identify the cascading obsolete code set.

[0067] The redundancy report generation module is used to generate a complete redundancy code report containing statistical data, a detailed list, and a risk assessment based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the set of cascaded obsolete code.

[0068] The beneficial effects of this invention are as follows:

[0069] 1. Through multi-dimensional analysis, redundant code in the system can be fully identified, including obsolete interfaces, unused internal code, obsolete components, and cascading obsolete code;

[0070] 2. By using data flow graph analysis and dynamic call detection, the code recognition problem in dynamic call scenarios is effectively addressed, improving recognition accuracy;

[0071] 3. By analyzing the entire system call graph and reverse reachability, it identifies cascading obsolete code and provides end-to-end tracing capabilities from the interface layer to the method layer;

[0072] 4. By using a risk assessment mechanism, the risk of misjudging redundant code is reduced, providing a reliable basis for code cleanup. Attached Figure Description

[0073] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0074] Figure 1 This is an overall flowchart of a redundant code identification method based on a data flow graph according to the present invention;

[0075] Figure 2 This is a flowchart illustrating the process of identifying obsolete interfaces in this invention.

[0076] Figure 3 This is the overall flowchart of the dynamic invocation detection of the present invention;

[0077] Figure 4 This is a schematic diagram of the AST tree construction of the present invention;

[0078] Figure 5 This is an example diagram for constructing the data flow graph of the present invention;

[0079] Figure 6 This is a schematic diagram of the construction of the system call graph of the present invention. Detailed Implementation

[0080] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0081] like Figure 1 As shown, a redundant code identification method based on data flow graphs includes five main steps: interface obsolescence detection, internal useless code identification, obsolescence component detection (obsolescence scripts and consumers), cascade obsolescence code identification, and result integration and output.

[0082] Step S1: Based on the interface access logs, full site scan results, and code repository information, identify the set of abandoned interfaces through set operations.

[0083] This step primarily involves comprehensive analysis of multiple data sources to identify deprecated interfaces in the system. First, the system collects recent (e.g., the last 30 days) interface access logs, which can be obtained from a log collection system (such as ELKStack) or directly from server log files. By parsing and statistically processing these logs, the system extracts all actually invoked interface URLs and their call counts, forming an active interface set A. These interfaces, due to their actual call records, are considered to be still in use within the system.

[0084] Next, a site-wide scanning tool (such as AWVS) is deployed to scan all externally exposed pages. This tool recursively accesses each page in the system using web crawling technology, analyzing elements such as JavaScript code and form submission targets to extract all visible interface URLs—that is, all interface URLs that may be called by the front-end—forming a set B of visible interfaces. Although these interfaces may not be actually called during the observation period, they are still considered potentially usable interfaces because they exist in the front-end pages.

[0085] Subsequently, the system uses static code analysis to extract all defined interfaces from the code repository. This process includes analyzing public methods in controller classes, routing configuration files, API annotations, etc., to identify all theoretically existing interfaces in the system, forming a theoretical interface set C. This set represents all implemented interfaces in the system, regardless of whether they are actually used.

[0086] The system performs a union operation on the active interface set A and the visible interface set B to obtain the used interface set (A∪B). This set contains all interfaces for which there is evidence that they are currently in use or may be used. Finally, the system performs a difference operation on the theoretical interface set C and the used interface set, i.e., C-(A∪B), to obtain the obsolete interface set D. Interfaces in this set are defined in the code but are not called and do not appear in the front-end page, therefore they are determined to be obsolete interfaces.

[0087] like Figure 2 As shown, this step specifically includes:

[0088] S1.1: Extract the URLs of the interfaces that have been called and the number of times they have been called based on the interface access logs, and generate a set of active interfaces based on the URLs of the interfaces that have been called and the number of times they have been called.

[0089] This process involves collecting recent (e.g., the last 30 days) interface access logs from a log collection system (such as ELK) or directly from the server, processing the logs, and extracting all called interface URLs and their call counts.

[0090] In the first sub-step of identifying deprecated interfaces, the system needs to collect and process interface access logs to determine which interfaces are still active. The system first establishes connections with log sources, which may be centralized logging systems (such as the ELK Stack consisting of Elasticsearch, Logstash, and Kibana) or raw log files distributed across various servers. For large systems, log aggregation tools such as the ELK Stack are typically used, providing powerful log collection, storage, and query capabilities for large-scale log analysis.

[0091] The logs collected by the system typically cover a reasonable time window, such as the most recent 30 or 90 days. This time span needs to be determined based on the system's access patterns and business cycles. For systems with significant seasonality, a longer time window may be needed to cover the entire business cycle. After the logs are collected, the system performs preprocessing, including removing invalid records, standardizing URL formats, and filtering non-API requests. This step ensures that subsequent analysis is based on clean and consistent data.

[0092] Subsequently, the system performs statistical analysis on the processed logs, extracting metrics such as the number of calls, last call time, and average response time for each interface URL. For RESTful APIs, the system treats interfaces with the same resource path but different HTTP methods (such as GET / users and POST / users) as different interfaces for statistical analysis. Based on these statistics, the system generates an active interface set A, which contains all interface URLs that were called during the observation period and their related metrics. This set provides the foundational data for subsequent set operations.

[0093] S1.2: Based on the full site scan results, extract the target visible interface URLs from all externally exposed pages, and generate a set of visible interfaces based on the target visible interface URLs.

[0094] This process involves deploying a site-wide scanning tool (such as AWVS) to scan all externally exposed pages of the system, recursively accessing the pages through a crawler mechanism, and extracting all target visible interface URLs, that is, all interface URLs that may be called by the front end.

[0095] The second sub-step focuses on identifying interfaces that may not appear in the logs but are visible on the front-end pages. The system deploys professional website scanning tools (such as AWVS, Burp Suite, etc.) or a self-developed crawler system to comprehensively scan all externally exposed pages of the target system. The scanning tools simulate user behavior, starting from the system's entry page, recursively accessing and parsing links, forms, and JavaScript code on the page to construct a complete website structure diagram.

[0096] During the scan, the system pays particular attention to elements on the page such as AJAX calls, form submission targets, and WebSocket connections. These elements typically contain information about front-end code calling back-end APIs. For single-page applications (SPAs), the system executes the JavaScript code on the page and captures network requests generated at runtime to discover dynamically generated API calls. The scan also attempts to parse the routing configurations and API call patterns of various front-end frameworks (such as React, Vue, and Angular) to improve the completeness of API discovery.

[0097] After scanning, the system filters and categorizes the collected URLs, identifying those that match API call patterns. This is typically based on features such as URL path patterns, parameter structure, HTTP methods, and response formats. The system also removes duplicate URLs, standardizes parameter order, and normalizes dynamic path parameters (such as / users / 123 and / users / 456) to the same interface pattern (such as / users / {id}). Finally, the system generates a set B of visible interfaces, containing all API URLs that can potentially be called from the front-end page.

[0098] S1.3: Based on code repository information, analyze the public methods, routing configuration files, and API annotations in the controller class, and generate a theoretical interface set based on the analysis results.

[0099] Static code analysis extracts all defined interfaces from the code repository, including analyzing public methods in controller classes, routing configuration files, API annotations, etc.

[0100] The third sub-step extracts all interfaces defined in the system from the source code level. The system first obtains a full copy of the code repository or access permissions, which may be achieved through version control systems such as Git or SVN. For monolithic applications, the system directly analyzes the main repository; while for microservice architectures, the system needs to analyze the code repositories of all relevant services to build a complete interface view.

[0101] The system extracts API definition information from the code using static code analysis. Specific methods include: analyzing methods marked as public in controller classes (usually identified by specific annotations or naming conventions); parsing routing configuration files (such as Spring's RequestMapping, Laravel's routing files, etc.); analyzing API annotations (such as annotations in specifications like Swagger and OpenAPI); and examining configuration files from API documentation generation tools. This process requires different analysis strategies for different programming languages ​​and frameworks.

[0102] During the extraction process, the system not only records the API's URL path but also collects metadata such as HTTP methods, request parameters, and return types. For systems using API gateways or middleware tiers, the analysis also needs to consider path rewriting rules to map internal paths to externally exposed paths. For versioned APIs, the system identifies different versions of the same interface and treats them as independent interfaces. Ultimately, the system generates a theoretical interface set C, containing all API definitions extracted from the code, regardless of whether they are actually used.

[0103] S1.4: Perform a union operation on the active interface set and the visible interface set to obtain the used interface set.

[0104] The fourth sub-step merges the interface sets obtained from the first two steps to determine all interfaces that are used or may be used in the system. The system performs a union operation (A∪B) on the active interface set A and the visible interface set B to obtain the set of used interfaces. This operation needs to consider different representations of interface URLs to ensure that the same interface is not counted repeatedly due to differences in URL format (such as trailing forward slashes, capitalization, default ports, etc.).

[0105] Before performing the union operation, the system standardizes the URLs in both sets, including normalizing path formats, removing default port numbers, and unifying the order of query parameters. For URL paths containing dynamic parts (such as path segments containing parameters like IDs or dates), the system uses pattern matching or regular expressions to normalize them into a common pattern. This ensures that the same interface with different representations can be correctly identified and merged.

[0106] The result of the union operation is a comprehensive set representing all interfaces in the system that have evidence of being in use or likely to be used. This set is more comprehensive than the set of active interfaces obtained solely from log analysis because it also includes interfaces that may not have been called during the observation period but exist in the front-end code and could be triggered at any time.

[0107] S1.5: Perform a difference operation on the theoretical interface set and the used interface set to obtain the discarded interface set.

[0108] The calculation formula is D = C - (A ∪ B), which means removing those interfaces that have appeared in the logs or are visible on the front-end page from all defined interfaces.

[0109] The final sub-step uses a difference operation to identify the interfaces defined but not used in the system. The system performs a difference operation (C - (A∪B)) on the theoretical interface set C and the used interface set to obtain the obsolete interface set D. The interfaces in this set are defined in the source code, but there is no evidence that they are being used or might be used.

[0110] Before performing the difference operation, the system needs to ensure that the URL format in the theoretical interface set C is consistent with the format in the used interface set. This may involve processing such as path format conversion and parameter order standardization. For auxiliary interfaces automatically generated by the framework (such as health checks, monitoring endpoints, etc.), the system may need to exclude them from the theoretical interface set according to the configuration to avoid misjudgment.

[0111] After the difference operation is completed, the system performs additional verification on each interface in the obsolete interface set D, such as checking their last modification time, associated test case coverage, and whether there are associated obsolete comments. This additional information helps improve the accuracy of obsolete judgment and provides more context for subsequent cleanup decisions. Finally, the system outputs the verified obsolete interface set D, which serves as an important input for subsequent cascading obsolete code analysis.

[0112] Step S2: Based on static analysis tools and abstract syntax trees, perform dynamic call detection and data flow analysis to identify the set of useless internal code.

[0113] This step uses a combination of static analysis and dynamic call detection to identify unused code within the system. First, a static code analysis tool (such as SonarQube) is configured and run. Predefined detection rules are set for the project code to specifically scan for unreferenced methods, classes, and variables. The static analysis tool then traverses all code files, analyzing the reference relationships between code segments to identify code elements that are not referenced by other code. The analysis results include information such as the name, location, and type of these unreferenced elements, forming a preliminary set of useless code, E1.

[0114] However, static analysis tools have certain limitations, especially when dealing with dynamic call scenarios (such as calls via reflection, variable function names, etc.). To address this issue, the system uses a code parser (such as PHP-Parser, JavaParser, etc.) to parse the source code and generate an Abstract Syntax Tree (AST). The system traverses the AST, identifying the definitions of all functions and classes, as well as the static call relationships between them, constructing a preliminary call relationship graph. During this process, the system pays special attention to dynamic call patterns, such as special structures like `call_user_func`, reflection calls, and variable function names, marking these dynamic call points as target nodes requiring further analysis.

[0115] For each marked dynamic call point, the system performs data flow analysis. This process first constructs a data flow graph, where variable definitions (def) and uses (use) are nodes, and data dependencies are directed edges. The system performs def-use analysis, tracing the definition and flow path of variable values. For example, when a variable is assigned the value of a function name string and then used as the target of a function call in subsequent code, the system uses backtracking analysis of the data flow graph to determine the possible range of values ​​for that variable, thereby resolving the actual set of functions that might be called.

[0116] Based on the data flow analysis results, the system resolves dynamic calls into specific static call targets, updates the previously constructed call relationship graph, and adds call edges from dynamic call points to the resolved actual target functions. Using the updated call relationship graph, the system re-evaluates the elements in the initial useless code set E1, excluding code referenced through dynamic calls, and obtains a more accurate internal useless code set E.

[0117] like Figure 3 As shown, this step specifically includes:

[0118] S2.1: Based on static analysis tools, predefined detection rules are set to scan unused methods, classes, and variables, generating a preliminary set of useless code.

[0119] Specifically, this involves configuring and running static code analysis tools (such as SonarQube), setting predefined detection rules, scanning for unused methods, classes, and variables, and collecting static analysis results, including a list of unreferenced functions, classes, and variables and their location information.

[0120] The first sub-step of identifying useless internal code is to detect unreferenced code elements using static analysis tools. The system first configures and deploys professional static code analysis tools, such as SonarQube, PMD, or ESLint. These tools are based on static program analysis techniques and can discover potential problems without executing the code. The system selects appropriate analysis tools and configures corresponding rule sets based on the project's programming language and architectural characteristics.

[0121] When configuring the analysis tools, the system pays particular attention to rules related to unused code detection, such as "unused private methods," "unused private fields," and "unreferenced classes." These rules may have different implementations and names for different programming languages. The system also adjusts the strictness and exclusion patterns of the rules to suit the specific circumstances of the project. For example, factory classes with certain patterns or methods invoked via reflection may need to be excluded from the detection scope.

[0122] The system runs a pre-configured static analysis tool to perform a comprehensive scan of the entire codebase. During the analysis, the tool constructs a symbol table and reference graph for the code, tracking the definition and references of each code element (such as classes, methods, fields, etc.). Elements that are defined but not referenced are marked as potentially useless code. After the scan is complete, the system collects the analysis results, including information such as the type, location, and severity of each unused element, forming a preliminary set of useless code, E1.

[0123] S2.2: Based on the abstract syntax tree, identify dynamic call patterns and mark the identified dynamic call points as target nodes to be analyzed, and construct a preliminary call relationship graph based on the target nodes.

[0124] like Figure 4 As shown, the specific process includes: using a code parser (such as PHP-Parser, JavaParser, etc.) to parse the source code and generate an abstract syntax tree (AST); traversing the AST to identify all function and class definitions and their static call relationships, and constructing a preliminary call relationship graph; identifying dynamic call patterns in the AST, such as special structures like call_user_func, reflection calls, and variable function names; and marking the identified dynamic call points as target nodes that need further analysis.

[0125] The second sub-step prepares for subsequent dynamic call detection by constructing and analyzing the Abstract Syntax Tree (AST). The system first selects a code parser suitable for the project's programming language, such as PHP-Parser for PHP, JavaParser for Java, and Babel for JavaScript. These parsers can convert source code text into a structured AST, facilitating programmatic analysis and processing.

[0126] The system uses a selected parser to parse each source file in the codebase, generating a corresponding Abstract Syntax Tree (AST). An AST is a tree-like representation of the source code, where each node represents a syntactic structure in the code (such as a function definition, variable declaration, or expression). Compared to the original code text, the AST provides a more structured and standardized code representation, facilitating precise code analysis.

[0127] The system traverses the generated AST, identifying all function, method, and class definitions, as well as the static call relationships between them. Static calls refer to function calls whose targets can be determined at compile time, such as direct calls to named functions or methods. The system creates a node for each function / method and a directed edge from the caller to the callee for each static call, thus constructing a preliminary call relationship graph.

[0128] In addition to identifying static calls, the system pays special attention to code patterns that may involve dynamic calls. This includes calls using function variables (such as "fn()" in JavaScript, where "fn" is a variable), functions whose call targets are specified by strings (such as "call_user_func()" in PHP or reflection calls in Java), and other language-specific dynamic call mechanisms. The system marks the identified dynamic call points as target nodes requiring further analysis, preparing for subsequent data flow analysis.

[0129] S2.3: Perform def-use analysis on the target node to construct a data flow graph with variable definitions and usages as nodes and data dependencies as directed edges.

[0130] like Figure 5 As shown, the specific process includes: constructing a data flow graph for each dynamic call point, with variable definition (def) and use (use) as nodes and data dependencies as directed edges; performing def-use analysis to trace the definition and flow path of variables; and determining the possible value set of the dynamic call target through backtracking analysis of the data flow graph.

[0131] The third sub-step uses data flow analysis techniques to track the flow of variable values ​​and analyze the possible targets of dynamic calls. The system first constructs a relevant data flow graph for each dynamic call target node marked in S2.2. A data flow graph is a special type of directed graph where nodes represent the definition and use of variables, and edges represent data dependencies.

[0132] The system performs def-use analysis, tracing the complete path from definition to use of variables associated with dynamic calls. For example, for the code '$func = "process"; $func($data);', the system traces the path from the definition of variable '$func' (assigned the value "process") to its use (as the target of a function call). This analysis needs to consider the variable's scope, control flow paths (such as conditional branches and loops), and possible alias relationships.

[0133] For complex data flow paths, the system may need to perform context-sensitive analysis, taking into account the context information of the call points. For example, in different conditional branches, the same variable may be assigned different function names, resulting in different targets for dynamic calls. The system constructs a data flow state for each possible execution path by tracing the control flow path and conditional constraints.

[0134] Through backtracking analysis of the data flow graph, the system determines the set of possible values ​​for the target variable in dynamic invocation. In simple cases, this might be a single, definite function name; in complex cases, it might be multiple possible function names. The system also evaluates the confidence level of each possible target based on factors such as the complexity of the analysis path and the number of assumptions involved. The results of the data flow analysis provide a more accurate resolution for dynamic invocation, exceeding the capabilities of simple static analysis.

[0135] S2.4: Based on the data flow graph, update the initial call relationship graph, and based on the updated call relationship graph, correct the initial set of useless code to obtain the internal set of useless code.

[0136] The specific process includes: based on the data flow analysis results, resolving dynamic calls into specific static call targets; updating the call relationship graph by adding call edges from the dynamic call point to the actual target function; and correcting the useless code set according to the updated call relationship graph to obtain more accurate results.

[0137] The final sub-step involves updating the call graph and correcting the set of useless code based on the data flow analysis results. The system first integrates the dynamic call targets parsed in S2.3 into the call graph. For each dynamic call point, the system adds directed edges from the call point to all possible target functions; each edge may also include confidence information, indicating the degree of determinism of the call relationship.

[0138] When updating call relationships, the system handles special cases, such as function names generated by string concatenation or methods accessed through arrays or object properties. For dynamic calls that cannot be precisely parsed, the system may adopt a conservative strategy, treating them as calls to functions that could match any name, or marking them as special cases requiring manual review.

[0139] After updating the call graph, the system re-evaluates the initial set of useless code E1 identified in S2.1. For each code element in E1, the system checks the updated call graph to determine if the element has an incoming edge (i.e., whether it is called by other code). If an element has an incoming edge in the new call graph, it is removed from the useless code set, as this indicates that the element may be used through dynamic calls.

[0140] The system also considers indirect usage scenarios. For example, a class might not be directly called, but its subclasses might be used; or an interface might not be directly referenced, but its implementing classes might be used. By tracing these indirect relationships, the system further optimizes the identification of useless code. Ultimately, the system outputs an internal set of useless code, E, corrected by dynamic call analysis. This set is more accurate and has a lower false positive rate than the initial result E1.

[0141] In one embodiment of the present invention, before step S2.4, a data flow reachability analysis step based on the Hardy field function is further included, specifically including:

[0142] S2.4.1: Based on the data flow graph, traverse the conditional branches and loop structures in the abstract syntax tree, convert each branch condition into a Presburger arithmetic expression, and extract the path constraints of the program execution path based on the Presburger arithmetic expression.

[0143] The specific process includes: traversing the conditional branches (if-else, switch-case, etc.) and loop structures (for, while, etc.) in the AST, and converting each branch condition into the Presburger arithmetic expression form. For example, the condition if($a>5&&$b<10) is converted into the constraint set {a>5, b<10}.

[0144] In the first fine-grained step of call relationship updating and useless code correction, the system implements a program path constraint extraction method based on Presburger arithmetic. Presburger arithmetic is a subset of first-order logic that specifically handles formulas for integer addition. It supports quantifiers, Boolean connectives, and linear constraints on integers, making it a powerful tool for expressing path constraints in program analysis. The system first fully traverses the abstract syntax tree (AST) constructed in the previous steps, paying particular attention to control structures that may affect the program execution path, such as conditional branches and loop statements.

[0145] For each conditional branch structure (such as if-else and switch-case statements), the system extracts the conditional expressions and converts them into standard Presburger arithmetic expression form. For example, for the conditional statement 'if($a>5&&$b<10)', the system decomposes it into atomic constraints '{a>5, b<10}' and records the association between these constraints and the execution path. For nested conditional structures, the system maintains the hierarchical relationship of constraints to ensure the correct representation of the combination of path constraints. In particular, for switch-case structures, the system converts them into equivalent if-else-if chains and then applies the same constraint extraction method.

[0146] Loop structures (such as for and while statements) are handled more complexly because they may cause variable values ​​to change with the number of iterations. The system employs two strategies to handle loops: for simple loops (loops with a fixed number of iterations or a definite upper limit), the system may unroll the loop and convert it into an equivalent sequence of branches; for complex loops, the system may apply loop invariant analysis to extract constraints that remain unchanged during loop execution, or summarize the overall behavior of the loop and convert it into constraints on the possible range of variable values.

[0147] When handling logical operators, the system pays special attention to the effects of short-circuit evaluation. For example, in the expression '$a>0&&func($a)', 'func($a)' is executed only if '$a>0' is true. The system correctly represents this behavior by introducing auxiliary variables in the constraints or decomposing the execution path. Similarly, the system also handles special control structures such as conditional operators (ternary operators), null co-operators, etc., converting them into equivalent conditional branching forms and then extracting the corresponding constraints.

[0148] After analyzing all control structures, the system constructs a complete set of path constraints for each possible execution path. Path constraints are a set of Presburger formulas representing all conditions that must be met for the program to execute along a specific path. These constraint sets will be used in subsequent steps to determine the possible targets of dynamic calls, providing a rigorous mathematical foundation for program analysis.

[0149] S2.4.2: Identify all possible constraints on the variables related to dynamic invocation, construct a Presburger formula representing the range of variable values, and establish a variable constraint model.

[0150] For example, for the code $funcName = ($condition) ? 'method1' : 'method2', a mapping relationship is established: condition=true→funcName='method1', condition=false→funcName='method2'.

[0151] The second detailed step primarily involves comprehensive constraint modeling of variables related to dynamic calls. The system first identifies all variables relevant to dynamic calls, whose values ​​ultimately determine the actual target of the call. For each such variable, the system collects all possible definition points (assignment statements) in the program and all control flow paths that might affect its value.

[0152] The system constructs a precise constraint model for each dynamically invoked variable, representing the possible values ​​of that variable under different execution paths. This process typically begins at each definition point of the variable and analyzes forward along the control and data flows to identify all factors affecting the final value of the variable. For example, considering the code snippet '$funcName = ($condition) ? 'method1' : 'method2';', the system establishes a mapping relationship 'condition=true→funcName='method1',condition=false→funcName='method2'', associating the value of the condition variable with the value of the target function name.

[0153] For more complex scenarios, such as when variables are assigned multiple times or modified through function calls, the system employs symbolic execution to simulate the state changes of variables during program execution. For example, for the code snippet '$func = 'base_'; if($mode == 'admin') { $func .= 'admin_';} $func .= 'process'; $func($data); ', the system uses symbolic execution to deduce the possible values ​​of '$func' under different conditions as '{'base_process', 'base_admin_process'}', thereby determining the possible targets for dynamic calls.

[0154] The system also pays special attention to the handling of arrays and object properties, as they are frequently used to implement dynamic invocation mechanisms. For example, for the code '$handler = $handlers[$type]; $handler->process($data);', the system needs to analyze the structure of the '$handlers' array and the possible values ​​of the '$type' variable to determine the object type that '$handler' might reference, and thus the possible implementation of the 'process' method. This usually requires combining information from other parts of the program, such as the initialization code of the '$handlers' array and the constraints of the '$type' variable.

[0155] For function names constructed through string manipulation, the system applies string analysis techniques to attempt to determine the set of possible values ​​for the string. For example, for the code '$method = 'handle' . ucfirst($action); $this->$method();', the system analyzes the possible values ​​of the variable '$action' and the effects of string manipulations to deduce the possible value set of `$method`, such as '{'handleCreate', 'handleUpdate', 'handleDelete'}'.

[0156] Through these detailed constraint modeling processes, the system establishes accurate Presburger constraint models for each dynamically invoked variable, representing the possible values ​​of the variables under various program states. These models will be combined with path constraints in subsequent steps to determine the actual target of the dynamically invoked variable on a specific execution path.

[0157] S2.4.3: Construct a Hardy field representing the program execution state, apply the monotonically decreasing property of the Hardy field function to the flow path of each variable, and determine the reachability of the execution path.

[0158] The third fine-grained step introduces Hardy field theory to analyze the reachability of program execution paths. Hardy fields are a concept in function analysis that satisfy the monotonically decreasing property, and can be used to prove program termination and analyze the reachability of execution paths. In this step, the system constructs a Hardy field representing the program's execution state based on the program's control flow graph, and uses the properties of the Hardy field to analyze path reachability.

[0159] The system first assigns a state node to each basic block of the program (a sequence of code excluding branches) and connects these nodes according to control flow relationships to form a control flow graph. For each variable in the program, the system defines a Hardy field function, which maps the program state to natural numbers and satisfies the property that the value monotonically decreases during program execution. Specifically, for inductive variables in loop structures (such as loop counters), the Hardy field function is typically defined as the distance from the loop termination condition to the current value; for other variables, the Hardy field function may be defined based on the variable's data dependencies or the structural characteristics of the program.

[0160] Using the constructed Hardy field, the system analyzes the reachability of each execution path. For a given set of path constraints (extracted in step S2.4.1), the system checks whether there exists a program state that satisfies these constraints, such that, starting from this state and executing according to the control flow specified by the path, the value of the Hardy field function always remains monotonically decreasing and eventually reaches a termination state. If such a state exists, the path is determined to be reachable; otherwise, the path is determined to be unreachable.

[0161] The system pays particular attention to loop structures because they can lead to infinite execution paths. By analyzing the changes in the Hardy field function within the loop body, the system can determine whether the loop will necessarily terminate and the range of possible execution counts. This is crucial for understanding the possible values ​​of variables within the loop. For example, for loops...

[0162] '

[0163] while

[0164] ($i<100) { $i += 2;}

[0165] '

[0166] The system can deduce that the loop will execute at most 50 times, and that the value of '$i' will be even and not less than 100 after the loop ends.

[0167] For conditional branching structures, the system analyzes the Hardy field characteristics of different branch paths. For example, for the code...

[0168] '

[0169] if ($x>0)

[0170] { $func = 'positive';}

[0171] else { $func = 'negative';}

[0172] The system analyzes the values ​​of the variable `$func` under the constraints of '$x>0' and '$x<=0', and determines the reachability of these two branch paths. If the path constraint of a branch conflicts with other constraints of the program, making it impossible to execute the branch under any circumstances, the system will mark the branch as unreachable.

[0173] By using Hardy field analysis, the system can eliminate execution paths that are mathematically proven to be unreachable, thereby improving the accuracy of dynamic call analysis. This method is particularly suitable for programs containing complex loops and conditional structures, and can reveal subtle path constraints that are difficult to capture by traditional data flow analysis.

[0174] S2.4.4: Solve the Presburger arithmetic constraint system based on the Presburger formula, exclude values ​​that are unreachable under any execution path, and obtain the precise set of values ​​for the target variable for dynamic invocation.

[0175] The fourth fine step uses constraint solving techniques from mathematical logic to solve the constructed Presburger arithmetic constraint system and determine the precise set of values ​​for the dynamically invoked target variable.

[0176] The system first obtains a Presburger arithmetic constraint system based on the Presburger formula, which integrates all constraints collected in the previous steps into a unified Presburger constraint system. This includes constraints extracted from the program path (step S2.4.1), value constraints of dynamically called variables (step S2.4.2), and reachability constraints determined through Hardy field analysis (step S2.4.3). The integrated constraint system represents the complete constraint conditions for the possible values ​​of variables in the program.

[0177] For the integrated constraint system, the system uses a dedicated Presburger arithmetic solver. These solvers are typically implemented based on techniques such as quantifier elimination, automata theory, or integer linear programming. The solution process determines whether the constraint system has a solution (i.e., whether there are variable assignments that satisfy all constraints). If a solution exists, the system finds the set of all possible solutions. For dynamically invoked target variables, the system pays particular attention to the complete set of their possible values.

[0178] During the solution process, the system may need to handle constraints beyond the expressive power of the Presburger formula. For example, string manipulation and complex data structure operations often cannot be directly represented by the Presburger formula. For such constraints, the system may employ approximation methods (such as over-approximation or under-approximation) or combine them with other domain-specific constraint solvers (such as string constraint solvers). These processes ensure that the system can handle various complex situations in real-world programs.

[0179] The result of constraint solving is an exact set of values ​​for the target variable in dynamic calls, representing all possible values ​​the variable can take under all possible execution paths. This set excludes values ​​that are impossible under any execution path, thus providing greater accuracy than simple static analysis. For example, for the previously mentioned code '$funcName = ($condition) ? 'method1' : 'method2';', if path constraint analysis reveals that '$condition' is always true in the program, then constraint solving will determine that the only possible value of '$funcName' is 'method1'.

[0180] The constraint solution results also include the conditions for each possible value, that is, the preconditions that must be met for a variable to take a specific value. These conditions are crucial for understanding the triggering mechanism of dynamic calls and also help with subsequent testing and verification. For example, the system may determine that the function 'handleSpecial' is only called on a specific error handling path, which prompts developers to pay special attention to testing error handling scenarios before deleting the function.

[0181] S2.4.5: Based on the precise value set, update the dynamic call parsing results and output a mathematically verified high-confidence dynamic call target set.

[0182] Furthermore, in this case, after obtaining the set of high-confidence dynamic invocation targets, the preliminary invocation relationship graph can be updated based on the set of high-confidence dynamic invocation targets.

[0183] This final, meticulous step updates the dynamic call resolution results based on the constraint solving results, outputting a mathematically validated set of high-confidence dynamic call targets. The system first maps the set of dynamic call variable values ​​obtained from constraint solving to specific function or method definitions in the program. This mapping considers factors such as the program's namespace rules, class inheritance relationships, and function aliases to ensure accurate identification of each possible call target.

[0184] For each identified potential call target, the system assigns a confidence score, representing the likelihood that the target will actually be invoked. The confidence score is based on several factors: the determinism of constraint solutions (whether there is a unique solution or multiple possible solutions); the complexity of path constraints (simple and explicit path constraints generally lead to higher confidence); the degree of influence of dynamic characteristics (characteristics that are difficult to analyze statically, such as reflection and eval, will lower the confidence); and the number of assumptions made during the analysis (fewer assumptions result in higher confidence). This confidence score helps distinguish between highly deterministic and speculative call relationships in subsequent analysis.

[0185] The system adds dynamic call targets with high confidence (typically exceeding a predetermined threshold, such as 90%) to the call graph constructed in step S2.2. For each added dynamic call edge, the system records its type (dynamic call), source (variable name and call expression), objective function, confidence score, and triggering condition (prerequisites for constraint solving). This detailed information provides important context for subsequent useless code analysis.

[0186] For potential call targets with low confidence, the system may adopt different processing strategies depending on the level of conservatism set in the analysis. In conservative mode, the system may still add these targets to the call graph but mark them as "low confidence," indicating that additional verification is needed; in aggressive mode, the system may ignore these low-confidence targets and focus on more likely call relationships. This flexibility allows users to balance the completeness and accuracy of the analysis according to specific needs.

[0187] Finally, the system re-evaluates the initial set of useless code E1 identified in S2.1. For each code element in E1, the system checks the updated call graph (including newly added high-confidence dynamic call edges) to determine if the element has an incoming edge. If the element has an incoming edge in the new call graph, it is removed from the useless code set; otherwise, its position in the useless code set is retained, but its metadata may be updated, such as adding a "verified by dynamic call analysis" tag.

[0188] Through this analysis based on precise mathematical methods, the system significantly improves the accuracy of dynamic call parsing, reduces the false alarm rate, and provides a solid mathematical foundation for the identification of useless code. The final output, the corrected internal useless code set E, has high reliability, providing a dependable reference for subsequent code cleanup decisions.

[0189] Step S3: Based on the consumer's running status, script execution records, and task scheduling configuration, perform status checks and log analysis to identify the obsolete script set and obsolete consumer set, and merge the obsolete consumer set and obsolete script set to form the obsolete component set.

[0190] This step primarily identifies script files and consumer components that are no longer used in the system. First, the system collects the definition information of all consumer components, which can be obtained from system configuration files, service registries, or code annotations. For each consumer component, the system checks its running status, including whether it is started and whether there are active processes. This can be achieved by querying the process management system, container orchestration platform, or service registry. Simultaneously, the system analyzes the consumer's runtime logs to determine if there are any message processing records in the recent past (e.g., the last 30 days). Combining this information, the system identifies consumers that are not started or have been inactive for a long time, forming a set of obsolete consumers, F1.

[0191] Next, the system collects information on all script files in the system, including command-line scripts and scheduled task scripts. For these scripts, the system checks their configuration status in the task scheduling system (such as Crontab, Quartz, etc.) to determine which scripts have been configured for scheduled execution. The system also analyzes task execution logs to determine whether the scripts have been actually executed recently. For non-scheduled task scripts, the system analyzes their execution records and last modification time to determine whether they are one-time scripts or obsolete scripts. Based on the combined analysis results, the system identifies obsolete script files, forming a set of obsolete scripts, F2.

[0192] Finally, the system merges the obsolete consumer set F1 and the obsolete script set F2 to obtain the complete obsolete component set F. The components in this set, although still present in the system, are no longer used or executed, possibly due to business changes, feature replacements, or system restructuring.

[0193] S3 specifically includes:

[0194] S3.1: Based on the definition information of all consumer components in the system, check the running status and active processes of each consumer component, and generate a set of abandoned consumers.

[0195] The specific process includes: collecting the definition information of all consumer components in the system; checking the running status of each consumer, including whether it has been started and whether there are active processes; analyzing consumer logs to determine whether there are recent message processing records; and combining the above information to identify consumers that have not been started or have been inactive for a long time.

[0196] The first sub-step of deprecated scripts and consumer detection is to check the running status of each consumer component in the system. Consumer components typically refer to background processes responsible for handling asynchronous messages, events, or tasks, such as message queue listeners, event subscribers, or data processing workers. The system first gathers definition information for consumer components from multiple sources, which may include configuration files, service registries, code annotations, or dedicated component registries. For microservice-based systems, this step may require connecting to a service discovery system (such as Consul, Eureka, or the Kubernetes API) to obtain a complete list of services.

[0197] After collecting the consumer component list, the system performs a runtime status check on each component. This typically involves multiple technical methods: for containerized environments, the system may query the API of a container orchestration platform (such as Kubernetes or Docker Swarm) to check the status of the Pod or container corresponding to each consumer component; for traditional deployment environments, the system may connect to each server via SSH and use process management tools (such as ps, top, or systemctl) to check the process status; for components that support health checks, the system may directly call their health check endpoints to verify the component's response status.

[0198] In addition to checking the current running status, the system also analyzes the historical activity records of the consumer components. This includes examining the component's log files to find message processing records, error reports, and activity timestamps. The system may connect to log aggregation platforms (such as ELK Stack or Graylog) to query log data for a specific time range (such as the last 30 days). For consumers using message queues, the system may also check the monitoring data of the queue system (such as RabbitMQ or Kafka) to verify whether the consumer is actively subscribing to and processing messages.

[0199] By comprehensively analyzing operational status and historical activity, the system identifies consumer components that may have been deprecated. The criteria typically include: consumers that have not been started or running for an extended period (e.g., more than 30 days); consumers whose processes exist but have not processed any messages for a long time; and consumers that have been marked as inactive or disabled in the monitoring system. The system collects these consumer components that meet the deprecated criteria into a deprecated consumer set F1, which serves as the basis for subsequent analysis.

[0200] S3.2: Based on the information of all script files in the system, check the configuration status of the corresponding script in the task scheduling system, analyze the task execution log, and generate a set of obsolete scripts.

[0201] The specific process includes: collecting information on all script files in the system, including command-line scripts and scheduled task scripts; checking the configuration status of the scripts in the task scheduling system (such as Crontab); analyzing the task execution logs to determine whether the scripts have been executed recently; and for non-scheduled task scripts, analyzing their execution records to determine whether they are one-time scripts or obsolete scripts.

[0202] The second sub-step focuses on the execution status of various script files in the system. Script files typically refer to standalone executable files used to perform specific tasks, data processing, or system maintenance, such as shell scripts, Python scripts, and PHP command-line scripts. The system first collects information on all script files by scanning the code repository and deployment directory. This process may require identifying different types of script files (based on file extensions, shebang lines, or other markers) and excluding those that are clearly library files or test scripts.

[0203] For each collected script file, the system checks its configuration status within the task scheduling system. This may involve analyzing configurations for various scheduling systems, such as Unix / Linux crontab files, Windows scheduled tasks, job definitions for enterprise scheduling platforms (such as Control-M and Airflow), or application-internal scheduling configurations. The system records whether each script is configured to execute on a scheduled basis, the configured execution frequency, and the last modified time.

[0204] Next, the system analyzes the historical execution history of the tasks to determine the actual execution status of the scripts. This includes checking the execution logs of the scheduling system, the script's own output logs, and any existing execution result records. For scripts that interact with the database, the system may also check the database access logs or audit logs to find evidence of script execution. The analysis focuses on determining the last execution time, execution frequency, and execution results of each script to assess its activity level.

[0205] Based on a comprehensive analysis of configuration status and execution records, the system identifies script files that may be obsolete. The criteria typically include: scripts not configured in any scheduling system and not executed for an extended period (e.g., more than 90 days); scripts configured but whose execution tasks have been disabled or have failed to execute successfully for an extended period; and scripts with clear evidence that they were one-off tasks (e.g., data migration, system upgrades) and have already been completed. The system collects these obsolete script files into the obsolete script set F2.

[0206] S3.3: Merge the obsolete consumer set and obsolete script set to obtain a complete obsolete component set.

[0207] The third sub-step merges the discarded consumers and discarded scripts identified in the first two steps to form a complete set of discarded components. The system first performs data standardization on the discarded consumer set F1 and the discarded script set F2 to ensure that elements in both sets have a consistent representation format. This may include unified path representation, standardized naming formats, and the addition of unified metadata fields (such as component type, discard criteria, last active time, etc.).

[0208] During the merging process, the system handles potential duplication or conflict. For example, some components may exist simultaneously as consumers and scripts (e.g., a script file can be executed as a scheduled task or run as a message consumer). In such cases, the system needs to merge relevant information to ensure that each logical component has only one entry in the final set, while retaining all related criteria for discarding certain items.

[0209] After merging, the system performs additional validation and enrichment on the set of obsolete components F. This may include: querying the code repository's history to determine the component's last modification time and the modifier; examining the component's documentation and comments to find possible obsolescence instructions or use case descriptions; and mapping it to known system functional modules to assess the component's business importance. This additional information helps with subsequent risk assessment and cleanup decisions.

[0210] Finally, the system outputs a verified and comprehensive set of obsolete components, F. This set contains all potentially obsolete consumer components and script files in the system, with each entry accompanied by detailed metadata such as component type, location, obsolete determination criteria, last active time, and risk rating. This set will serve as an important input for subsequent cascading obsolete code analysis, forming a complete view of obsolete entry points together with the obsolete interface set.

[0211] Step S4: Based on the set of obsolete interfaces, the set of internal useless code, and the set of obsolete components, construct a full system call graph to perform reverse reachability analysis and identify the cascading obsolete code set.

[0212] This step identifies cascading obsolete code that is only called by obsolete interfaces, components, or scripts by constructing a full system call graph and performing reverse reachability analysis. First, the system merges the call relationship information obtained in the previous steps to construct a full system call graph containing all components such as interfaces, functions, and classes. In this call graph, nodes are divided into two categories: entry nodes (such as interfaces, scripts, and consumers) and internal nodes (such as ordinary functions and class methods). The system also establishes call edges to represent dependencies from the caller to the callee.

[0213] Subsequently, the system marks the elements in the set of obsolete interfaces D identified in step S1 and the set of obsolete components F identified in step S3 as obsolete entry points in the call graph. These obsolete entry points are the starting point for the system to analyze cascading obsolete code. Starting from all non-obsolete entry point nodes (i.e., still-used interfaces, scripts, and consumers), the system performs a depth-first search, marking all reachable internal nodes as "active nodes." These active nodes represent code still used by normal functional paths in the system.

[0214] Next, the system performs a depth-first search starting from all abandoned entry points, but only marks internal nodes that are reachable but not marked as "active." These nodes represent code reachable only from abandoned entry points—cascading abandoned code. The system merges and deduplicates this cascading abandoned code, resulting in a set G of cascading abandoned code. While the code in this set may not have obvious problems, it becomes useless as these abandoned entry points are removed because it is only called by obsolete interfaces or components.

[0215] like Figure 6 As shown, it specifically includes:

[0216] S4.1: Based on the updated call relationship graph, construct a full system call graph that includes interfaces, functions, and classes; the nodes in the full system call graph are divided into entry nodes and internal nodes.

[0217] The specific process includes: merging the call relationship information from the previous steps to construct a full system call graph containing all components such as interfaces, functions, and classes; dividing the nodes in the call graph into entry nodes (interfaces, scripts, consumers) and internal nodes (ordinary functions, class methods, etc.); and constructing call edges to represent the dependency relationship from the caller to the callee.

[0218] The first sub-step of cascading obsolete code identification is to construct a system-wide call graph containing all system components and their call relationships. The system first integrates the various call relationship information already constructed in the preceding steps, including the mapping relationship between interfaces and controllers, the call relationship between controllers and service layers, static function call relationships, and dynamic call relationships parsed through data flow analysis. For large systems, this may involve merging local call graphs from multiple microservices or modules to form a global view.

[0219] When constructing the system call graph, nodes are divided into two categories: entry nodes and internal nodes. Entry nodes represent external access points to the system, including API interfaces, command-line scripts, consumer components, and scheduled tasks. These nodes are typically where the execution flow begins, representing the trigger points for system functions. Internal nodes represent internal code elements such as functions, methods, and classes, which are called by other nodes to collectively implement system functions.

[0220] The system adds rich metadata to each node in the call graph, including node type (interface, script, function, class, etc.), code location (file path, line number), last modified time, complexity metrics, etc. For function and method nodes, it may also include parameter information, return type, access modifiers, etc. This metadata will provide important contextual information in subsequent analysis.

[0221] The edges in the call graph represent dependencies from the caller to the callee. The system adds attributes to each edge, such as call type (static call, dynamic call), call confidence (for dynamically resolved calls), and call frequency (if runtime data is available). For conditional calls (such as calls within if statements), the edge attributes may also include condition information, indicating the constraints that caused the call. Once constructed, the entire system call graph provides a complete structural foundation for subsequent reachability analysis.

[0222] S4.2: Mark the elements in the deprecated interface set D and the deprecated component set F as deprecated entries in the system call graph.

[0223] The second sub-step is to mark the identified obsolete entry points in the system call graph. The system first maps the elements in the obsolete interface set D identified in step S1 to the corresponding nodes in the call graph. This mapping process may need to handle issues such as URL format differences and routing rule conversions to ensure that the controller method or processing function corresponding to the obsolete interface is accurately located. For each successfully mapped obsolete interface, the system marks its corresponding node as an "obsolete entry point" and adds attributes such as obsolete type (interface obsolete) and judgment criteria.

[0224] Next, the system maps the elements in the obsolete component set F identified in step S3 to the corresponding nodes in the call graph. This includes obsolete script files and consumer components, which are often the system's entry points. The mapping process may involve file path resolution, class name matching, and other operations to ensure that the graph node corresponding to the obsolete component is found. For each successfully mapped obsolete component, the system also marks it as an "obsolete entry point" and adds attributes such as obsolete type (script obsolete or consumer obsolete) and judgment criteria.

[0225] For obsolete elements that cannot be directly mapped to existing nodes (e.g., some interfaces may have been removed from the code but still exist in the API documentation), the system may need to create virtual nodes to represent these obsolete entries and add appropriate tags and metadata. This ensures that all identified obsolete entries are represented in the call graph, without omitting any possible sources of obsolete code.

[0226] After marking, the system may perform additional verification, such as cross-checking the inter-call relationships of abandoned entry points or verifying the consistency of the abandoned entry point determination. This helps improve the accuracy of abandoned entry point identification and lays a reliable foundation for subsequent reachability analysis. Ultimately, all entry point nodes in the call graph are clearly divided into two categories: abandoned entry points and non-abandoned entry points (active entry points), preparing for the next step of depth-first search.

[0227] S4.3: Starting from all non-abandoned entry nodes, perform a depth-first search and mark all reachable internal nodes as active nodes.

[0228] The third sub-step marks all active internal nodes in the system through a depth-first search starting from non-deprecated entry points. The system first identifies all entry points in the call graph that are not marked as "deprecated." These nodes represent functional entry points that are still active in the system, such as APIs in use, periodically executed scripts, and active consumer components. These non-deprecated entry points are the starting point for the depth-first search.

[0229] The system starts from each non-deprecated entry node and executes a depth-first search (DFS) algorithm. The search traverses the graph along the call edges, visiting all internal nodes reachable from the starting point. For call edges with conditional attributes, the system may adopt a conservative strategy, assuming the condition might be true and continuing the search along that edge; or it may analyze the conditional constraints, assess the probability of the condition being true, and decide whether to continue along that edge accordingly. For dynamically called edges, the system may determine the search priority or whether to include them in the search scope based on the confidence attribute.

[0230] When a depth-first search reaches a node, the system marks it as an "active node," indicating that the node is reachable from a non-abandoned entry point and may still be playing a role in the system's active functions. To optimize performance, the system may employ memoization techniques to avoid repeatedly visiting marked nodes. For large systems, the search may be performed in a distributed or incremental manner to handle potential memory constraints and performance challenges.

[0231] After the search is complete, all internal nodes in the call graph are divided into two categories: nodes marked as "active nodes," which can be reached from at least one non-deprecated entry point; and unmarked nodes, which cannot be reached from any non-deprecated entry point. The latter category of nodes represents potential cascading deprecated code, but further analysis is needed to confirm whether they are only reachable from deprecated entry points.

[0232] S4.4: Starting from the abandoned entry node, perform a depth-first search and mark all reachable but not marked as active internal nodes.

[0233] The fourth sub-step uses a depth-first search starting from the abandoned entry point to mark internal nodes that are only reachable from the abandoned entry point. The system first collects all nodes in the call graph that have been marked as "abandoned entry points," which represent the abandoned interfaces and components identified in the previous steps. These abandoned entry points are the starting point for a new round of depth-first search.

[0234] The system starts from each abandoned entry point node and executes a depth-first search algorithm. The search process is similar to the previous step, but with one important difference: the system only visits and marks internal nodes that have not yet been marked as "active nodes." This ensures that the search only focuses on code sections that cannot be reached from non-abandoned entry points. For each node that meets the criteria, the system marks it as a "cascading abandoned node" and records which abandoned entry point can reach it, which helps in subsequent abandoned code analysis and cleanup planning.

[0235] During the search process, the system may employ more complex strategies to handle special cases. For example, certain critical system components (such as core library functions and infrastructure code) may require additional verification steps or be marked as special cases requiring manual review, even if they are currently only accessible through obsolete entry points. The system may also pay special attention to nodes called by multiple obsolete entry points, as these may represent shared functional modules, and all callers need to be considered comprehensively during cleanup.

[0236] After the search is complete, all internal nodes in the call graph are divided into three categories: active nodes (reachable from non-deprecated entry points), cascading deprecated nodes (reachable only from deprecated entry points), and isolated nodes (not reachable from any entry point). These three categories of nodes each represent different code states, with cascading deprecated nodes forming a candidate set of cascading deprecated code.

[0237] S4.5: Merge and deduplicate only internal nodes reachable from the obsolete entry point to obtain a cascading obsolete code set.

[0238] The final sub-step is to integrate the analysis results to form the final cascading obsolete code set. The system first collects and merges all the "cascading obsolete nodes" marked in the previous step. These nodes represent code elements such as functions, methods, and classes that are defined in the code but can only be reached from obsolete entry points. The system performs deduplication on these nodes to ensure that each obsolete code element appears only once in the final set, even if it may be reached from multiple obsolete entry points.

[0239] For each cascading abandoned node, the system extracts and integrates its associated metadata, including basic information such as code location, type, complexity, and last modification time, as well as additional information obtained from reachability analysis, such as which abandoned entry points are reachable, call chain depth, and whether it is shared by multiple abandoned entry points. This rich metadata will help in subsequent risk assessment and cleanup priority determination.

[0240] The system may also perform additional analyses, such as identifying dependencies between cascading obsolete code and constructing an internal dependency graph of the obsolete code. This helps in determining a reasonable cleanup order and avoiding dependency loss issues during removal. The system may also evaluate the "isolation" of each obsolete code element, i.e., how isolated it is from active code, which affects the security and complexity of the removal operation.

[0241] Finally, the system integrates all analysis results to generate a cascading obsolete code set G. This set contains all code elements in the system that have been identified as cascading obsolete, each with detailed metadata and related information. This set, together with the obsolete interface set D, the internal useless code set E, and the obsolete component set F identified in the previous steps, constitutes a complete view of the system's redundant code, providing comprehensive data support for the final report generation and cleanup plan development.

[0242] Step S5: Based on the set of obsolete interfaces, the set of internal useless code, the set of obsolete components, and the set of cascaded obsolete code, generate a complete redundant code report containing statistical data, a detailed list, and a risk assessment.

[0243] This step integrates the aforementioned analysis results to generate a complete redundant code report. First, the system summarizes the various types of redundant code identified in the previous steps: obsolete interface set D, internal useless code set E, obsolete component set F, and cascading obsolete code set G. The system categorizes and organizes these identification results according to different dimensions such as interface layer, component layer, function layer, and variable layer, making the report more structured and easier to understand.

[0244] For each identified redundant code entry, the system adds detailed information, including code location, type, and potential risks. Especially for critical system components, the system adds extra verification steps to calculate the potential impact of deleting the component and provides a risk assessment to prevent accidental deletion from causing system failure. The system also assigns a risk score to each redundant code entry, categorizing redundant code into high, medium, and low risk levels based on the risk score. High-risk entries (high probability of misjudgment) are marked as requiring manual review.

[0245] The system provides a manual confirmation mechanism, allowing developers to review the list of redundant code before actual deletion. Developers can view detailed information for each entry and decide whether to retain, delete, or conduct further analysis. The system generates a detailed report containing information on all redundant code, including statistics (such as the quantity and percentage of each type of redundant code), a detailed list, and a risk assessment.

[0246] Finally, the system provides visualization features, such as call relationship diagrams and heatmaps, to help developers intuitively understand the distribution and relationships of redundant code. These visualization tools enable developers to better assess the impact of deleting specific redundant code and develop reasonable code cleanup plans. The system also outputs final redundant code cleanup recommendations, including recommended deletion order and precautions, completing the entire identification and report generation process.

[0247] S5 specifically includes:

[0248] S5.1: Summarize the collection of obsolete interfaces, internal unused code, obsolete components, and cascading obsolete code.

[0249] The first sub-step in the results integration and output is to comprehensively summarize the various redundant codes identified during the preceding analysis. The system first retrieves four key datasets generated in the previous steps from the data storage: a set of obsolete interfaces (D), a set of internal useless code (E), a set of obsolete components (F), and a set of cascaded obsolete code (G). These datasets represent different types of redundant code in the system; they were identified using different analysis techniques and judgment criteria, and therefore have different characteristics and metadata structures.

[0250] The aggregation process begins by standardizing the four datasets to ensure they have a uniform data format and consistent metadata fields. This may involve operations such as field mapping, data transformation, and format normalization. For example, the system might need to standardize fields representing code locations in different sets to a standard format (such as "file path:line number"), or convert timestamps with different representations to a unified date and time format. This standardization process lays the foundation for subsequent merging and analysis.

[0251] Subsequently, the system performs cross-validation and duplicate checking on the four datasets. Because different analysis steps may overlap, the same code element may appear in multiple datasets simultaneously. For example, a function might be judged as both internally useless code (because it has no static calls) and cascading obsolete code (because it can only be reached from obsolete interfaces). The system needs to identify these duplicates and determine how to handle them based on predefined rules. The typical approach is to retain the most specific or stringent judgment result while merging all relevant judgment criteria and metadata.

[0252] Finally, the system assigns a unique identifier to each aggregated redundant code entry and establishes an index structure to support subsequent querying, filtering, and analysis operations. The system may also calculate aggregated statistical data, such as the number of various types of redundant code, their proportion of the total code volume, and their distribution across different modules. This statistical data provides an overview for subsequent report generation. After aggregation, the system possesses a unified and complete view of redundant code, which forms the basis for subsequent classification, organization, and in-depth analysis.

[0253] S5.2: The summarized results are categorized and organized according to preset dimensions, which include the interface layer, component layer, function layer, and variable layer.

[0254] The second sub-step involves categorizing and organizing the aggregated redundant code from multiple dimensions to make the results more structured and organized. The system first classifies redundant code into different technical layers based on the type of code elements. This typically includes: the interface layer (external access points such as API endpoints and web pages), the component layer (functional units such as service classes, controllers, consumers, and scripts), the function layer (execution units such as methods and functions), and the variable layer (data elements such as constants, properties, and local variables). This hierarchical classification reflects the structural hierarchy of the code and helps in understanding the location and scope of influence of redundant code within the system architecture.

[0255] In addition to the technical level, the system may also be classified according to several other dimensions: according to the module or microservice to which it belongs, redundant code can be classified into different business or functional units; according to the reason for obsolescence, redundancy caused by different reasons such as functional refactoring, business changes, and technical upgrades can be distinguished; according to the last modification time, redundant code can be divided into different time periods to reflect the historical process of code aging; according to the risk level, redundant code can be divided into high, medium and low risk levels to facilitate the formulation of cleanup priorities.

[0256] To support flexible analysis and visualization, the system typically implements a multi-dimensional data cube structure, allowing for slicing, drilling down, and rotating operations along different dimensions. For example, analysts can first view all redundant code in a specific module, then focus on the high-risk parts, and finally filter out elements at the interface layer for detailed examination. This multi-dimensional analysis capability greatly improves the flexibility and depth of redundant code analysis.

[0257] The system may also implement intelligent classification capabilities, automatically identifying patterns and clusters of redundant code. For example, by analyzing code naming patterns, file locations, and modification history, the system may identify a group of related obsolete feature codes that may originate from the same canceled product function. This pattern recognition helps to better understand the source and context of redundant code, providing more information for cleanup decisions. After classification and organization, the redundant code is structured into a multi-level, multi-dimensional view, facilitating subsequent detailed analysis and report generation.

[0258] S5.3: Add detailed information for each identified redundant code entry, including code location, type, and target risk.

[0259] The third sub-step involves adding rich details to each identified redundant code entry, providing comprehensive context and evaluation criteria. The system first collects basic information for each redundant code entry, including precise code location (file path, start and end line numbers), code type (class, method, function, variable, etc.), code size (number of lines, number of bytes), and code complexity (loop complexity, nesting depth, etc.). This basic information provides a clear description of the redundant code entity itself.

[0260] Next, the system adds information related to the code's history. This is typically obtained by analyzing the historical records of version control systems (such as Git and SVN), including the code's creation time, last modification time, modification frequency, contributor information, etc. The system may also extract relevant descriptions from commit logs, looking for keywords that may be related to obsolescence (such as "obsolete," "replacement," "temporary," etc.). This historical information helps in understanding the code's lifecycle and the context of its obsolescence.

[0261] The system will also add detailed information related to redundancy assessment, including the criteria for assessment (such as "no call records within 30 days", "reachable only from obsolete interfaces"), the confidence level of the assessment (based on the reliability of the analysis method), and potential risks of misjudgment (such as the uncertainty of dynamic call resolution). For code judged as redundant from multiple perspectives, the system will list all applicable criteria to provide more comprehensive evidence.

[0262] Most importantly, the system assesses and adds information related to the risks of removal. This includes analysis of code dependencies (which code depends on this redundant code, and the state of these dependencies), potential runtime impacts (such as the possibility of reflection calls, configuration-driven dynamic loading, etc.), and system stability risks (such as whether it involves core functionality, exception handling, data consistency, or other critical parts). Based on these risk factors, the system assigns a risk score and risk level to each redundant code entry, providing a reference for cleanup decisions. With the addition of detailed information, each redundant code entry has rich context and evaluation data, enabling developers to make more informed cleanup decisions.

[0263] S5.4: For critical system components, add a component verification step.

[0264] The fourth sub-step involves implementing additional verification steps for critical components in the system to reduce the risk of accidental deletion. The system first identifies which code elements belong to critical system components using predefined rules or configurations. These critical components typically include: core business logic processing classes, exception handling and recovery mechanisms, security-related components (such as authentication and authorization), data consistency assurance mechanisms, distributed coordination components, and system startup and initialization related code. Even if these components are initially determined to be redundant, they require more careful handling, as accidental deletion could lead to serious system failures.

[0265] For redundant code identified as critical components, the system implements a series of additional verification steps. First, a more in-depth static dependency analysis is performed, considering not only direct dependencies but also multiple levels of indirect dependencies to assess the component's connectivity and impact across the entire system. Second, dynamic runtime verification is conducted, which may include temporarily disabling or simulating the removal of the component in a test environment to observe system behavior, or monitoring the component's actual invocation in different scenarios using instrumentation techniques.

[0266] The system may also implement historical data-based validation, analyzing component usage patterns over longer periods (such as a year) to identify potential seasonal or periodic usage patterns. For example, some components may only be used at the end of a fiscal year, during system upgrades, or for specific business events; such cases are easily misjudged as redundant in short-term observations. Another validation method is to examine the component's documentation and comments for explanations of its purpose, importance, or special usage conditions.

[0267] For critical components that remain unidentified, the system will mandate manual review and may contact the component's original author or maintainer for consultation. The verification results will be updated in the component's detailed information, including the verification method, results, and recommended handling. For critical components confirmed as truly redundant, the system may recommend a gradual cleanup strategy, such as marking them as obsolete, monitoring them for a period before deletion, or isolating them instead of deleting them directly. These additional verification and cautious handling strategies significantly reduce the risk of mistakenly deleting critical components.

[0268] S5.5: Display a manual confirmation control, which allows users to review the list of redundant codes before deletion.

[0269] The fifth sub-step is to implement a manual verification mechanism, enabling developers to review the list of redundant code before actual deletion. The system designs and implements an interactive verification interface that allows developers to browse, filter, and evaluate identified redundant code. This interface could be a web-based application integrated into existing development tools, or offered as a standalone desktop tool. Regardless of its form, the verification interface needs to provide an intuitive and efficient interactive experience, supporting developers in making rapid decisions.

[0270] The review interface offers various viewing and filtering options. Developers can filter redundant code by module, risk level, code type, and other dimensions, or search for specific code elements. For each redundant code entry, the interface displays a summary of its key information, such as location, type, risk level, and judgment criteria, and provides ways to quickly access detailed information. Most importantly, the interface allows developers to view the actual content of the redundant code and its context, which is typically achieved through an embedded code viewer or integration with an IDE.

[0271] For each redundant code entry, developers can make three decisions: confirm deletion (marked as verified redundant code that can be safely removed), retain code (marked as a misjudgment and should be retained), or mark as requiring further analysis (when a decision cannot be made immediately). Developers can also add comments explaining their decision rationale or providing additional context; these comments become part of the code cleanup history and help with future code maintenance and auditing.

[0272] The system implements workflow management functions, supporting collaborative team reviews. For large codebases, redundant code reviews typically require multiple participants, possibly divided by module or area of ​​expertise. The workflow function allows for task allocation, progress tracking, coordination of opinions among different reviewers, and multi-level approval (e.g., requiring senior developers or architects to approve the removal of high-risk components). The system also maintains a review history, including the time of each decision, the person making the decision, and the rationale, providing a complete audit trail for the entire cleanup process. Through this manual confirmation mechanism, the system combines the efficiency of automated analysis with the accuracy of human judgment, achieving safer and more reliable redundant code cleanup.

[0273] S5.6: Generates a detailed report containing information on all redundant codes, including statistics, a detailed list, and a risk assessment.

[0274] The sixth sub-step is to generate a detailed report containing information on all redundant code, providing a comprehensive reference for code cleanup decisions and execution. The system first collects and organizes all relevant data, including automated analysis results, manual review decisions, verification results, and additional comments. Based on this data, the system generates a structured report that supports both a high-level overview and in-depth detail viewing.

[0275] The report's statistics section provides an overall picture of redundant code, including the quantity and percentage of each type of redundant code (e.g., the percentage of obsolete interfaces out of all interfaces), the size of redundant code (total lines, percentage of the entire codebase), the distribution of redundant code (by module, by time period, by risk level, etc.), and the statistics on review status (the percentage of confirmed, retained, and pending analysis). These statistics are typically presented in tables and charts, providing intuitive data visualization.

[0276] The detailed list section of the report provides complete information on each redundant code entry. This typically uses a hierarchical structure, first grouping by module or type, then listing the specific entries within each group. For each entry, the report displays its basic information, the basis for the judgment, risk assessment, review status and decision, relevant comments, etc. The report also provides navigation and referencing features, allowing quick jumps between related entries, such as jumping from a deprecated interface to cascading deprecated code that was only called by it.

[0277] The risk assessment section of the report focuses on the potential risks and impacts of the cleanup operation. This includes a centralized presentation of high-risk items, analysis of potential system impacts, recommendations for possible rollback strategies, and suggested testing priorities. For large-scale cleanup operations, the report may also include a phased cleanup plan, dividing redundant code into multiple batches based on risk and dependencies, and recommending a gradual cleanup approach.

[0278] Finally, the report includes an execution guideline section, providing specific recommendations for cleanup implementation. This includes the recommended deletion order, considerations for handling specific code segments, key functionalities requiring post-cleanup testing, and security measures to be taken before cleanup (such as code backups and rollback plans). The report can be exported in various formats, such as PDF, HTML, or formats integrated with project management tools, facilitating use and sharing in different scenarios. These detailed and comprehensive reports provide a solid foundation for redundant code cleanup, helping teams make informed decisions and perform cleanup operations safely.

[0279] S5.7: Provides target visualization content, including calling relationship diagrams and heatmaps.

[0280] The final sub-step involves providing rich visualization capabilities to help developers intuitively understand the distribution and relationships of redundant code. The system implements various types of visualizations, each focusing on revealing different aspects of redundant code, providing intuitive support for analysis and decision-making. These visualizations are typically interactive, allowing users to zoom, filter, and drill down to explore different levels and perspectives of the data.

[0281] Call graphs are one of the most basic forms of visualization, showing the call dependencies between system components. In this graph, nodes represent code elements (such as functions, classes, etc.), and edges represent call relationships. The system uses different colors to mark active code, obsolete interfaces, and cascading obsolete code, making them visually easy to distinguish. Users can select a specific node to view all its incoming and outgoing edges, understanding the component's dependencies. For large systems, the graph may support clustering and unfolding operations, allowing users to progressively expand from a high-level module view to a detailed component view.

[0282] Heatmaps are another powerful form of visualization that uses color intensity to represent the density of redundant code in different areas. Heatmaps can be applied to various views, such as codebase structure diagrams (showing which directories or files contain a large amount of redundant code), module dependency diagrams (showing which dependencies between modules contain redundant calls), or timeline views (showing the accumulation of redundant code over time). Heatmaps provide a macroscopic view of the distribution of redundant code, helping teams identify areas that require focused attention.

[0283] The system may also provide specialized cascading effect visualizations, showing the chain reactions that may result from deleting specific redundant code. This visualization typically uses a tree or graph structure, with the target element to be deleted as the root node, displaying all potentially affected dependent components. The color or label of the node indicates the component's status (confirmed redundancy, pending verification, active, etc.), helping to assess the safety boundaries of the deletion operation.

[0284] In team collaboration scenarios, the system can visualize responsibility areas, displaying redundancy in the code areas managed by different teams or developers. This facilitates task allocation and progress tracking, ensuring that redundant code cleanup is evenly distributed and fully covered.

[0285] All these visualizations support interactive operations, such as clicking to view details, dragging and rearranging, zooming and focusing. The system also supports exporting and sharing visualization results for easy use in team meetings or documents. Through these intuitive and information-rich visualizations, developers can better understand the overall picture and details of redundant code, make more informed cleanup decisions, and effectively plan and execute cleanup work.

[0286] In another embodiment of the present invention, the step of generating a complete redundant code report includes a misjudgment risk assessment and optimization based on saddle point approximation, specifically including:

[0287] S5.8: Obtain the identified redundant code entries, construct a feature vector for each identified redundant code entry that includes code complexity, last modification time, and call path depth, and standardize the feature vectors to a uniform numerical range.

[0288] In the first sub-step of the advanced risk assessment and optimization strategy, the system performs in-depth characterization of each identified redundant code entry, constructing a standardized feature vector. This process first retrieves all identified redundant code entries from the database, including obsolete interfaces, internal unused code, obsolete components, and cascading obsolete code identified in the preceding steps. For each entry, the system collects a series of key metrics that characterize the code's properties and context from multiple dimensions.

[0289] The system first calculates code complexity metrics, including cyclomatic complexity (measuring the number and nesting depth of conditional branches), cognitive complexity (assessing the difficulty of understanding the code), lines of code (code size), and bytes. For functions and methods, the system also calculates more granular metrics such as the number of parameters, the number of return statements, and nesting levels. These complexity metrics reflect the internal structural characteristics of the code and are closely related to the difficulty of code maintenance and potential error risks. Higher-complexity code, if mistakenly identified as redundant and deleted, could have a greater impact on the system.

[0290] Next, the system analyzes the time characteristics of the code, extracting time-dimensional indicators such as last modification time, creation time, and commit history frequency. The system calculates the code's "age" (time since creation) and "stable period" (time since last modification), these time characteristics help determine the code's lifecycle stage. Generally, code that hasn't been modified for a long time is more likely to be truly obsolete, but it may also be core stable functionality; while frequently modified code is more likely to be mistakenly identified as redundant. The system also analyzes modification patterns, identifying code that is seasonally or periodically modified, which may indicate that the code supports periodic business needs.

[0291] The system also analyzes the call context of the code, extracting topological features such as call path depth (the length of the call chain from the entry point to the code), number of callers, and number of calls made. The system pays particular attention to the "centrality" of code in the call graph, assessing the code's importance in the system's functional flow. Code with high centrality often acts as a bridge connecting different functional modules, and may play a crucial role in the system even if its current call frequency is low. The system also evaluates the "distance" of code from core functions, i.e., the shortest path length from the entry point of a critical function to the code, reflecting the degree of correlation between the code and the system's core functions.

[0292] Finally, the system calculates features related to redundancy judgment itself, such as the diversity of judgment criteria (based on the number of different judgment methods), confidence score (the overall confidence of each judgment method), and anomaly indicators (uniqueness compared to similar code). The system also collects feedback data accumulated during the aforementioned manual review process, such as the frequency with which similar code is marked as a misjudgment.

[0293] All these features are organized into a unified feature vector. However, due to the significant differences in the original numerical ranges of the features, the system applies standardization to transform all features to a uniform numerical range (typically [0,1] or [-1,1]). Standardization methods include min-max normalization, Z-score standardization, or nonlinear transformations (such as logarithmic transformation). The choice of method depends on the distribution characteristics of the features and domain knowledge. The standardized feature vector provides a unified mathematical representation for subsequent model training and risk assessment, forming the basis for accurate risk quantification.

[0294] S5.9: Construct a discrimination model based on historical data, train the model using the saddle point approximation method, and evaluate the misclassification probability of each redundant code entry based on the trained model.

[0295] The second sub-step primarily involves building and training a discrimination model to assess the false positive probability of each redundant code entry. The system first collects training samples from historical data, which fall into two categories: confirmed truly redundant code (positive samples) and code that was previously misidentified as redundant but is still in use (negative samples). These samples are collected from various sources, including records of past code cleanup projects, manual reviews by the development team, rollback history (indicating that deletion operations caused problems), or specially constructed benchmark sets.

[0296] Based on the collected samples, the system constructs a discriminative model suitable for binary classification tasks. Considering the potentially limited number of samples and the complexity of the feature space, the system selects a model architecture with good generalization ability, such as Support Vector Machine (SVM), Random Forest, or Deep Neural Network. To handle the complex nonlinear relationships that may exist between features, the system may employ kernel methods (such as radial basis function kernels) or attention mechanisms from deep learning to capture higher-order interactions between features.

[0297] During model training, the system applies the saddle point approximation method to optimize model parameters. Saddle point approximation is a mathematical technique particularly suitable for optimization problems with complex constraints, capable of finding near-global optimal solutions with limited computational resources. In this application, saddle point approximation helps the system find a balance between minimizing the false positive rate (reducing the misclassification of actually useful code as redundant) and maximizing the detection rate (ensuring that truly redundant code is correctly identified).

[0298] In its implementation, the system defines a Lagrangian function that combines the primal optimization objective with various constraints (such as tolerance thresholds for different types of errors). By iteratively updating the primal variables (model parameters) and dual variables (constraint-related multipliers), the system gradually approaches a saddle point solution. In each iteration, the system updates the parameters using mini-batch stochastic gradient descent or a second-order optimization method and checks the convergence condition. To avoid local optima, the system may employ multi-starting-point strategies or simulated annealing techniques.

[0299] The trained discriminant model can receive feature vectors of redundant code entries and output an estimate of the probability that an entry is misclassified as redundant. The system performs a comprehensive evaluation of the model, using cross-validation to calculate performance metrics such as accuracy, precision, recall, and F1 score. Crucially, the system analyzes the distribution of different error types to ensure the model maintains good performance across various code types and scenarios.

[0300] Finally, the system applies the trained model to all identified redundant code entries, calculating the false positive probability for each entry. These probability estimates reflect the system's "confidence" in its judgment, providing crucial input for subsequent risk assessment. Entries with high false positive probabilities require additional manual review, while entries with low false positive probabilities can be more confidently identified as genuine redundant code.

[0301] S5.10: Calculate the negative moment of the false positive probability distribution, optimize the parameters of the redundant code recognition algorithm by minimizing the negative moment, and determine the edge cases of high-risk false positives based on the optimized parameters.

[0302] The third sub-step applies advanced mathematical and statistical methods to deeply analyze the misjudgment probability distribution and improves the system's judgment reliability through negative moment optimization techniques. The system first collects the misjudgment probabilities of all redundant code entries calculated in the previous step, constructing an empirical distribution of the misjudgment probabilities. This distribution reflects the system's confidence in judging different code entries and forms the basis of risk assessment.

[0303] The system calculates the statistical moments of the misclassification probability distribution, paying particular attention to higher-order negative moments. Mathematically, the k-th moment of a distribution is the expected value of the k-th power of a random variable, while a negative moment is a moment with a negative exponent. Negative moments are particularly sensitive to the tails of the distribution (low-probability regions), making them a powerful tool for analyzing the risk of rare events. In this application, the system calculates negative moments of order -1 and -2, etc. These indicators give higher weight to code entries with lower misclassification probabilities, helping to identify situations where the overall misclassification probability is low but the tail risk is significant.

[0304] Based on the calculated negative moments, the system constructs an optimization problem to minimize a specific negative moment (or a weighted combination of negative moments) of the misclassification probability distribution. This optimization involves adjusting the parameters of the redundant code recognition algorithm, such as the judgment threshold, feature weights, or model hyperparameters. The optimization problem can be formalized as: finding a parameter vector θ such that the negative moment index M of the misclassification probability distribution P(θ) is minimized. - (P(θ)) is minimized.

[0305] Solving this optimization problem requires advanced numerical methods because the response of negative moments to parameter variations can be nonlinear and non-smooth. The system may employ techniques such as variants of gradient descent (e.g., Adam or RMSProp), evolutionary algorithms, or Bayesian optimization to search for the optimal solution in the parameter space. To improve efficiency, the system may use surrogate models or sensitivity analysis to reduce the number of parameter combinations that need to be evaluated.

[0306] The optimization process pays particular attention to identifying high-risk edge cases, which, although low in probability, could have serious consequences if they occur. For example, the system might identify specific types of code patterns (such as indirect calls, reflection usage, or domain-specific logic) that have frequently appeared in past misjudgments and adjust the identification algorithm accordingly. The system may also find that certain combinations of features are particularly prone to misjudgments; for example, the combination of "unmodified for a long time" and "high complexity" might indicate that the code is a core, stable function rather than genuine redundancy.

[0307] After negative moment optimization, the system obtains adjusted algorithm parameters that improve its performance in handling edge cases and rare risks. The system recalculates the misclassification probability of all redundant code entries, generating optimized risk assessment results. These results not only reflect the likelihood of each entry being misclassified but also highlight cases that, while appearing unlikely overall, may actually present underestimated risks.

[0308] S5.11: Assign a risk score to each redundant code entry, and classify each redundant code entry into a risk category based on the risk score. The risk categories include high risk, medium risk, and low risk. Redundant code entries belonging to the high-risk category are marked as entries to be manually reviewed.

[0309] The fourth sub-step, based on the aforementioned analysis results, assigns a comprehensive risk score to each redundant code entry and categorizes the risks accordingly. The system first constructs a risk scoring model that comprehensively considers multiple risk factors, including but not limited to: the probability of misjudgment (derived from the discriminant model), code complexity (reflecting the potential scope of impact), the system's core nature (its relevance to key functions), and code recoverability (the difficulty of rebuilding after deletion).

[0310] Risk scoring employs a weighted summation or more complex nonlinear model to integrate various risk factors into a single risk score. Weight allocation is based on domain expert knowledge and historical data analysis, reflecting the relative importance of different factors in the overall risk. For example, the system may assign a higher weight to a higher probability of misjudgment, while simultaneously considering that even code with high complexity or tightly integrated with the core system should be considered high-risk, even if the probability of misjudgment is low.

[0311] The calculated risk scores are typically normalized to a uniform range (e.g., 0-100) for ease of understanding and comparison. Based on the score distribution and predefined thresholds, the system categorizes all redundant code entries into three main risk categories: high risk, medium risk, and low risk. This classification provides clear prioritization guidance for subsequent review and cleanup decisions.

[0312] The high-risk category includes entries whose risk scores exceed a specific threshold (e.g., 75 points). These entries typically possess one or more of the following characteristics: high probability of false positives, high code complexity, tight integration with core system functions, difficulty in recovery after deletion, or special business sensitivity. The system automatically marks all high-risk entries as "awaiting manual review," ensuring they undergo detailed examination by experts before actual deletion. Furthermore, the system may generate specific review guidelines for high-risk entries, suggesting which aspects and potential risk points reviewers should focus on.

[0313] The medium-risk category includes entries with scores in the middle range (e.g., 40-75 points). These entries may not be high enough to require manual review, but they are not low enough to warrant direct deletion. The system may suggest a phased cleanup strategy for these entries, first verifying the impact of deletion in a test environment, or implementing temporary blocking instead of direct deletion.

[0314] The low-risk category includes entries with lower scores (e.g., below 40 points). These entries typically have a lower probability of false positives, lower complexity, and smaller system impact. The system may suggest that these entries can be directly included in the automated cleanup process, but a basic rollback mechanism should still be retained.

[0315] In addition to the main risk categories, the system may also apply more granular labels to highlight specific risk characteristics, such as "document dependency risk" (which may be referenced in a document or comment), "reflection call risk" (which may be invoked via reflection), or "seasonal use risk" (which may be used during a specific period). These labels provide additional context for human review, helping to make more accurate decisions.

[0316] S5.12: Construct an objective function based on system size and code characteristics, use the saddle point method to find the optimal equilibrium point, and use the threshold parameter corresponding to the optimal equilibrium point as the adjusted threshold parameter.

[0317] This sub-step applies the saddle point optimization method to find the globally optimal balance point for the system's decision parameters, ensuring an optimal balance between the accuracy and efficiency of redundant code identification. The system first defines an objective function related to code cleanup, which comprehensively considers multiple competing objectives: reducing redundant code (improving code quality and maintenance efficiency), reducing the risk of accidental deletion (avoiding functional loss and system failure), and minimizing the cost of manual review (improving overall efficiency).

[0318] The specific form of the objective function depends on the system size and code characteristics, and typically includes multiple weighted components: redundancy code identification rate (to be maximized), false positive rate (to be minimized), and manual review workload (to be minimized). There are inherent trade-offs among these components; for example, increasing the identification rate usually increases the risk of false positives, while reducing the risk of false positives usually requires increasing the workload of manual review. The objective function may take the form of a linear weighted function or a more complex non-linear form, reflecting the relative importance and interaction between different objectives.

[0319] The saddle point method is particularly well-suited for solving multi-objective optimization problems because it can find stable equilibrium solutions even with constraints and multiple competing objectives. The system first transforms the original optimization problem into finding a saddle point for a specific Lagrangian function: maximizing the dual variable (constraint-related) and minimizing the original variable (system parameters). Mathematically, this is equivalent to solving a minimax problem: min_θ max_λ L(θ, λ), where θ are the system parameters, λ are the Lagrange multipliers, and L is the Lagrangian function.

[0320] The system employs an iterative algorithm to solve this saddle point problem. In each iteration, the system first fixes the current values ​​of the dual variables and optimizes the primal variables (typically using gradient descent or a second-order method); then, it fixes the updated values ​​of the primal variables and optimizes the dual variables (typically using gradient ascent). This alternating optimization process continuously adjusts the system parameters and constraint weights, gradually approaching the saddle point solution. To ensure global convergence, the system may implement a multi-starting-point strategy, optimizing from different initial points and selecting the optimal result.

[0321] The optimization process pays particular attention to the system's key threshold parameters, which directly affect the decision boundaries for code classification and risk assessment. Key thresholds include: a usage frequency threshold for classifying code as "potentially redundant," a score threshold for distinguishing risk categories, and a false positive probability threshold for determining whether manual review is required. The system finds the optimal balance point by simulating the impact of different threshold combinations on the overall objective function.

[0322] The optimal threshold parameters obtained from the solution are adjusted according to the specific circumstances of the system. For example, for core systems with high availability requirements, the system may adjust the threshold to be more conservative, classifying more code entries as requiring manual review; while for non-critical systems that iterate rapidly, the threshold may be more aggressive, allowing for more automated cleanup. The system may also set differentiated thresholds for different modules or code regions to reflect their different characteristics and risk tolerance.

[0323] Finally, the system applies the adjusted optimal threshold parameters to reassess the classification and risk level of all redundant code entries. This saddle-point optimization-based parameter adjustment ensures that the system achieves an optimal balance between accuracy, security, and efficiency in redundant code identification, providing a solid mathematical foundation for subsequent code cleanup work.

[0324] In another embodiment of the present invention, a routing-gated cross-modal feature fusion analysis step is added between step S3 and step S4, specifically including:

[0325] S3.4: For each code entity, extract structural features from static analysis, behavioral features from dynamic analysis, evolutionary features from code repository history, and semantic features from code documentation to construct multimodal features corresponding to each code entity. Specifically, this includes: analyzing the call relationships, inheritance hierarchy, and module dependencies of each code entity to extract structural features reflecting the complexity and coupling of the code structure; analyzing runtime call frequency, execution path distribution, and resource consumption patterns to extract behavioral features reflecting the code's runtime behavior; statistically analyzing the modification frequency, number of commit authors, and version span of the code entity, combined with code change scale and stability indicators, to extract evolutionary features reflecting the code lifecycle; parsing code comments, function names, and docstrings, using natural language processing techniques to extract keywords and semantic tags to construct semantic features reflecting the code's functional intent; and standardizing the structural, behavioral, evolutionary, and semantic features, and constructing multimodal features corresponding to each code entity through a weighted fusion mechanism.

[0326] In the first meticulous step of multi-dimensional data analysis and code status assessment, the system implements a comprehensive multi-modal feature construction process, extracting and integrating code features from four different dimensions. This multi-modal approach overcomes the limitations of single-dimensional analysis, capturing a complete profile of the code from different perspectives and laying a solid foundation for subsequent activity assessment. The system constructs independent feature sets for each code entity (function, method, class, etc.) identified in the previous steps, ensuring the accuracy and relevance of the analysis.

[0327] First, the system extracts structural features from static analysis, reflecting the organization and complexity of the code. The system analyzes the call relationships of code entities, calculating in-degree (number of calls) and out-degree (number of calls to other components), identifying call hierarchy and dependency depth. For object-oriented code, the system also analyzes inheritance hierarchy, recording metrics such as class inheritance depth, number of subclasses, and percentage of overridden methods. At the module level, the system calculates dependencies between modules, constructs dependency graphs, and extracts relevant metrics such as module coupling, cohesion, and stability. These structural features collectively describe the architectural characteristics of the code; highly coupled components or those on the critical path typically have higher importance.

[0328] Secondly, the system integrates dynamic analysis data to extract behavioral characteristics that reflect the code's usage patterns in the actual operating environment. The system analyzes call frequency data collected by APM tools, calculates the call distribution of code entities across different time periods, environments, and user scenarios, and identifies usage peaks and patterns. The system also analyzes execution path distribution, recording the occurrence of code entities in various program execution paths and identifying critical and rare paths. Regarding resource consumption, the system collects performance metrics such as CPU time, memory usage, and I / O operations to evaluate the resource efficiency and performance characteristics of code entities. These behavioral characteristics directly reflect the actual usage of the code; components that are frequently called and located on critical paths typically indicate higher activity.

[0329] Third, the system extracts evolutionary features from the code repository history, revealing patterns and lifecycle characteristics of code changes over time. The system analyzes the commit history of the version control system, calculating the modification frequency of code entities (number of changes within a specific time window), the most recent modification time, and the first introduction time. The system also tracks the number and distribution of developers involved in the modifications, assessing the degree of "collective knowledge" and maintenance patterns of the code. By analyzing the scale and type of code changes (such as feature additions, bug fixes, refactoring, etc.), the system evaluates the stability and maturity of the code. The system pays particular attention to time patterns, such as periodic modifications or sudden changes after long-term stability, which may indicate specific business cycles or technology migrations. These evolutionary features help identify the lifecycle stages of the code; long-term stable code with few modifications may be mature core components or forgotten legacy code.

[0330] Finally, the system extracts semantic features from the code documentation, capturing the functional intent and business semantics of the code. The system parses code comments, function names, and API documentation, applying natural language processing techniques to extract keywords and topics. Through term frequency-inverse document frequency (TF-IDF) analysis or more advanced language models (such as BERT, CodeBERT, etc.), the system generates semantic vector representations of the code. The system also identifies specific semantic tags, such as "obsolete," "temporary," and "TODO" comment labels, which directly indicate the expected lifecycle of the code. For code with external documentation, the system also analyzes document citations to assess the code's documentation coverage and maintenance status. These semantic features provide context for the code's functionality and intent, helping to distinguish between core business logic and auxiliary functions.

[0331] After extracting these four types of features, the system performs standardization to ensure that features of different dimensions and scales can be effectively compared and integrated. The system applies standard score transformation or min-max normalization to numerical features, mapping all features to a unified range (e.g., [0,1]). For categorical features, the system uses one-hot encoding or entity embedding techniques to convert them into numerical representations. Finally, the system integrates features from different dimensions through a weighted fusion mechanism to construct a unified multimodal feature representation. Weight allocation can be based on domain knowledge pre-sets or automatically optimized through machine learning techniques to ensure that the most important features have appropriate influence in the final representation. This multimodal feature construction method provides a comprehensive profile of code entities, offering a rich information foundation for subsequent activity assessment and code state judgment.

[0332] S3.5: Convert the multimodal features corresponding to each code entity into a unified vector representation of that code entity. Construct a global multidimensional feature matrix based on the unified vector representation of all code entities. Perform dimensionality reduction processing on the global multidimensional feature matrix to output a simplified feature representation. Input the simplified feature representation into a gating function to filter low-confidence features. Then, assign weights to the remaining filtered features through an attention mechanism. Based on the weighted features, dynamically route them to the corresponding analysis branches through a routing network. Then, resolve conflicts in the output results of each analysis branch to generate a comprehensive feature representation. Finally, generate an activity score for each code entity based on the comprehensive feature representation.

[0333] The second sophisticated step involves converting multimodal features into a unified code activity score. This process involves complex feature fusion, dimensionality reduction, and neural network inference. The system first further processes the multimodal features of each code entity, converting the features across four dimensions—structure, behavior, evolution, and semantics—into a unified vector representation. This conversion may employ techniques such as deep neural network encoders, autoencoders, or variational autoencoders to map heterogeneous features of different dimensions to a latent space of the same dimension, ensuring that semantically similar code entities are close together in this space.

[0334] Once all code entities are converted to a unified vector representation, the system combines them into a global multidimensional feature matrix. Each row of this matrix represents a code entity, and each column represents a feature dimension, fully capturing the feature distribution of the entire codebase. Because the original feature space has high dimensionality and may contain redundancy, the system applies dimensionality reduction techniques to reduce the number of features while retaining key information. Common dimensionality reduction methods include Principal Component Analysis (PCA), t-distributed random neighborhood embedding (t-SNE), or autoencoders, which can significantly reduce dimensionality while preserving data structure. The dimensionality-reduced feature representation is more compact, reducing the computational complexity of subsequent analysis and mitigating the risk of overfitting.

[0335] The dimensionality-reduced features undergo initial screening using a gating function to filter out features with low confidence or limited information. Gating functions are typically designed based on feature variance, entropy, or importance scores, allowing only features that significantly contribute to distinguishing code activity. This step effectively reduces the impact of noise and irrelevant features, improving the robustness of subsequent analysis. The passing features are then processed by an attention mechanism, which dynamically assigns weights to highlight the most important features in the current context. Attention weights may be calculated based on the feature's global importance, relevance to a specific code entity, or interaction with other features, ensuring that the most relevant features play a greater role in the final decision.

[0336] Features with attention weights are then fed into a routing network, which dynamically assigns them to different specialized analysis branches based on their nature. For example, structurally relevant features might be routed to an architecture analysis branch, behavioral features to a usage pattern analysis branch, evolutionary features to a lifecycle analysis branch, and semantic features to a functional intent analysis branch. Each analysis branch is a specially designed neural network submodule optimized for a specific type of feature, enabling the extraction of deeper patterns and relationships. This specialized design significantly improves the accuracy and interpretability of the analysis.

[0337] The outputs of different analysis branches may conflict or be inconsistent; for example, structural analysis might indicate that code is a core component, while pattern analysis shows it is rarely invoked. The system implements a conflict resolution mechanism, integrating the results from different branches through weighted averaging, voting, or more complex ensemble learning methods. Conflict resolution considers the confidence level, historical accuracy, and relevance of each branch to the current context, generating a final comprehensive feature representation. This representation integrates information from all dimensions, describing the state of the code entity in a consistent and comprehensive manner.

[0338] Finally, the system calculates an activity score for each code entity based on a comprehensive feature representation. This score reflects the code's usage status and importance within the current system and is the core basis for subsequent redundant code assessment. The score calculation may employ linear models, decision trees, or neural networks, mapping features to standardized score intervals of [0,1] or [0,100]. The system may also generate confidence intervals or probability distributions for the scores, reflecting the uncertainty of the assessment. Activity scores are typically provided along with interpretive metrics, indicating which factors primarily contribute to the score results, significantly improving the interpretability and operability of the analysis results. Through this complex feature fusion and reasoning process, the system can comprehensively consider all relevant aspects of the code to generate accurate and meaningful activity assessments.

[0339] S3.6: Identify and filter common code noise patterns, apply adaptive thresholds to adjust the judgment criteria for different noise levels, and generate a confidence score for each code entity.

[0340] The third meticulous step primarily involves identifying and processing various noises during the analysis process to ensure the reliability of the final judgment. In complex software systems, various factors can lead to misleading signals about code usage patterns, such as testing activities, batch processing jobs, and monitoring probes. These "noises" can interfere with the actual assessment of code activity and require specialized processing mechanisms. The system first constructs a comprehensive noise pattern library, containing common code noise types and their characteristic signatures.

[0341] The system identifies and filters several common code noise patterns. Test-driven calls are one of the most prevalent sources of noise; automated tests may frequently call certain code, making it appear very active in dynamic analysis, even though it is rarely used in production environments. The system distinguishes between test calls and real business calls by analyzing call stack context, execution environment identifiers, and call timing patterns. The system also identifies debugging and logging-related code, which is frequently used during development and troubleshooting but does not represent core business functionality. Based on code pattern recognition and context analysis, the system appropriately adjusts the activity level of this type of auxiliary code.

[0342] Batch processing and scheduled tasks are another significant source of noise, potentially causing certain code to be called periodically at high frequencies while remaining completely inactive at other times. The system analyzes the temporal distribution patterns of these calls, identifies calls with clear periodicity, and assesses their importance based on the business calendar and system runtime cycle. The system also pays special attention to monitoring and health check-related code, which may be called automatically and frequently but is typically not core business logic. By identifying typical monitoring patterns and call contexts, the system appropriately reduces the apparent activity of this type of code.

[0343] Exception handling paths are another area requiring special attention. Error handling code may be executed infrequently, but this doesn't mean it's redundant—on the contrary, it can be a critical component of system robustness. The system identifies exception handling-related code paths and assesses their activity based on their functional importance rather than execution frequency. The system also considers special parts of the codebase, such as experimental features, backup systems, or disaster recovery components, which may be used infrequently but are of strategic importance. Through domain knowledge and code comment analysis, the system applies customized evaluation rules to these special components.

[0344] While handling various types of noise, the system employs adaptive thresholding technology to dynamically adjust the judgment criteria based on the noise levels of different code regions. For regions with high noise (such as modules with extensive testing or monitoring activities), the system raises the activity judgment threshold, requiring stronger evidence to confirm that the code is active; while for regions with low noise, the system may adopt a more lenient standard. This adaptive approach ensures consistency and fairness in judgments under different noise environments.

[0345] The system ultimately generates a confidence score for each code entity, reflecting the reliability of the activity assessment. The confidence score considers multiple factors: data coverage (the completeness and representativeness of the data used for analysis), noise level (the number and intensity of identified noise patterns), feature consistency (the degree of consistency across different feature dimensions), and historical stability (the degree to which the assessment result changes over time). The confidence score uses a [0,1] or percentage scale to intuitively represent the system's confidence in its judgment. For judgments with low confidence, the system may mark them as "requiring further verification," prompting manual review or additional data collection. Through this noise processing and confidence assessment mechanism, the system can significantly improve the accuracy and reliability of code activity assessment and reduce the risk of misjudgments.

[0346] S3.7: Generate a comprehensive code usage status report based on activity score and confidence score, after noise filtering and cross-modal fusion.

[0347] In step S4, based on the set of obsolete interfaces, the set of internal useless code, the set of obsolete components, and the comprehensive code usage status report, a system call graph is constructed to perform reverse reachability analysis and identify the cascading obsolete code set.

[0348] The final, meticulous step, based on the aforementioned analysis results, generates a comprehensive and actionable code usage status report. This report integrates activity scores, confidence scores, and various contextual information, providing a complete view for codebase management. At the heart of the report is the final status assessment of each code entity, based on a combined consideration of activity and confidence scores. Status assessments are typically categorized into several types, such as "Highly Active," "Moderately Active," "Lowly Active," "Possibly Redundant," and "Highly Likely Redundant," providing clear guidance for subsequent decision-making.

[0349] For each code entity, the report provides a detailed activity analysis, including an activity score, historical trends in the score, key contributing factors, and a benchmark. This analysis uses intuitive charts and metrics to help users understand code usage patterns and importance. For example, the report might show the call frequency changes of a function over the past six months and compare it to the average of similar functions, highlighting unusual patterns or trend changes. The report also provides confidence analysis, including a confidence score, key factors influencing confidence, and data quality assessment. This analysis helps users understand the reliability of judgments and potential sources of uncertainty. For example, the report might indicate that a judgment has low confidence because of incomplete dynamic tracking data or because the code has recently undergone a major refactoring.

[0350] The report pays particular attention to potentially redundant code, providing a detailed analysis for each entity identified as "potentially redundant" or "highly likely redundant." This includes evidence of unused code (such as long periods without call history), potential risks of false positives (such as the presence of hard-to-detect dynamic calls), and recommended handling strategies (such as direct deletion, marking as obsolete, or further verification). For each potential redundancy, the report also provides contextual information, such as the code's creation time, last modifier, related modules, and potential dependencies, to help assess the feasibility and impact of deletion.

[0351] To support a holistic analysis perspective, the report offers various aggregated views, such as redundant code distribution by module, code activity changes over time, and division by development team responsibility areas. These views help identify hotspots and patterns in the system, such as an unusual concentration of redundant code in a specific module or a significant drop in code activity after a certain period. The report also provides interactive exploration features, allowing users to filter and drill down into data along different dimensions, such as focusing on specific time periods, specific types of code, or judgments within specific confidence ranges.

[0352] Finally, the report includes actionable recommendations and next steps. For confirmed redundant code, the report provides an organized cleanup plan, considering code dependencies, risk levels, and business impact. For code with low activity but uncertain redundancy, the report may recommend additional monitoring or testing strategies. For judgments with low confidence, the report recommends specific verification steps, such as code review, functional testing, or more in-depth dependency analysis.

[0353] The reports are provided in multiple formats, including interactive dashboards, static PDF documents, and machine-readable data exports, to meet the needs of different users and use cases. Reports are updated regularly (e.g., weekly or monthly) to reflect ongoing changes to the codebase and newly collected data, ensuring decisions are based on the latest analysis results. Through this comprehensive and actionable reporting, the system not only provides detailed analysis of code status but also offers concrete action guidelines for codebase optimization and redundant code cleanup, significantly improving the efficiency and accuracy of the entire process.

[0354] The present invention also provides a redundant code identification device based on a data flow graph, comprising:

[0355] The obsolete interface identification module is used to identify the set of obsolete interfaces based on interface access logs, full site scan results, and code repository information through set operations.

[0356] The useless code identification module is used to perform dynamic call detection and data flow analysis based on static analysis tools and abstract syntax trees to identify the internal useless code set;

[0357] The obsolete component formation module is used to perform status checks and log analysis based on consumer running status, script execution records, and task scheduling configuration, identify obsolete script sets and obsolete consumer sets, and merge obsolete consumer sets and obsolete script sets to form obsolete component sets;

[0358] The cascading obsolete code identification module is used to construct a full system call graph based on obsolete interface sets, internal useless code sets, and obsolete component sets to perform reverse reachability analysis and identify cascading obsolete code sets.

[0359] The redundancy report generation module is used to generate a complete redundancy code report containing statistical data, a detailed list, and a risk assessment based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the set of cascaded obsolete code.

[0360] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0361] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for identifying redundant code based on data flow graphs, characterized in that, include: Obtain API access logs, full site scan results, and code repository information; process these data through set operations to identify a set of obsolete APIs. Based on static analysis tools and abstract syntax trees, dynamic call detection and data flow analysis are performed to identify sets of useless internal code. Based on the consumer's running status, script execution records, and task scheduling configuration, status checks and log analysis are performed to identify the abandoned script set and the abandoned consumer set, and the abandoned consumer set and the abandoned script set are merged to form the abandoned component set; Based on the set of obsolete interfaces, the set of internal useless code, and the set of obsolete components, a full system call graph is constructed for reverse reachability analysis to identify the cascading obsolete code set. This includes: constructing a full system call graph containing interfaces, functions, and classes based on the updated call relationship graph, where nodes are divided into entry nodes and internal nodes; marking elements in the set of obsolete interfaces and the set of obsolete components as obsolete entry points in the full system call graph; performing a depth-first search from all non-obsolete entry nodes to mark all reachable internal nodes as active nodes; performing a depth-first search from the obsolete entry nodes to mark all reachable but not marked as active internal nodes; and merging and deduplicating internal nodes reachable only from the obsolete entry points to obtain the cascading obsolete code set. Based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the set of cascaded obsolete code, a complete redundant code report containing statistical data, a detailed list, and a risk assessment is generated.

2. The method according to claim 1, characterized in that, The process of obtaining interface access logs, site-wide scan results, and code repository information, through set operations, identifies a set of obsolete interfaces, including: Based on the interface access logs, extract the URLs of the interfaces that have been called and the number of times they have been called, and generate an active interface set based on the URLs of the interfaces that have been called and the number of times they have been called; Based on the full site scan results, extract the target visible interface URLs from all externally exposed pages, and generate a set of visible interfaces based on the target visible interface URLs; Based on the code repository information, the public methods, routing configuration files, and API annotations in the controller class are analyzed, and a theoretical interface set is generated based on the analysis results. Perform a union operation on the active interface set and the visible interface set to obtain the used interface set; The discarded interface set is obtained by performing a difference operation on the theoretical interface set and the used interface set.

3. The method according to claim 1, characterized in that, The method, based on static analysis tools and abstract syntax trees, performs dynamic call detection and data flow analysis to identify a set of internally useless code, including: Based on the static analysis tool, predefined detection rules are set to scan unused methods, classes, and variables, generating a preliminary set of useless code. Based on the abstract syntax tree, dynamic call patterns are identified, and the identified dynamic call points are marked as target nodes to be analyzed. A preliminary call relationship graph is then constructed based on the target nodes. For the target node, a def-use analysis is performed to construct a data flow graph with variable definitions and usages as nodes and data dependencies as directed edges; Based on the data flow graph, the initial call relationship graph is updated, and based on the updated call relationship graph, the initial set of useless code is corrected to obtain the internal set of useless code.

4. The method according to claim 1, characterized in that, Based on consumer running status, script execution records, and task scheduling configuration, status checks and log analysis are performed to identify sets of obsolete scripts and obsolete consumers. These obsolete consumer sets and obsolete script sets are then merged to form a complete set of obsolete components, including: Based on the definition information of all consumer components, check the running status and active processes of each consumer component to generate a set of abandoned consumers; Based on the information from all script files, check the configuration status of the corresponding scripts in the task scheduling system, analyze the task execution logs, and generate a set of obsolete scripts. The abandoned consumer set and the abandoned script set are merged to obtain the complete abandoned component set.

5. A redundant code identification device based on data flow graphs, characterized in that, include: The obsolete interface identification module is used to identify the set of obsolete interfaces based on interface access logs, full site scan results, and code repository information through set operations. The useless code identification module is used to perform dynamic call detection and data flow analysis based on static analysis tools and abstract syntax trees to identify the internal useless code set; The obsolete component formation module is used to perform status checks and log analysis based on consumer running status, script execution records and task scheduling configuration, identify obsolete script sets and obsolete consumer sets, and merge the obsolete consumer sets and obsolete script sets to form obsolete component sets; The cascading obsolete code identification module is used to construct a full system call graph based on the obsolete interface set, the internal useless code set, and the obsolete component set, and perform reverse reachability analysis to identify the cascading obsolete code set. This includes: constructing a full system call graph containing interfaces, functions, and classes based on the updated call relationship graph, where nodes are divided into entry nodes and internal nodes; marking elements in the obsolete interface set and the obsolete component set as obsolete entry points in the full system call graph; performing a depth-first search from all non-obsolete entry nodes to mark all reachable internal nodes as active nodes; performing a depth-first search from the obsolete entry nodes to mark all reachable but not marked as active internal nodes; and merging and deduplicating internal nodes reachable only from the obsolete entry points to obtain the cascading obsolete code set. The redundancy report generation module is used to generate a complete redundancy code report containing statistical data, a detailed list, and a risk assessment based on the set of obsolete interfaces, the set of internal unused code, the set of obsolete components, and the set of cascaded obsolete code.

Images