Technical debt quantitative repair method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a technology debt quantitative restoration method and device, electronic equipment and a storage medium. The method comprises the steps that a technology debt quantitative data source is acquired; determining at least one technical debt item contained in the software system based on the technical debt quantification data source; for each technical debt item in the at least one technical debt item, determining a technical debt cost corresponding to the technical debt item based on the technical debt quantitative data source; according to the ascending order of the technical debt cost, the low-cost technical debt items are preferentially processed, and the high-cost technical debt items are gradually advanced, so that the debt repair of the software system is completed. According to the technical scheme, the technical debt quantitative data source is introduced, accurate cost evaluation of each technical debt item is realized, and the technical debt item repair priority sequence can be generated based on the quantitative result, so that key debt repair work is preferentially processed, the terminal user experience is improved, and the technical debt repair efficiency is improved. And the continuity and the stability of service operation are ensured.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, electronic device, and storage medium for quantifying and repairing technical debt. Background Technology

[0002] In the field of software development, technical debt refers to compromises made in system architecture, code quality, or engineering standards to meet short-term delivery goals (such as rapid deployment or addressing urgent needs). These compromises may include temporary solutions, reduced test coverage, or simplified design patterns. While such decisions may accelerate short-term delivery, their long-term accumulation leads to a non-linear increase in the complexity of the software system, resulting in systemic risks such as soaring maintenance costs, continuously declining iteration efficiency, and limited technological innovation capabilities.

[0003] The core contradiction in current technology debt management lies in the fact that the cost assessment process for technology debt relies excessively on the experience-based judgment of individual developers. Due to the lack of a unified quantitative assessment framework, different teams or even different members may have orders of magnitude differences in their assessment of the severity of the same technology debt item. This inconsistency in assessment standards directly affects the determination of the priority of technology debt remediation, making it difficult for teams to reach a consensus on the order of technology debt handling. Ultimately, this leads to delays in critical debt remediation work, continuous deterioration of software system quality, and serious impact on end-user experience and business continuity. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for quantifying and repairing technical debt, which can effectively solve the above-mentioned technical problems.

[0005] In a first aspect, embodiments of this application provide a method for quantitatively repairing technical debt, the method comprising:

[0006] Obtain a data source for quantifying technical debt; wherein, the data source for quantifying technical debt refers to a relevant dataset used for systematically assessing and measuring the technical debt of a software system;

[0007] At least one technical debt item contained in the software system is determined based on the technical debt quantification data source;

[0008] For each of the at least one of the said technical debt items, the technical debt cost corresponding to the technical debt item is determined based on the technical debt quantification data source;

[0009] Based on the ascending order of the technical debt costs, the lower-cost technical debt items are processed first, and then the higher-cost technical debt items are processed in order to complete the debt-related repair of the software system.

[0010] Optionally, as described above, determining at least one technical debt item contained in the software system based on the technical debt quantification data source includes:

[0011] Extract the code repository from the aforementioned technical debt quantification data source;

[0012] The code repository was analyzed using static code analysis tools, and at least one code smell module was identified.

[0013] The bad taste code module was identified as a technical debt item.

[0014] Optionally, as described above, determining the technology debt cost corresponding to the technology debt item based on the technology debt quantification data source includes:

[0015] By performing AST parsing on the code repository, static feature data of each code module can be extracted;

[0016] Extract labor cost data, historical repair data, and business value data from the aforementioned data source for quantifying technical debt.

[0017] The technical debt cost corresponding to the technical debt item is determined based on the static code feature data, the human resource cost data, the historical repair data, and the business value data.

[0018] Optionally, as described above, the method is characterized in that determining the technical debt cost corresponding to the technical debt item based on the code static feature data, the human resource cost data, the historical repair data, and the business value data includes:

[0019] The actual repair time of the target historical technical debt item corresponding to each of the aforementioned technical debt items is queried from the historical repair data; wherein, the historical repair data stores the actual repair time corresponding to each historical technical debt item, and the target historical technical debt item is the historical technical debt item with the highest code similarity to the aforementioned technical debt item;

[0020] Determine the hourly wage per unit of labor based on the aforementioned labor cost data;

[0021] Obtain first business value data corresponding to the technical debt item and second business value data corresponding to the technical debt impact item from the business value data; wherein, the technical debt impact item refers to the code module affected by the technical debt item;

[0022] The direct cost of the technical debt item is determined based on the hourly wage of the unit's labor force, the actual repair time corresponding to the technical debt item, and the static code feature data.

[0023] The indirect cost of the technical debt item is determined based on the unit hourly wage, the first business value data and code static feature data corresponding to the technical debt item, the second business value data and code static feature data corresponding to the technical debt impact item, and the actual repair time corresponding to each technical debt item.

[0024] The technology debt cost corresponding to the technology debt item is determined based on the direct costs and the indirect costs.

[0025] Optionally, as described above, determining the direct cost of the technical debt item based on the unit hourly wage, the actual repair time corresponding to the technical debt item, and the static code feature data includes:

[0026] Extract cyclomatic complexity and duplicate code ratio from the static feature data of the code corresponding to the technical debt item;

[0027] The refactoring time is determined based on the actual repair time corresponding to the technical debt item, the cyclomatic complexity, and the proportion of duplicate code.

[0028] The direct cost of the technical debt item is determined based on the reconstruction time and the hourly wage per unit of manpower.

[0029] Optionally, as described above, determining the indirect cost of the technical debt item based on the unit hourly wage, the first business value data and code static characteristic data corresponding to the technical debt item, the second business value data and code static characteristic data corresponding to the technical debt impact item, and the actual repair time corresponding to each technical debt item includes:

[0030] The average repair time is determined based on the actual repair time corresponding to each of the aforementioned technical debt items;

[0031] Extract the number of code module modifications and the number of times the first module was called from the static code feature data corresponding to the technical debt item;

[0032] Extract the number of times the second module is called from the static feature data of the code corresponding to the technical debt impact item;

[0033] The maintenance efficiency loss of the technical debt item is determined based on the average repair time, the hourly wage per unit of manpower, and the number of code module modifications.

[0034] Based on the number of times the first module was called and the first business value data corresponding to the technical debt item, and the number of times the second module was called and the second business value data corresponding to the technical debt impact item, the business weight coefficient is determined.

[0035] The indirect costs of the technical debt item are determined based on the maintenance efficiency loss and the business weighting coefficient.

[0036] Optionally, as described above, determining the business weight coefficient based on the number of times the first module is called and the first business value data corresponding to the technical debt item, and the number of times the second module is called and the second business value data corresponding to the technical debt impact item, includes:

[0037] The first business value is obtained by weighting the number of times the first module is called and the first business value data; wherein, the first business value data includes the revenue contribution ratio and the user access volume ratio.

[0038] The second business value is obtained by weighting the number of times the second module is called and the second business value data.

[0039] The total business value is determined based on the first business value and the second business value.

[0040] The business weight coefficient corresponding to the total business value is retrieved from the business weight coefficient lookup table; wherein, the business weight coefficient lookup table stores in advance the correspondence between the business value range and the business weight coefficient.

[0041] Optionally, as described above, the method further includes:

[0042] Extract the number of circular dependencies and the number of hierarchical violations for each code module from the static feature data of each code module;

[0043] For each of the aforementioned code modules, the number of circular dependencies and the number of hierarchical violations are weighted and calculated to obtain the module architecture corruption index;

[0044] The architecture corruption index of the software system is determined based on the module architecture corruption index of each of the code modules.

[0045] Secondly, embodiments of this application provide a device for quantifying and repairing technical debt, the device comprising:

[0046] The acquisition module is used to acquire data sources for quantifying technical debt; wherein, the data sources for quantifying technical debt refer to relevant datasets used for systematically evaluating and measuring the technical debt of software systems.

[0047] The first determining module is used to determine at least one technical debt item contained in the software system based on the technical debt quantification data source.

[0048] The second determining module is used to determine the technical debt cost corresponding to each of the at least one technical debt item based on the technical debt quantification data source.

[0049] The third determining module is used to prioritize processing low-cost technical debt items based on the ascending order of technical debt costs, and gradually proceed to high-cost technical debt items in order to complete the debt-related repair of the software system.

[0050] Thirdly, embodiments of this application provide an electronic device, comprising: a processor and a memory, wherein the processor is configured to execute a program for quantifying and repairing technical debt stored in the memory, so as to implement the above-described method for quantifying and repairing technical debt.

[0051] Fourthly, embodiments of this application provide a storage medium, wherein the storage medium stores one or more programs, which can be executed by one or more processors to implement the above-described method for quantifying and repairing technical debt.

[0052] The technical debt quantification and repair method, apparatus, electronic device, and storage medium provided in this application embodiment include: acquiring a technical debt quantification data source; wherein, the technical debt quantification data source refers to a relevant dataset used for systematically evaluating and measuring the technical debt of a software system; determining at least one technical debt item contained in the software system based on the technical debt quantification data source; for each technical debt item, determining the corresponding technical debt cost based on the technical debt quantification data source; and prioritizing the processing of low-cost technical debt items according to the ascending order of technical debt costs, gradually progressing to high-cost technical debt items, to complete the debt-related repair of the software system. This technical solution, by introducing a technical debt quantification data source, achieves accurate cost assessment of each technical debt item. Based on the quantification results, a priority ranking of technical debt item repairs can be generated, thereby solving the problem in the traditional model where a lack of objective assessment of technical debt costs leads to a lack of consensus on the order of technical debt processing, resulting in delays in critical debt repair work and continuous deterioration of software system quality. This solution improves the end-user experience while ensuring the continuity and stability of business operations. Attached Figure Description

[0053] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0054] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 A flowchart illustrating an embodiment of a method for quantifying and repairing technical debt provided in this application;

[0056] Figure 2 A flowchart illustrating an embodiment of another technical debt quantification and repair method provided in this application;

