Method, apparatus and device for determining redundant code, and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for determining redundant code. The method involves acquiring access data corresponding to multiple page links in a project to be processed, and a file dependency graph corresponding to the project; determining target page links that meet preset conditions based on preset duration and access thresholds, according to the access data corresponding to the multiple page links; identifying cleanable redundant code files based on the target page link data and the file dependency graph; and cleaning up the redundant code files. This technical solution can more accurately clean up redundant code.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for determining redundant code. Background Technology

[0002] In modern web development, front-end projects are typically designed with a modular architecture, dynamically loading page components through a routing system. As business requirements iterate frequently, the project codebase continues to expand, leading to the accumulation of code redundancy issues.

[0003] Existing technologies mainly rely on static code analysis tools and human experience to identify redundant code, which is then removed.

[0004] However, with frequent business iterations, the above method may not accurately remove redundant code. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for determining redundant codes, in order to improve the accuracy of redundant code removal.

[0006] In a first aspect, embodiments of this application provide a method for determining redundant code, including:

[0007] Obtain the access data corresponding to multiple page link data in the project to be processed and the file dependency graph corresponding to the project to be processed;

[0008] Based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions is determined from the multiple page link data. The preset conditions are determined based on preset duration and access threshold.

[0009] Based on the target page link data and the file dependency graph, identify redundant code files that can be cleaned up;

[0010] Clean up the redundant code files.

[0011] In one or more embodiments, determining the cleanable redundant code files based on the target page link data and the file dependency graph includes:

[0012] Obtain the first file list and the full file list referenced in the file dependency graph. The full file list is a file list obtained by performing a full scan of the file system corresponding to the project to be processed.

[0013] The redundant code files are determined based on the first file list, the full file list, and the target page link data.

[0014] In one or more embodiments, determining the redundant code file based on the first file list, the full file list, and the target page link data includes:

[0015] By comparing the full file list with the first file list, a first code file is identified that is not referenced by the dependency path and is not a necessary configuration file for the project to be processed.

[0016] The intersection of the first code file and the second code file corresponding to the target page link data is determined as the redundant code file.

[0017] In one or more embodiments, obtaining the file dependency graph corresponding to the project to be processed includes:

[0018] In the local environment corresponding to the project to be processed, obtain the path mapping relationship of the project to be processed and the full file list;

[0019] The file dependency graph is determined based on the path mapping relationship, the full file list, and multiple page link data.

[0020] In one or more embodiments, determining the file dependency graph based on the path mapping relationship, the full file list, and multiple page link data includes:

[0021] Using the multiple page link data as the entry point, the dependency relationship of the full file list is traversed and analyzed based on the path mapping relationship to construct the file dependency relationship graph.

[0022] In one or more embodiments, obtaining access data corresponding to multiple page link data in the project to be processed includes:

[0023] Obtain the full routing information of the project to be processed, the full routing information including: the multiple page link data;

[0024] For each page link, access data corresponding to the page link is obtained using tracking tools or traffic monitoring tools.

[0025] In one or more embodiments, determining the target page link data that meets preset conditions from the plurality of page link data based on the access data corresponding to the plurality of page link data includes:

[0026] For each page link data corresponding to the access data, determine the target access data within the preset time period where the access data is less than or equal to the access threshold;

[0027] The page link data corresponding to each of the target access data is determined as the target page link data.

[0028] Secondly, embodiments of this application provide a device for determining redundant codes, comprising:

[0029] The acquisition module is used to acquire access data corresponding to multiple page link data in the project to be processed and the file dependency graph corresponding to the project to be processed.

[0030] The first determining module is used to determine, based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions from the multiple page link data, wherein the preset conditions are determined based on a preset duration and an access threshold.

[0031] The second determining module is used to determine the redundant code files that can be cleaned up based on the target page link data and the file dependency graph.

[0032] The processing module is used to clean up the redundant code files.

[0033] In one or more embodiments, the second determining module, based on the target page link data and the file dependency graph, determines cleanable redundant code files, specifically for:

[0034] Obtain the first file list and the full file list referenced in the file dependency graph. The full file list is a file list obtained by performing a full scan of the file system corresponding to the project to be processed.

[0035] The redundant code files are determined based on the first file list, the full file list, and the target page link data.

[0036] In one or more embodiments, the second determining module determines the redundant code file based on the first file list, the full file list, and the target page link data, specifically for:

[0037] By comparing the full file list with the first file list, a first code file is identified that is not referenced by the dependency path and is not a necessary configuration file for the project to be processed.

[0038] The intersection of the first code file and the second code file corresponding to the target page link data is determined as the redundant code file.

[0039] In one or more embodiments, the acquisition module acquires the file dependency graph corresponding to the project to be processed, specifically for:

[0040] In the local environment corresponding to the project to be processed, obtain the path mapping relationship of the project to be processed and the full file list;

[0041] The file dependency graph is determined based on the path mapping relationship, the full file list, and multiple page link data.

[0042] In one or more embodiments, the acquisition module determines the file dependency graph based on the path mapping relationship, the full file list, and multiple page link data, specifically for:

[0043] Using the multiple page link data as the entry point, the dependency relationship of the full file list is traversed and analyzed based on the path mapping relationship to construct the file dependency relationship graph.

[0044] In one or more embodiments, the acquisition module acquires access data corresponding to multiple page link data in the project to be processed, specifically for:

[0045] Obtain the full routing information of the project to be processed, the full routing information including: the multiple page link data;

[0046] For each page link, access data corresponding to the page link is obtained using tracking tools or traffic monitoring tools.

[0047] In one or more embodiments, the first determining module determines target page link data that meets preset conditions from the plurality of page link data based on the access data corresponding to each of the plurality of page link data, specifically for:

[0048] For each page link data corresponding to the access data, determine the target access data within the preset time period where the access data is less than or equal to the access threshold;

[0049] The page link data corresponding to each of the target access data is determined as the target page link data.

[0050] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0051] The memory stores computer-executed instructions;

[0052] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0053] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0054] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0055] The method, apparatus, device, and storage medium for determining redundant code provided in this application embodiment obtain access data corresponding to multiple page link data in the project to be processed and a file dependency graph corresponding to the project to be processed; based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions are determined from the multiple page link data, the preset conditions being determined based on a preset duration and access threshold; based on the target page link data and the file dependency graph, cleanable redundant code files are determined; and redundant code files are cleaned up. This technical solution acquires access data and file dependency graphs corresponding to multiple page links in the project to be processed, enabling a comprehensive understanding of the actual access status of each page and the relationship structure between code files. Subsequently, target page links meeting preset conditions are identified from the multiple page link data, allowing for precise filtering of pages that have been largely ignored or have extremely low access volume based on time and access popularity. Then, based on the target page link data and file dependency graph, redundant code files that can be cleaned up are determined, allowing for the tracing of isolated code modules referenced only by these low-population pages and not used by other high-frequency pages. Finally, cleaning up redundant code files effectively removes unnecessary and useless code from the project, thereby reducing project size, lowering maintenance costs, and improving build and loading efficiency. Attached Figure Description

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

[0057] Figure 1 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 1 ;

[0058] Figure 2 This is a schematic diagram of page link data provided in an embodiment of this application;

[0059] Figure 3 This is a schematic diagram illustrating the clearing of page link data provided in an embodiment of this application;

[0060] Figure 4Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 2 ;

[0061] Figure 5 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 3 ;

[0062] Figure 6 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 4 ;

[0063] Figure 7 This is a schematic diagram of the monitoring process of the traffic monitoring tool provided in the embodiments of this application;

[0064] Figure 8 A schematic diagram illustrating the execution flow of the preparation module provided in this application embodiment;

[0065] Figure 9 A schematic diagram of the execution flow of the file scanning module provided in an embodiment of this application;

[0066] Figure 10 A schematic diagram of the execution flow of the dependency analysis module provided in an embodiment of this application;

[0067] Figure 11 A schematic diagram of the execution flow of the result output module provided in the embodiments of this application;

[0068] Figure 12 A schematic diagram of the execution flow of the deletion module provided in an embodiment of this application;

[0069] Figure 13 A schematic diagram of the structure of the device for determining redundant codes provided in the embodiments of this application;

[0070] Figure 14 A schematic diagram of the structure of the electronic device provided in this application.

[0071] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0072] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0073] In modern web development, front-end projects are typically designed with a modular architecture, dynamically loading page components through a routing system. As business requirements iterate frequently, the project codebase continues to expand, for example, by adding new functional modules, optimizing interaction logic, and refactoring the code structure.

[0074] However, this dynamism also leads to the accumulation of code redundancy: unaccessed route pages, unreferenced component code, and legacy obsolete functional modules gradually pile up in the project. This redundant code not only increases project build time and deployment size, but may also lead to increased code maintenance complexity and even potential version compatibility issues.

[0075] Development teams often face the challenge of code cleanup when maintaining large-scale front-end applications. For example, after business line adjustments, some pages may not be accessed for a long time, but developers may find it difficult to accurately identify whether they are useless code using static code analysis tools; some modules may be indirectly referenced in the code, but are not actually triggered at runtime; dynamically imported component paths may have invalid dependencies due to configuration errors or legacy issues.

[0076] Existing tools are primarily based on static syntax trees or file dependency graph analysis. Furthermore, manual code cleanup suffers from low efficiency, a high risk of accidental deletion, and difficulty in tracing deletion history.

[0077] Accordingly, addressing the technical problems existing in the prior art, the inventors of this application conceived as follows: Recognizing that in the long-term iteration of large-scale front-end projects, a large number of pages and their associated code that are no longer accessed by users accumulate. These redundant files not only increase the project's size and build time but also increase the maintenance burden on developers. Therefore, real user access data can be introduced as a basis for judgment. By collecting the access volume of multiple pages within a preset time period and setting access thresholds, less popular pages that meet the cleanup criteria can be filtered out. However, simply knowing which pages are less popular is insufficient to locate specific code files, as the same code file may be shared by multiple pages. Therefore, a further concept is to construct a file dependency graph for the project to visually display which pages depend on each code file. Finally, by combining the less popular page data with the dependency graph, it is possible to deduce those code files that are only depended on by less popular pages but not used by popular pages. These files are the redundant code that can be safely cleaned up, thereby solving the aforementioned technical problems.

[0078] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0079] It should be understood that this method is applied to electronic devices.

[0080] Figure 1 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 1 ,like Figure 1 As shown, the method includes:

[0081] Step 11: Obtain the access data corresponding to multiple page link data in the project to be processed and the file dependency graph corresponding to the project to be processed;

[0082] In this step, the routing configuration file of the project to be processed is first parsed to generate a full list of page links at the project level. Then, based on this full list of page link data, access data for each page link in the online environment is obtained using a data tracking tool.

[0083] Simultaneously, obtain the file dependency graph of the project to be processed. This file dependency graph can be a static structure graph that reflects the reference relationships between project code files, constructed by using the full list of page links as the entry point and through static analysis (Abstract Syntax Tree (AST) parsing, Breadth-First Search (BFS) traversal, etc.).

[0084] For example, Figure 2 This is a schematic diagram of page link data provided in an embodiment of this application, such as... Figure 2 As shown in the diagram, the page link data may include: page name, page link, and a description of the page name.

[0085] For example, the page name could be: Order List, Order Search, Order Details, Package Details, Bulk Receipt, etc.; the page link could be: detailed URL data.

[0086] For example, the contents of the route configuration file in the project to be processed can be as follows:

[0087] module.exports = [

[0088] {

[0089] / **

[0090] * Form page

[0091] /

[0092] path: ' / bind-bd',

[0093] name: 'bind-bd',

[0094] redirect: ' / bind-bd / list',

[0095] component: async() => await import('@views / bind-bd / index.vue'),

[0096] children: [

[0097] {

[0098] path: 'list',

[0099] name: 'list',

[0100] meta: {

[0101] Title: 'Guaranteed Sales Merchant Management'

[0102] },

[0103] component: async() =>

[0104] await import(

[0105] / * webpackChunkName: "bind-bd-list" * /

[0106] '@views / bind-bd / list / index.vue' )

[0108] },

[0109] {

[0110] path: 'close-communate',

[0111] name: 'close-communate',

[0112] meta: {

[0113] title: 'Manage Guaranteed Sale Merchants'

[0114] },

[0115] component: async() =>

[0116] await import(

[0117] / * webpackChunkName: "bind-bd-close-communate" * /

[0118] '@views / bind-bd / close-communate / index.vue' )

[0120] },

[0121] {

[0122] path: 'qr-code',

[0123] name: 'qr-code',

[0124] meta: {

[0125] title: 'My QR Code'

[0126] },

[0127] component: async() =>

[0128] await import(

[0129] / * webpackChunkName: "bind-bd-qr-code" * /

[0130] '@views / bind-bd / qr-code / index.vue' )

[0132] },

[0133] {

[0134] path: 'scan-code',

[0135] name: 'scan-code',

[0136] meta: {

[0137] title: 'Binding BD'

[0138] },

[0139] component: async() =>

[0140] await import(

[0141] / * webpackChunkName: "bind-bd-scan-code" * /

[0142] '@views / bind-bd / scan-code / index.vue' )

[0144] } ]

[0146] } ]

[0148] Step 12: Based on the access data corresponding to the multiple page link data, determine the target page link data that meets the preset conditions from the multiple page link data;

[0149] The preset conditions are determined based on preset duration and access thresholds;

[0150] In this step, based on preset duration and access threshold, low-value or no-access pages can be filtered from all page link data, and the corresponding page link data of these pages can be identified as target page link data that meets preset conditions.

[0151] Optionally, one possible implementation of step 12 could be:

[0152] Step 1: For each page link data, determine the target access data that is less than or equal to the access threshold within a preset time period.

[0153] In this implementation, all page link data is traversed, and for each page link data, its access data (abbreviated as PV) within a specified preset time period (e.g., the most recent 90 days) is retrieved from the router_pv table or other storage.