[0057] Figure 3 A flowchart illustrating an embodiment of another technical debt quantification and repair method provided in this application;

[0058] Figure 4 A flowchart illustrating an embodiment of another technical debt quantification and repair method provided in this application;

[0059] Figure 5 A flowchart illustrating an embodiment of another technical debt quantification and repair method provided in this application;

[0060] Figure 6 A block diagram illustrating an embodiment of a technical debt quantification and repair device provided in this application;

[0061] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0063] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0064] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0065] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0066] Foundational technologies in artificial intelligence generally include sensors, dedicated AI chips, cloud computing, storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0067] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0068] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0069] This application provides a method for quantitatively repairing technical debt. See also... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of a method for quantifying and repairing technical debt provided in this application. Figure 1 The process shown may include the following steps:

[0070] Step 101: Obtain the data source for quantifying technical debt;

[0071] Among them, the data source for quantifying technical debt refers to the relevant datasets used to systematically assess and measure the technical debt of software systems.

[0072] In the actual data collection process, the data sources for quantifying technical debt are mainly integrated and acquired through the following three types of systems: 1) Technical debt repair data and cost data recorded by project management and defect tracking systems (such as Jira and ZenTao); 2) Business data systems (such as ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management)) to acquire module-related business data for assessing the business value impact of technical debt; and 3) Code repository acquisition systems to acquire code repositories storing code related to the software system. These three types of systems together constitute a multi-dimensional data support system for technical debt assessment.

[0073] Step 102: Determine at least one technical debt item contained in the software system based on the technical debt quantification data source;

[0074] Since bad code smells (such as duplicate code, excessively long methods, etc.) are a direct manifestation of code quality problems and reflect design compromises or temporary solutions, bad code smell modules can be identified as technical debt items in this embodiment. This can be understood as a one-to-one correspondence between the number of bad code smell modules and the number of technical debt items; that is, the number of bad code smell modules corresponds to the number of identified technical debt items.

[0075] The specific process for identifying technical debt items is as follows: extracting code repositories from the technical debt quantification data source; analyzing the code repository using static code analysis tools to obtain at least one bad code smell module; and identifying the bad code smell module as a technical debt item.

[0076] By automatically scanning the code repository with static code analysis tools (such as SonarQube, Checkmarx, etc.), a list of bad code smells can be generated, including: duplication, long methods, large classes, high fan-out / fan-in leading to high coupling and low cohesion between modules, high cyclomatic complexity, non-compliance with coding standards, lack of comments, and potential performance issues or security vulnerabilities.

[0077] In addition, to provide a detailed description of the bad smell modules, the bad smell list should also include the problem type, file path, specific line of code, and severity level (such as "critical", "warning", "recommendation") for each bad smell module, without any restrictions here.

[0078] In addition, the analysis results will be presented through visualization methods (such as a technology debt heatmap, which displays the distribution of debt according to severity levels) to assist in decision-making.

[0079] Step 103: For each of the at least one technical debt items, determine the technical debt cost corresponding to the technical debt item based on the technical debt quantification data source;

[0080] Technical debt cost serves as a quantitative standard for assessing the impact of technical debt on software systems. Its value directly reflects the cost of remediation: a lower cost value means less man-hours and less resource consumption required to remediate the technical debt; a higher cost value indicates that more investment is needed to remediate the technical debt. This quantitative mechanism provides an objective basis for prioritizing technical debt governance, enabling teams to formulate optimal remediation strategies based on cost data.

[0081] Step 104: Based on the ascending order of technical debt costs, prioritize the processing of low-cost technical debt items and gradually proceed to high-cost technical debt items to complete the debt-related repair of the software system.

[0082] Developing a remediation roadmap based on the increasing cost of technical debt allows for the rapid release of team capacity by prioritizing low-cost technical debt items, accumulating resources for the remediation of subsequent high-cost technical debt items.

[0083] The above technical solution introduces a quantitative data source for technical debt to achieve accurate cost assessment of each technical debt item. Based on the quantitative results, a priority ranking of technical debt items for repair can be generated. This solves the problem in the traditional model where the lack of objective assessment of technical debt costs leads to a lack of consensus on the order of technical debt processing, resulting in delays in critical debt repair work and continuous deterioration of software system quality. This solution improves the end-user experience while ensuring the continuity and stability of business operations.

[0084] like Figure 2 As shown, as an optional implementation, the method described above, step 103, determining the technical debt cost corresponding to the technical debt item based on the technical debt quantification data source, includes the following steps:

[0085] Step 201: Extract static feature data of each code module by performing AST parsing on the code repository;

[0086] The source code in the code repository is transformed into a tree structure by using AST (Abstract Syntax Tree). Each node represents a syntactic element of the code (such as functions, loops, variable declarations, etc.), and the static feature data of each code module is extracted by traversing the nodes.

[0087] Step 202: Extract human cost data, historical repair data, and business value data from the technology debt quantification data source;