[0154] Then, this access data is compared with a pre-set access threshold (e.g., 0 times, 2 times).

[0155] For example, if the total page views (PV) for the page / bind-bd / close-communate over the past 90 days is 0, then the access data for that page is identified as the target access data.

[0156] Step 2: Determine the page link data corresponding to all target access data as target page link data.

[0157] In this implementation, all target access data that meets the requirement of accessing less than or equal to the access threshold within a preset time period is filtered out, and the corresponding page link data is marked as target page link data, which represents those pages that have been ignored online for a long time.

[0158] Step 13: Based on the target page link data and file dependency graph, identify redundant code files that can be cleaned up;

[0159] In this step, after obtaining the list of inaccessible pages (i.e., target page link data) and the project's complete file dependency graph, the two are combined to identify underlying code files that may be obsolete due to these pages being obsolete.

[0160] In other words, if a code file is only referenced by target page link data (i.e., no accessed page) in the file dependency graph, or is not referenced by any page link data at all, then the code file is a cleaned-up redundant code file.

[0161] Step 14: Clean up redundant code files.

[0162] In this step, the redundant code files identified in step 13 are cleaned up, which means they can be directly deleted.

[0163] Optionally, for enhanced security and operability, a secure deletion mechanism and audit logs can be configured. This means that multiple security checks can be performed before deletion, such as confirming whether the file is in a version control system like Git, whether it has been recently modified, and whether it matches user-defined exclusion patterns.

[0164] Then, after confirming that everything is correct, the deletion operation is performed, and a complete operation audit log is recorded, including the deletion time, the list of deleted files, and other information, so as to facilitate subsequent problem tracking and rollback when necessary.

[0165] For example, Figure 3 This is a schematic diagram illustrating the clearing of page link data provided in an embodiment of this application, such as... Figure 3 As shown in the diagram, the diagram includes: project name, page Uniform Resource Locator (URL), route name, route description, 90-day page views (PV), status, and entry time.

[0166] For example, the project names are A and B, and the rest can be added based on the actual situation.

[0167] The method for determining redundant code provided in this application involves obtaining access data corresponding to multiple page link data in a project to be processed and a file dependency graph corresponding to the project to be processed; determining target page link data that meets preset conditions from the multiple page link data based on the access data corresponding to the multiple page link data, wherein the preset conditions are determined based on a preset duration and access threshold; determining cleanable redundant code files based on the target page link data and the file dependency graph; and cleaning up the redundant code files. This technical solution acquires access data and file dependency graphs corresponding to multiple page links in the project to be processed, enabling a comprehensive understanding of the actual access status of each page and the relationship structure between code files. Subsequently, target page links meeting preset conditions are identified from the multiple page link data, allowing for precise filtering of pages that have been largely ignored or have extremely low access volume based on time and access popularity. Then, based on the target page link data and file dependency graph, redundant code files that can be cleaned up are determined, allowing for the tracing of isolated code modules referenced only by these low-population pages and not used by other high-frequency pages. Finally, cleaning up redundant code files effectively removes unnecessary and useless code from the project, thereby reducing project size, lowering maintenance costs, and improving build and loading efficiency.

[0168] Based on the above embodiments, Figure 4 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 2 ,like Figure 4 As shown, step 13 may include:

[0169] Step 41: Obtain the list of the first referenced files and the full list of files in the file dependency graph;

[0170] The full file list is a list of files obtained by performing a full scan of the file system corresponding to the project to be processed.

[0171] In this step, all files that are directly or indirectly referenced by at least one entry point (including all page links) can be extracted from the file dependency graph constructed in step 52 to form the first file list (i.e., the active file list).

[0172] And, the full file list obtained from step 51 (i.e., all files that exist in the project).

[0173] Step 42: Based on the first file list, the full file list, and the target page link data, identify the redundant code files.

[0174] In this step, multiple comparisons are performed based on the first file list, the full file list, and the target page link data to identify redundant code files that can be cleaned up.

[0175] Optionally, one possible implementation of step 42 could be:

[0176] Step 1: Compare the full file list and the first file list to identify the first code file that is not referenced by dependency paths and is not a necessary configuration file for the project to be processed.

[0177] In this implementation, a set difference operation can be performed, subtracting the first file list from the full file list to obtain a preliminary candidate set of unreferenced files.

[0178] Then, a security check filter can be applied to exclude configuration files necessary for the project to run, such as package.json, webpack.config.js, eslintrc.js, etc., as well as files that may be subject to special requirements by the build tool or version control system from this unreferenced file candidate set. The remaining files are recorded as the first code files.

[0179] Step 2: Identify the intersection code file between the first code file and the second code file corresponding to the link data of the target page as the redundant code file.

[0180] In this implementation, firstly, based on the target page link data and its position in the file dependency graph, all code files referenced only by the target page link data are traced back and used as the second code files.

[0181] Then, we can take the intersection of the first code file and the second code file (the dynamic abandoned page related file). That is, the intersection code file is not only not referenced anywhere in the static dependency analysis, but it is also strongly related to a page that has been proven by online data to be truly unused.

[0182] The method for determining redundant code provided in this application involves obtaining a first file list and a full file list referenced in the file dependency graph. The full file list is obtained by performing a full scan of the file system corresponding to the project to be processed. Redundant code files are determined based on the first file list, the full file list, and the target page link data. In this technical solution, by obtaining the first file list and the full file list referenced in the file dependency graph, the scope of files actually involved in the construction of modules in the project and the overview of all files existing in the project directory can be grasped. Determining redundant code files based on the first file list, the full file list, and the target page link data involves cross-comparing the files statically referenced in the dependency graph, all physically stored files, and information on infrequently accessed pages filtered based on real access data to accurately locate isolated or redundant files that exist in the file system but are not referenced by any dependency relationship, or are only referenced by infrequently accessed pages and not depended on by core pages.

[0183] Based on the above embodiments, Figure 5 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 3 ,like Figure 5 As shown, obtaining the file dependency graph corresponding to the project to be processed in step 11 may include:

[0184] Step 51: In the local environment corresponding to the project to be processed, obtain the path mapping relationship and the full file list of the project to be processed;

[0185] In this step, a project analysis environment can be initialized, which is the local environment corresponding to the project to be processed. The basic structure, compilation options and module parsing rules of the project can be obtained by parsing the configuration files (such as package.json, tsconfig.json, webpack.config.js) in the root directory of the project to be processed.

[0186] Furthermore, in order to establish the path mapping relationship of the project to be processed, all path alias definitions can be extracted from these configuration files. For example, @ / in the code can be mapped to the actual src / directory, @views can be mapped to a specific view folder, and other complex mappings defined in the paths field of tsconfig.json can be processed. Finally, a complete alias-actual path mapping table is generated, which is recorded as the path mapping relationship.

[0187] At the same time, by recursively scanning the project folder (for example, using fs.readdirSync()), a graph data structure can be built with file paths as keys and storing file information (such as filename, size, modification time), thereby obtaining a full list of files containing all supporting files (such as .vue, .js, .ts).

[0188] Step 52: Determine the file dependency graph based on the path mapping relationship, the full file list, and the link data of multiple pages.

[0189] In this step, the multiple page link data obtained are used as the entry point for traversal. Using the path mapping relationship established in step 51, a deep dependency analysis is performed on the full file list to construct the file dependency graph of the entire project to be processed.

[0190] During the traversal, circular dependencies can be detected and handled by recording the visited paths, preventing the algorithm from getting stuck in an infinite loop.

[0191] Optionally, one possible implementation of step 52 could be: using multiple page link data as the entry point, performing dependency traversal analysis on the full file list based on path mapping relationships, and constructing a file dependency graph.

[0192] In this implementation, the BFS algorithm can be used to start from these entry points and gradually resolve the dependency references in each file of the full file list.

[0193] The parsing process can rely on AST analysis and lexical analysis techniques to accurately identify various citation patterns, including:

[0194] 1) Static import: e.g., importModulefrom'@ / components / Module'.

[0195] 2) Dynamic import: e.g., ()=>import('@ / views / Home.vue').

[0196] 3) Vue component registration: Identifies components:{ComponentName} or... <scriptsetup>Automatic registration in [the system / mechanism].

[0197] Optionally, before analyzing the import statements of each file, the file content can be preprocessed: using a lexical analyzer, the code content can be distinguished into code tokens (i.e., valid code), comments, and strings.

[0198] During the parsing process, a preprocessing step can be used to ignore comments and pseudo-paths within strings, avoiding false judgments. Simultaneously, a unified path resolver converts all forms of paths (relative paths like `. / utils`, alias paths like `@ / components`) to absolute paths based on path mapping relationships, and performs file existence verification (e.g., completing file extensions or finding the `index.js` file). In this way, an accurate, non-circular dependency-free directed graph (preventing infinite recursion through a circular dependency detection mechanism) is constructed—that is, a file dependency graph.

[0199] All nodes traversed in the dependency graph of this file are active files that are directly or indirectly referenced by the entry page.

[0200] The method for determining redundant code provided in this application involves obtaining the path mapping relationship and full file list of the project to be processed in the local environment corresponding to the project; and determining the file dependency graph based on the path mapping relationship, the full file list, and multiple page link data. In this technical solution, by obtaining the path mapping relationship and full file list of the project to be processed in the local environment corresponding to the project, it is possible to establish the resolution rules between file paths within the project and module reference aliases, and to grasp the complete picture of all files physically stored in the project; by determining the file dependency graph based on the path mapping relationship, the full file list, and multiple page link data, the page entry file can be used as the starting point, and the actual physical file path referenced by each module can be accurately resolved using the path mapping rules; and by recursively traversing all files in the full file list, all file nodes and their reference chains dependent on each page entry can be completely traced.