[0088] Among them, human resource cost data refers to detailed salary data for all staff provided by the finance department. This data can be uploaded and recorded by finance personnel in the project management and defect tracking system for storage and management. Historical repair data covers the actual repair time spent on resolved technical debt items. This data is also stored in the same project management and defect tracking system. Business value data reflects the actual value created by the corresponding business functions of each code module, including key indicators such as revenue contribution ratio and user access ratio. This type of data is usually stored in a dedicated business data system.

[0089] Step 203: Determine the technical debt cost corresponding to the technical debt item based on code static feature data, human resource cost data, historical repair data, and business value data.

[0090] In this embodiment, by associating code quality metrics with business data, an objective basis is provided for quantifying the cost of technical debt items.

[0091] like Figure 3 As shown, as an optional implementation, the method described above, step 203 specifically includes the following steps:

[0092] Step 301: Query the actual repair time of the target historical technical debt item corresponding to each technical debt item from the historical repair data;

[0093] The historical repair data stores the actual repair time for each historical technical debt item. The target historical technical debt item is the one with the highest code similarity to the previous technical debt item. This can be understood as matching the current technical debt item with each historically repaired technical debt item using a code similarity algorithm (such as cosine similarity), and extracting the actual repair time corresponding to the historical technical debt item with the highest similarity.

[0094] Step 302: Determine the hourly wage per unit of labor based on labor cost data;

[0095] Specifically, the hourly wage per unit of labor can be calculated by taking the average of the job salary data (hourly wages for development / testing / operations personnel) provided by the finance department.

[0096] Step 303: Obtain the first business value data corresponding to the technical debt item and the second business value data corresponding to the technical debt impact item from the business value data;

[0097] The aforementioned technical debt impact items refer to code modules affected by technical debt items; technical debt impact items can be understood as code modules that call technical debt items and / or code modules that are called by technical debt items.

[0098] Since the business value data includes business value data corresponding to each code module, it is possible to obtain the first business value data corresponding to the technical debt item and the second business value data corresponding to the technical debt impact item from the business value data; wherein, both the first business value data and the second business value data include the revenue contribution ratio and the user access volume ratio.

[0099] Step 304: Determine the direct cost of the technical debt item based on the unit hourly wage, the actual repair time corresponding to the technical debt item, and the static feature data of the code.

[0100] Direct costs refer to the quantifiable data of resource inputs that can be directly collected and accurately measured when repairing technical debt.

[0101] like Figure 4 As shown, as an optional implementation, the method described above, step 304 specifically includes the following steps:

[0102] Step 401: Extract cyclomatic complexity and duplicate code ratio from the static feature data of the code corresponding to the technical debt item;

[0103] Cyclomatic complexity quantifies the logical complexity of code; a high value indicates more potential defects and maintenance difficulty. The duplicate code ratio refers to the percentage of repetitive or highly similar code snippets within a code module representing technical debt, reflecting maintenance efficiency risks. Given that high cyclomatic complexity and high duplication rates exponentially increase the time required to fix technical debt, direct cost accounting based on these two key indicators can accurately quantify the total development resources required to fix technical debt.

[0104] Step 402: Determine the refactoring time based on the actual repair time, cyclomatic complexity, and duplicate code ratio corresponding to the technical debt item;

[0105] The reconstruction time can be calculated using the following formula:

[0106] Refactoring time = actual repair time × (1 + cyclomatic complexity / cyclomatic complexity threshold) × duplicate code ratio; where the cyclomatic complexity threshold can be set according to actual needs and is not limited here.

[0107] Step 403: Determine the direct costs of technical debt items based on the reconstruction time and the hourly wage per unit of manpower.

[0108] Direct costs can be calculated using the following formula:

[0109] Direct cost = Restructuring time × Hourly wage per unit of manpower.

[0110] Step 305: Determine the indirect cost of the technical debt item based on the unit hourly wage, the first business value data and code static characteristic data corresponding to the technical debt item, the second business value data and code static characteristic data corresponding to the technical debt impact item, and the actual repair time corresponding to each technical debt item;

[0111] Indirect costs refer to the quantifiable data of hidden losses caused by technical debt that cannot be directly attributed to a single repair action (such as increased maintenance costs, decreased development efficiency, system failure risks, and even potential business losses).

[0112] like Figure 5 As shown, as an optional implementation, the method described above, step 305 specifically includes the following steps:

[0113] Step 501: Determine the average repair time based on the actual repair time corresponding to each technical debt item;

[0114] The average repair time is calculated by averaging the actual repair times for each technical debt item. For example, if there are three technical debt items, with technical debt item 1 having a technical modification time of 2 hours, technical debt item 2 having a technical modification time of 8 hours, and technical debt item 3 having a technical modification time of 5 hours, then the average repair time is 5 hours.

[0115] This step determines the average repair time to establish a baseline time unit for subsequent maintenance efficiency loss calculations.

[0116] Step 502: Extract the number of code module modifications and the number of times the first module was called from the static feature data of the code corresponding to the technical debt item;

[0117] The number of code module modifications refers to the number of times the code module of the technical debt item has been committed within a specific period, and this value reflects stability; the number of times the first module is called refers to the number of times the current technical debt item code module is depended on, and this data can be obtained by calling the dependency graph constructed after parsing the code repository using AST.

[0118] Step 503: Extract the number of times the second module is called from the static feature data of the code corresponding to the technical debt impact item;

[0119] Similarly, the number of times the second module corresponding to the technical debt impact item is called can be retrieved from the dependency graph.

[0120] Step 504: Determine the maintenance efficiency loss of technical debt items based on average repair time, hourly wage per unit of manpower, and number of code module modifications;

[0121] Maintenance efficiency loss refers to the additional costs incurred due to reduced efficiency in daily development, maintenance, and defect repair caused by the existence of technical debt.

[0122] In this embodiment, the maintenance efficiency loss can be calculated using the following formula:

[0123] Maintenance efficiency loss = average repair time × hourly wage per unit of manpower × number of code module modifications.

[0124] Step 505: Determine the business weight coefficient based on the number of times the first module is called and the first business value data corresponding to the technical debt item, and the number of times the second module is called and the second business value data corresponding to the technical debt impact item.

[0125] The specific process of determining the business weight coefficients can be achieved through steps A1 to A4:

[0126] Step A1: The first business value is obtained by performing a weighted calculation based on the number of times the first module is called and the first business value data;

[0127] The primary business value data includes the revenue contribution percentage and the user traffic percentage; specifically, the primary business value can be calculated using the following formula:

[0128] First business value = (Weight 1 × Revenue contribution percentage) + (Weight 2 × User visit percentage) + (Weight 3 × Number of times the first module is called). The weights in the formula can be set according to actual needs and are not limited here.

[0129] Step A2: The second business value is obtained by performing a weighted calculation based on the number of times the second module is called and the second business value data;

[0130] The formula for calculating the second business value is the same as that for the first business value; the only difference is that the number of times the first module is called in the first business value calculation formula is replaced with the number of times the second module is called. This will not be elaborated further here. It should be noted that there are several technical debt impact items, requiring the calculation of the corresponding second business value for each of these technical debt impact items.

[0131] Step A3: Determine the total business value based on the first business value and the second business value;

[0132] The total business value mentioned above can be calculated using the following formula:

[0133] Where n represents the total value of the first business.

[0134] Step A4: Query the business weight coefficient corresponding to the total business value from the business weight coefficient lookup table;

[0135] The business weight coefficient lookup table pre-stores the correspondence between business value ranges and business weight coefficients. This code complexity coefficient lookup table may be a database table, an Excel spreadsheet, a configuration file, or other data structure; no specific limitation is made here. For ease of understanding, it is shown in Table 1:

[0136] Table 1

[0137] Business Value Scope Business weight coefficient 0-20 0.2 21-50 0.6 51-80 0.8 81-100 1

[0138] It should be noted that the above-mentioned correspondence between business value range and business weight coefficient is only an example. The specific correspondence between business value range and business weight coefficient can be set according to actual needs, and is not limited here.

[0139] If the calculated total business value is 75, the corresponding business weight coefficient can be found to be 0.8 by referring to Table 1.

[0140] Step 506: Determine the indirect costs of technical debt items based on maintenance efficiency loss and business weighting coefficient.

[0141] Indirect costs can be calculated using the following formula:

[0142] Indirect costs = maintenance efficiency loss × business weight coefficient.

[0143] Step 306: Determine the technology debt cost corresponding to the technology debt item based on direct costs and indirect costs.

[0144] The direct and indirect costs are added together, and the result is determined as the technical debt cost. In this embodiment, the integration method based on AST parsing and technical debt quantification data sources can effectively achieve accurate calculation of technical debt costs, providing data support for prioritizing the remediation of technical debt items.

[0145] Regarding the quantitative model of technical debt costs, in addition to the formula "Technical debt cost = (reconstruction time × unit manpower hourly wage) + (maintenance efficiency loss × business weight coefficient)" proposed in this embodiment, more detailed cost dimensions can be introduced, such as considering the direct economic losses (such as compensation, user churn) caused by online failures due to technical debt, brand reputation losses, and market opportunity costs missed due to system instability or difficulty in modification, etc., which are not limited here.

[0146] In practical applications, much technical debt is not only reflected in code details but may also be hidden at the system architecture design level, such as unreasonable module dependencies, circular dependencies, chaotic hierarchical structures, and aging technology stacks. Existing tools have weak detection capabilities for this type of "architectural corruption," relying more on human experience for judgment. Experience bias may underestimate the severity of architectural problems, allowing corruption to accumulate. To address these technical issues, this embodiment can extract the number of circular dependencies and the number of hierarchical violations for each code module from its static code feature data. For each code module, the number of circular dependencies and the number of hierarchical violations are weighted to obtain a module architecture corruption index. Based on the module architecture corruption index of each code module, the architecture corruption index of the software system is determined.