[0201] Based on the above embodiments, Figure 6 Flowchart of the method for determining redundant code provided in the embodiments of this application Figure 4 ,like Figure 6 As shown, step 11, obtaining the access data corresponding to multiple page link data in the project to be processed, may include:

[0202] Step 61: Obtain the full routing information of the project to be processed. The full routing information includes: multiple page link data;

[0203] In this step, all route definitions, especially dynamic import statements, can be matched by parsing the routing configuration file (e.g., router data) of the front-end project to be processed and using regular expressions or AST analysis.

[0204] For example, from the `path` and `children` fields in the JSON structure, complete paths such as ` / bind-bd / list` and ` / bind-bd / qr-code` can be extracted recursively. Ultimately, this generates multi-page link data at the project level, i.e., full routing information.

[0205] Step 62: For each page link data, obtain the access data corresponding to the page link data through tracking tools or traffic monitoring tools.

[0206] In this step, after obtaining the full routing information, we can retrieve the actual online access data for each page's link data.

[0207] For example, by setting up a scheduled task, the API of the traffic monitoring tool is called to query the page views of each page link data within a preset time period (such as the last 90 days), and the query results are associated with the page information and stored to obtain the access data corresponding to each page link data.

[0208] As shown in the following embodiment, a scheduled task can be set to obtain a list of URLs from page_url_manage (page link management module), then query PV data through pageShow tracking points, and finally record the results (e.g., page URLs and their corresponding PV values) in the router_pv data table.

[0209] For example, Figure 7 This is a schematic diagram of the monitoring process of the traffic monitoring tool provided in the embodiments of this application, such as... Figure 7 As shown in the diagram, the system includes: scheduled task startup, page URL manager, router access table (newly added), and cloud window.

[0210] In one possible implementation, the following steps are performed: A list of routers for all projects is queried in the page URL manager to obtain all project routes; a scheduled task queries the router access table for existing route information; a scheduled task compares route differences; a new route (state=0) is inserted into the router access table; after successful insertion, the state is updated (state=03); after successful update, routes with state=0, 1, and 2 are retrieved and the route list is returned; a scheduled task submits a PV query SQL query in the cloud window and retrieves the returned task identifier (taskid); a scheduled task submits the polling progress (5 minutes) in the cloud window and retrieves the returned result; a scheduled task creates a new router with PV = active and returns a success update; a scheduled task creates a router with 7-day PV = obsolete and returns a success update; a scheduled task creates a router with PV = active and returns a success update; a scheduled task creates a router with no PV = active and returns a success update; a scheduled task creates a router with PV = active and returns a success update.

[0211] The method for determining redundant code provided in this application involves obtaining full routing information from the project to be processed. This full routing information includes multiple page link data. For each page link data, access data corresponding to that page link data is obtained using a data tracking tool or traffic monitoring tool. In this technical solution, by obtaining full routing information from the project to be processed, which includes multiple page link data, all accessible page paths in the project can be completely listed, providing a clear target scope for subsequent targeted analysis. For each page link data, obtaining access data corresponding to that page link data using a data tracking tool or traffic monitoring tool allows the abstract routing address to be associated with real user behavior data, thereby quantifying the actual popularity or unpopularity of each page. This provides reliable data support for accurately identifying cleanable redundant code, avoiding accidental or missed deletions that may result from subjective judgment alone.

[0212] Based on the above embodiments, the electronic device executing the method for determining redundant code is virtualized into 5 modules, including: a preparation module, a file scanning module, a dependency analysis module, a result output module, and a deletion module.

[0213] The following sections detail the implementation process of the method for determining redundant code, using the execution flow of each module as an example:

[0214] Figure 8 The execution flow diagram of the preparation module provided in the embodiments of this application is as follows: Figure 8 As shown, the execution flow includes:

[0215] Step 81: Execute the command that determines the redundant code;

[0216] Step 82: Parse the project configuration;

[0217] Step 83: Resolve path aliases;

[0218] Step 84: Initialize the data structure.

[0219] Figure 9 This is a schematic diagram of the execution flow of the file scanning module provided in the embodiments of this application, such as... Figure 9 As shown, the execution flow includes:

[0220] Step 901: Scan the views directory;

[0221] Step 902: Scan the components directory;

[0222] Step 903: Scan other directories;

[0223] Step 904: Traverse and determine file type;

[0224] Step 905: Is it a .vue file? If yes, proceed to step 907; if no, proceed to step 906.