[0147] Among them, the number of circular dependencies refers to the number of circular reference chains formed between code modules, such as a closed loop structure where module A depends on B, B depends on C, and C depends on A. This metric directly reflects abnormal coupling between system modules; the number of hierarchical violations refers to the number of times a module violates the principles of layered architecture (such as reasonable cross-layer calls, blurred module boundaries, overly centralized "God modules", and hierarchical violations such as aging or inconsistency of the technology stack).

[0148] Each code module can be calculated using the formula (number of circular dependencies × weight 4) + (number of hierarchical violations × weight 5). The weights can be set according to actual needs and are not limited here.

[0149] After obtaining the module architecture corruption index for each of the aforementioned code modules, the multiple module architecture corruption indices are added together. The resulting index is the architecture corruption index of the software system, normalized to a score of 0-100, with higher scores indicating more severe corruption. For visualization, an architecture dependency diagram is generated, highlighting circular dependencies and illegal calls, and outputting the corruption index for easier understanding.

[0150] The aforementioned technical solution transforms implicit architectural issues such as circular dependencies and hierarchical violations into measurable corruption indices through a quantitative evaluation model, enabling digital diagnosis of the architecture's health status. This index-based approach overcomes the subjective limitations of traditional manual experience-based assessments, providing a measurable and comparable objective standard for assessing the degree of architectural corruption. Analysis based on quantitative data can accurately identify the degree of system architecture degradation, offering the technical team a clear basis for prioritizing governance and ensuring timely and effective intervention when architectural corruption reaches a critical threshold.

[0151] During the process of uncovering technical debt, there are also some implicit debts that negatively impact the software system and cannot be directly identified through static analysis. These include: knowledge debt (such as key modules being understood by only a few people, posing a single point of failure risk), testing debt (such as low unit test coverage and insufficient integration testing), and documentation debt (such as outdated or missing design documents). In this embodiment, the technical debt quantification data source can be input into a pre-trained implicit debt identification model, allowing the model to output the identified implicit debts. The implicit debt identification model can be trained using historical technical debt quantification data sources for a classification model; this is not a limitation.

[0152] This technical solution enables hidden debts to be discovered and dealt with in a timely manner, thereby greatly saving maintenance costs.

[0153] At the level of debt discovery and analysis, more advanced machine learning techniques, such as natural language processing, can be used to analyze code comments, commit messages, defect reports, and team communication records to uncover deeper levels of implicit debt and knowledge debt.

[0154] See Figure 6 This is a block diagram illustrating an embodiment of a technical debt quantification and repair device provided in this application. Figure 6 As shown, the device includes:

[0155] The acquisition module 601 is used to acquire the data source for quantifying technical debt; wherein, the data source for quantifying technical debt refers to the relevant dataset used for systematically evaluating and measuring the technical debt of software systems;

[0156] The first determining module 602 is used to determine at least one technical debt item contained in the software system based on the technical debt quantification data source;

[0157] The second determining module 603 is used to determine the technical debt cost corresponding to each technical debt item based on a technical debt quantification data source for at least one technical debt item.

[0158] The third determination module 604 is used to prioritize low-cost technical debt items based on their ascending order of cost, and then gradually proceed to high-cost technical debt items in order to complete the debt-related repair of the software system.

[0159] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0160] As an optional implementation, the first determining module 602 is further configured to:

[0161] Extract code repositories from data sources quantifying technical debt;

[0162] By analyzing the code repository using static code analysis tools, at least one code smell module was identified.

[0163] The bad smell code module was identified as a technical debt item.

[0164] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0165] As an optional implementation, the second determining module 603 is further configured to:

[0166] By performing AST parsing on the code repository, static feature data of each code module can be extracted;

[0167] Extract human cost data, historical repair data, and business value data from the data source for quantifying technical debt.

[0168] The technical debt cost corresponding to each technical debt item is determined based on static code feature data, human resource cost data, historical repair data, and business value data.

[0169] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0170] As an optional implementation, the second determining module 603 is further configured to:

[0171] The actual repair time of the target historical technical debt item corresponding to each technical debt item is retrieved from the historical repair data. The historical repair data stores the actual repair time of each historical technical debt item, and the target historical technical debt item is the historical technical debt item with the highest similarity to the technical debt item code.

[0172] Determine the hourly wage per unit of labor based on labor cost data;

[0173] Obtain the first business value data corresponding to the technical debt item and the second business value data corresponding to the technical debt impact item from the business value data; where the technical debt impact item refers to the code module affected by the technical debt item.

[0174] The direct cost of technical debt items is determined based on the hourly wage of the unit's workforce, the actual repair time corresponding to the technical debt items, and the static characteristic data of the code.

[0175] The indirect costs of technical debt items are determined based on the unit hourly wage, the first business value data and code static characteristic data corresponding to the technical debt items, the second business value data and code static characteristic data corresponding to the technical debt impact items, and the actual repair time corresponding to each technical debt item.

[0176] The technology debt cost corresponding to the technology debt item is determined based on direct costs and indirect costs.

[0177] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0178] As an optional implementation, the second determining module 603 is further configured to:

[0179] Extract cyclomatic complexity and duplicate code ratio from the static feature data of the code corresponding to technical debt items;

[0180] The refactoring time is determined based on the actual repair time, cyclomatic complexity, and proportion of duplicate code corresponding to the technical debt items.

[0181] The direct costs of technical debt items are determined based on the time spent on reconstruction and the hourly wage per unit of manpower.

[0182] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0183] As an optional implementation, the second determining module 603 is further configured to:

[0184] The average repair time is determined based on the actual repair time corresponding to each technical debt item.

[0185] Extract the number of code module modifications and the number of times the first module was called from the static feature data of the code corresponding to the technical debt item;

[0186] Extract the number of times the second module is called from the static feature data of the code corresponding to the technical debt impact item;

[0187] The maintenance efficiency loss of technical debt items is determined based on average repair time, hourly wage per unit of manpower, and number of code module modifications.

[0188] Based on the number of times the first module was called and the first business value data corresponding to the technical debt item, and the number of times the second module was called and the second business value data corresponding to the technical debt impact item, the business weight coefficient is determined;

[0189] The indirect costs of technical debt items are determined based on maintenance efficiency losses and business weighting coefficients.

[0190] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0191] As an optional implementation, the second determining module 603 is further configured to:

[0192] The first business value is obtained by weighting the number of times the first module is called and the first business value data; the first business value data includes the revenue contribution ratio and the user access ratio.

[0193] The second business value is obtained by weighting the number of times the second module is called and the second business value data.

[0194] The total business value is determined based on the value of the first business and the value of the second business.

[0195] Retrieve the business weight coefficient corresponding to the total business value from the business weight coefficient lookup table; the business weight coefficient lookup table pre-stores the correspondence between the business value range and the business weight coefficient.

[0196] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0197] As an optional implementation, the above-described apparatus further includes:

[0198] The extraction module is used to extract the number of circular dependencies and the number of hierarchical violations for each code module from the static feature data of each code module.

[0199] The calculation module is used to perform a weighted calculation on the number of circular dependencies and the number of hierarchical violations for each code module to obtain the module architecture corruption index;

[0200] The fourth module is used to determine the architecture decay index of the software system based on the module architecture decay index of each code module.

[0201] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 The illustrated electronic device 1200 includes at least one processor 1201, a memory 1202, at least one network interface 1204, and other user interfaces 1203. The various components in the electronic device 1200 are coupled together via a bus system 1205. It is understood that the bus system 1205 is used to implement communication between these components. In addition to a data bus, the bus system 1205 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 7 The general labeled all buses as Bus System 1205.

[0202] The user interface 1203 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0203] It is understood that the memory 1202 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 1202 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0204] In some implementations, memory 1202 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 12021 and application program 12022.

[0205] The operating system 12021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 12022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this application embodiment can be included in the application program 12022.

[0206] In this embodiment of the application, the processor 1201 executes the method steps provided by each method embodiment by calling the program or instructions stored in the memory 1202, specifically the program or instructions stored in the application program 12022.

[0207] The methods disclosed in the embodiments of this application can be applied to or implemented by the processor 1201. The processor 1201 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in the processor 1201. The processor 1201 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1202. Processor 1201 reads the information in memory 1202 and completes the steps of the above method in conjunction with its hardware.

[0208] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0209] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0210] The electronic device provided in this embodiment may be as follows: Figure 7 The electronic device shown can perform the following: Figure 1-5 All steps of the quantitative repair method for China's technical debt, thereby achieving Figure 1-5 For details on the technical effects of the debt quantification and repair method shown, please refer to [link / reference]. Figure 1-5 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0211] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0212] When one or more programs in the storage medium can be executed by one or more processors to implement the above-mentioned technical debt quantification repair method.

[0213] The processor is used to execute a program stored in memory for the quantitative repair of technical debt, in order to implement the steps of the quantitative repair of technical debt method.

[0214] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0215] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0216] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for quantitatively repairing technical debt, characterized in that, The method includes: Obtain a data source for quantifying technical debt; wherein, the data source for quantifying technical debt refers to a relevant dataset used for systematically assessing and measuring the technical debt of a software system; At least one technical debt item contained in the software system is determined based on the technical debt quantification data source; For each of the at least one of the said technical debt items, the technical debt cost corresponding to the technical debt item is determined based on the technical debt quantification data source; Based on the ascending order of the technical debt costs, the lower-cost technical debt items are processed first, and then the higher-cost technical debt items are processed in order to complete the debt-related repair of the software system.

2. The method according to claim 1, characterized in that, The determination of at least one technical debt item contained in the software system based on the technical debt quantification data source includes: Extract the code repository from the aforementioned technical debt quantification data source; The code repository was analyzed using static code analysis tools, and at least one code smell module was identified. The bad taste code module was identified as a technical debt item.