[0225] Step 906: Is it a .js file? If yes, proceed to step 907; if no, proceed to step 905.

[0226] Step 907: Store to file mapping;

[0227] Step 908: Construct file metadata;

[0228] Step 909: Read the main routing file;

[0229] Step 910: Read the routing module file;

[0230] Step 911, Code Preprocessing: Remove comments; standardize formatting; protect string content;

[0231] Step 912: Dynamic import recognition: import() format; webpack comment format; multi-line format;

[0232] Step 913, Dynamic Import Standardization: Relative path conversion; Alias ​​path handling; Extension completion;

[0233] Step 914: Mark the routing component as being used by yourself.

[0234] Figure 10 This is a schematic diagram of the execution flow of the dependency analysis module provided in the embodiments of this application, as shown below. Figure 10 As shown, the execution flow includes:

[0235] Step 101: Create an analysis queue;

[0236] Step 102: Traverse the queue;

[0237] Step 103: Is the queue empty? If yes, proceed to step 104; if no, proceed to step 113.

[0238] Step 104: Retrieve the current file;

[0239] Step 105: Has the file been analyzed? If yes, proceed to step 103; if no, proceed to step 106.

[0240] Step 106: Analyze the document content;

[0241] Step 107, Static Import Analysis: import…from…; Filtering third-party libraries; Handling internal project references;

[0242] Step 108, Dynamic Import Analysis: import(); Handling back comments;

[0243] Step 109: Sub-component registration analysis;

[0244] Step 110, Special Registration / Identification: Vue.extend; require;

[0245] Step 111: Mark the dependency as used;

[0246] Step 112: Add the new dependency to the queue; proceed to step 103.

[0247] Step 113: Dependency analysis completed.

[0248] Figure 11 This is a schematic diagram of the execution flow of the result output module provided in the embodiments of this application, such as... Figure 11 As shown, the execution flow includes:

[0249] Step 115: Statistical Analysis Results: Total number of files; Used files; Unused files;

[0250] Step 116: Generate a Markdown report: Overall statistics; List of unused files; List of routing components; Optimization suggestions;

[0251] Step 117: Generate a brief text report: basic statistics; file list.

[0252] Figure 12 This is a schematic diagram of the execution flow of the deletion module provided in an embodiment of this application, as shown below. Figure 12 As shown, the execution flow includes:

[0253] Step 121: Are there any unused files? If yes, proceed to step 122; if no, proceed to step 124.

[0254] Step 122: Verify the existence of the file;

[0255] Step 123: Traverse and delete files;

[0256] Step 124: End the deletion script.

[0257] The method for determining redundant code shown in the above embodiments has the following technical effects:

[0258] Technical benefits 1) Improved accuracy: By combining PV access data with dependency analysis, the probability of accidental or missed deletions is significantly reduced;

[0259] Technical advantage 2) High degree of automation: From detection and analysis to cleaning, everything can be done automatically by the system;

[0260] Technical effect 3), risk controllable: the logging mechanism provides traceability and rollback capabilities;

[0261] Technical benefit 4) Code library simplification: Long-term operation can reduce project size, build time and maintenance complexity;

[0262] Technical benefits 5) High scalability: The solution can be applied to multiple projects or multiple platform environments and supports periodic automatic execution.

[0263] Figure 13 A schematic diagram of the structure of the redundant code determination device provided in the embodiments of this application is shown below. Figure 13 As shown, the device for determining the redundant code includes:

[0264] Module 131 retrieves access data corresponding to multiple page link data in the project to be processed and file dependency graph corresponding to the project to be processed.

[0265] The first determining module 132 is used to determine the target page link data that meets the preset conditions from the multiple page link data according to the access data corresponding to the multiple page link data respectively. The preset conditions are determined based on the preset duration and access threshold.

[0266] The second determination module 133 is used to determine the redundant code files that can be cleaned up based on the target page link data and file dependency graph;

[0267] Processing module 134 is used to clean up redundant code files.

[0268] In one or more embodiments, the second determining module 133 determines cleanable redundant code files based on the target page link data and file dependency graph, specifically for:

[0269] Obtain the list of the first referenced files and the full list of files in the file dependency graph. The full list of files is obtained by performing a full scan of the file system corresponding to the project to be processed.

[0270] Based on the first file list, the full file list, and the target page link data, identify redundant code files.

[0271] In one or more embodiments, the second determining module 133 determines redundant code files based on the first file list, the full file list, and the target page link data, specifically for:

[0272] By comparing the full file list and the first file list, the first code file that is not referenced by dependency paths and is not a necessary configuration file for the project to be processed is identified;

[0273] The intersection of the first code file and the second code file corresponding to the link data of the target page is identified as a redundant code file.

[0274] In one or more embodiments, the acquisition module 131 acquires the file dependency graph corresponding to the project to be processed, specifically for:

[0275] In the local environment corresponding to the project to be processed, obtain the path mapping relationship and the full file list of the project to be processed;

[0276] Based on the path mapping relationship, the full file list, and the link data of multiple pages, determine the file dependency graph.

[0277] In one or more embodiments, the acquisition module 131 determines a file dependency graph based on the path mapping relationship, the full file list, and multiple page link data, specifically for:

[0278] Using multiple page link data as the entry point, a dependency traversal analysis is performed on the full file list based on path mapping relationships to construct a file dependency graph.

[0279] In one or more embodiments, the acquisition module 131 acquires access data corresponding to multiple page link data in the project to be processed, specifically for:

[0280] Retrieve full routing information from the project to be processed. Full routing information includes: link data for multiple pages.

[0281] For each page link, access data corresponding to the page link is obtained through tracking tools or traffic monitoring tools.

[0282] In one or more embodiments, the first determining module 132 determines, based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions from the multiple page link data, specifically for:

[0283] For each page link data, determine the target access data that is less than or equal to the access threshold within a preset time period;

[0284] The page link data corresponding to each of the target access data is determined as the target page link data.

[0285] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical element, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls, or entirely in hardware. Alternatively, some modules can be implemented through processing element calls in software, while others can be implemented in hardware. Moreover, these modules can be integrated together or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0286] As can be seen from the above, the redundant code determination device provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.

[0287] Figure 14 A schematic diagram of the structure of the electronic device provided in this application. Figure 14 As shown, the electronic device provided in this embodiment includes at least one processor 141 and a memory 142.

[0288] Optionally, the electronic device also includes a communication component 143.

[0289] The processor 141, memory 142 and communication component 143 are connected via bus 144.

[0290] In a specific implementation, at least one processor 141 executes computer execution instructions stored in memory 142, causing at least one processor 141 to perform the above-described method.

[0291] The specific implementation process of processor 141 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0292] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0293] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0294] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0295] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0296] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0297] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0298] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0299] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0300] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0301] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0302] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0303] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0304] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.< / scriptsetup>

Claims

1. A method for determining redundant codes, characterized in that, include: Obtain the access data corresponding to multiple page link data in the project to be processed and the file dependency graph corresponding to the project to be processed; Based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions is determined from the multiple page link data. The preset conditions are determined based on preset duration and access threshold. Based on the target page link data and the file dependency graph, identify redundant code files that can be cleaned up.

2. The method according to claim 1, characterized in that, The step of determining the cleanable redundant code files based on the target page link data and the file dependency graph includes: Obtain the first file list and the full file list referenced in the file dependency graph. The full file list is a file list obtained by performing a full scan of the file system corresponding to the project to be processed. By comparing the full file list with the first file list, a first code file is identified that is not referenced by the dependency path and is not a necessary configuration file for the project to be processed. The intersection of the first code file and the second code file corresponding to the target page link data is determined as the redundant code file.

3. The method according to claim 2, characterized in that, Obtain the file dependency graph corresponding to the project to be processed, including: In the local environment corresponding to the project to be processed, obtain the path mapping relationship of the project to be processed and the full file list; The file dependency graph is determined based on the path mapping relationship, the full file list, and multiple page link data.

4. The method according to claim 3, characterized in that, The step of determining the file dependency graph based on the path mapping relationship, the full file list, and multiple page link data includes: Using the multiple page link data as the entry point, the dependency relationship of the full file list is traversed and analyzed based on the path mapping relationship to construct the file dependency relationship graph.

5. The method according to any one of claims 1-4, characterized in that, The process of obtaining access data corresponding to multiple page links in the project to be processed includes: Obtain the full routing information of the project to be processed, the full routing information including: the multiple page link data; For each page link, access data corresponding to the page link is obtained using tracking tools or traffic monitoring tools.

6. The method according to any one of claims 1-4, characterized in that, The step of determining the target page link data that meets preset conditions from the multiple page link data based on the access data corresponding to each of the multiple page link data includes: For each page link data corresponding to the access data, determine the target access data within the preset time period where the access data is less than or equal to the access threshold; The page link data corresponding to each of the target access data is determined as the target page link data.

7. A device for determining redundant codes, characterized in that, include: The acquisition module is used to acquire access data corresponding to multiple page link data in the project to be processed and the file dependency graph corresponding to the project to be processed. The first determining module is used to determine, based on the access data corresponding to the multiple page link data, target page link data that meets preset conditions from the multiple page link data, wherein the preset conditions are determined based on a preset duration and an access threshold. The second determining module is used to determine the redundant code files that can be cleaned up based on the target page link data and the file dependency graph.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images