3. The method according to claim 2, characterized in that, Determining the technology debt cost corresponding to the technology debt item based on the technology debt quantification data source includes: By performing AST parsing on the code repository, static feature data of each code module can be extracted; Extract labor cost data, historical repair data, and business value data from the aforementioned data source for quantifying technical debt. The technical debt cost corresponding to the technical debt item is determined based on the static code feature data, the human resource cost data, the historical repair data, and the business value data.

4. The method according to claim 3, characterized in that, The determination of the technical debt cost corresponding to the technical debt item based on the static code feature data, the human resource cost data, the historical repair data, and the business value data includes: The actual repair time of the target historical technical debt item corresponding to each of the aforementioned technical debt items is queried from the historical repair data; wherein, the historical repair data stores the actual repair time corresponding to each historical technical debt item, and the target historical technical debt item is the historical technical debt item with the highest code similarity to the aforementioned technical debt item; Determine the hourly wage per unit of labor based on the aforementioned labor cost data; Obtain first business value data corresponding to the technical debt item and second business value data corresponding to the technical debt impact item from the business value data; wherein, the technical debt impact item refers to the code module affected by the technical debt item; The direct cost of the technical debt item is determined based on the hourly wage of the unit's labor force, the actual repair time corresponding to the technical debt item, and the static code feature data. The indirect cost of the technical debt item is determined based on the unit hourly wage, the first business value data and code static feature data corresponding to the technical debt item, the second business value data and code static feature data corresponding to the technical debt impact item, and the actual repair time corresponding to each technical debt item. The technology debt cost corresponding to the technology debt item is determined based on the direct costs and the indirect costs.

5. The method according to claim 4, characterized in that, The step of determining the direct cost of the technical debt item based on the unit hourly wage, the actual repair time corresponding to the technical debt item, and the static code feature data includes: Extract cyclomatic complexity and duplicate code ratio from the static feature data of the code corresponding to the technical debt item; The refactoring time is determined based on the actual repair time corresponding to the technical debt item, the cyclomatic complexity, and the proportion of duplicate code. The direct cost of the technical debt item is determined based on the reconstruction time and the hourly wage per unit of manpower.

6. The method according to claim 4, characterized in that, The determination of the indirect cost of the technical debt item based on the unit hourly wage, the first business value data and code static characteristic data corresponding to the technical debt item, the second business value data and code static characteristic data corresponding to the technical debt impact item, and the actual repair time corresponding to each technical debt item includes: The average repair time is determined based on the actual repair time corresponding to each of the aforementioned technical debt items; Extract the number of code module modifications and the number of times the first module was called from the static code feature data corresponding to the technical debt item; Extract the number of times the second module is called from the static feature data of the code corresponding to the technical debt impact item; The maintenance efficiency loss of the technical debt item is determined based on the average repair time, the hourly wage per unit of manpower, and the number of code module modifications. Based on the number of times the first module was called and the first business value data corresponding to the technical debt item, and the number of times the second module was called and the second business value data corresponding to the technical debt impact item, the business weight coefficient is determined. The indirect costs of the technical debt item are determined based on the maintenance efficiency loss and the business weighting coefficient.

7. The method according to claim 6, characterized in that, The step of determining the business weight coefficient based on the number of times the first module is called and the first business value data corresponding to the technical debt item, and the number of times the second module is called and the second business value data corresponding to the technical debt impact item, includes: The first business value is obtained by weighting the number of times the first module is called and the first business value data; wherein, the first business value data includes the revenue contribution ratio and the user access volume ratio. The second business value is obtained by weighting the number of times the second module is called and the second business value data. The total business value is determined based on the first business value and the second business value. The business weight coefficient corresponding to the total business value is retrieved from the business weight coefficient lookup table; wherein, the business weight coefficient lookup table stores in advance the correspondence between the business value range and the business weight coefficient.

8. The method according to claim 3, characterized in that, The method further includes: Extract the number of circular dependencies and the number of hierarchical violations for each code module from the static feature data of each code module; For each of the aforementioned code modules, the number of circular dependencies and the number of hierarchical violations are weighted and calculated to obtain the module architecture corruption index; The architecture corruption index of the software system is determined based on the module architecture corruption index of each of the code modules.

9. A device for quantifying and repairing technical debt, characterized in that, The device includes: The acquisition module is used to acquire data sources for quantifying technical debt; wherein, the data sources for quantifying technical debt refer to relevant datasets used for systematically evaluating and measuring the technical debt of software systems. The first determining module is used to determine at least one technical debt item contained in the software system based on the technical debt quantification data source. The second determining module is used to determine the technical debt cost corresponding to each of the at least one technical debt item based on the technical debt quantification data source. The third determining module is used to prioritize processing low-cost technical debt items based on the ascending order of technical debt costs, and gradually proceed to high-cost technical debt items in order to complete the debt-related repair of the software system.

10. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a program for quantifying and repairing technical debt stored in the memory, to implement the method for quantifying and repairing technical debt as described in any one of claims 1 to 8.

11. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the technical debt quantification and repair method according to any one of claims 1 to 8.

Images