Code dependency relationship acquisition method and device, electronic equipment and medium

Abstract

The embodiment of the invention provides a code dependency relationship obtaining method and device, electronic equipment and a medium, and belongs to the technical field of system operation and maintenance. The method comprises the steps of obtaining a project code, wherein the project code comprises a plurality of code modules; generating an information file for the project code, wherein the information file is used for representing a dependency relationship between first target code modules in the code modules; generating a visual dependency analysis component according to the information file, wherein the visual dependency analysis component comprises visual identifiers of multiple levels of code modules; and displaying the visual dependency analysis component. Thus, a user can visually view the dependency path of each code module through the component and accurately grasp the dependency relationship between the code modules, the time required by manual analysis and possible errors are reduced, and the efficiency and accuracy of code dependency relationship analysis are improved.

Description

Technical Field

[0001] The present application relates to the field of system operation and maintenance, and in particular to a method, device, electronic device and medium for obtaining code dependency relationships. Background Art

[0002] At present, in the relevant code analysis technology, the dependencies between multiple code module files are usually analyzed by manual inspection or using some simple tools. Although this method can barely cope with small projects, when the project scale continues to expand and the number of modules increases significantly, this manual or simple analysis method becomes inefficient and cannot meet development needs. As the complexity of the code increases, developers face more and more challenges. Manual processing may lead to omissions or errors, which in turn affects the stability and maintainability of the entire project. Therefore, relying on traditional methods for code analysis is not only time-consuming, but also risky. More efficient technical means are urgently needed to improve analysis efficiency and accuracy. Summary of the invention

[0003] The main purpose of the embodiments of the present application is to propose a code dependency acquisition method, device, electronic device and medium, aiming to improve the efficiency and accuracy of code dependency analysis.

[0004] To achieve the above purpose, a first aspect of an embodiment of the present application proposes a method for obtaining code dependency, the method comprising:

[0005] Obtaining a project code, wherein the project code includes a plurality of code modules;

[0006] Generate an information file for the project code, the information file being used to characterize the dependency relationship between the first target code modules in the plurality of code modules;

[0007] Generate a visual dependency analysis component according to the information file, wherein the visual dependency analysis component includes visual identifiers of code modules at multiple levels;

[0008] The visual dependency analysis component is displayed.

[0009] In some implementations, the plurality of code modules are all the first target code modules, and generating a visual dependency analysis component according to the information file includes:

[0010] According to the information file, the multiple code modules are grouped according to the dependency relationship to obtain multiple module groups, wherein the code modules in the same module group are dependent on the same code module;

[0011] Generating a dependency analysis tree according to the plurality of module groups, the dependency analysis tree comprising a plurality of levels formed by identifiers of the plurality of code modules, wherein a code module of an upper level depends on a code module of a lower level;

[0012] The target identifier in the dependency analysis tree is visualized to obtain the visualized dependency analysis component, wherein the target identifier is other identifiers in the dependency analysis tree except the first identifier, the first identifier is the identifier of a code module that depends on a preset vertex module, and the vertex module is a code module among the multiple code modules.

[0013] In some implementations, generating a dependency analysis tree according to the plurality of module groups includes:

[0014] Performing intra-group deduplication processing on the multiple module groups, wherein the intra-group deduplication processing is used to remove duplicate code modules in the module groups;

[0015] The dependency analysis tree is generated according to the multiple module groups obtained after the intra-group deduplication processing.

[0016] In some implementations, the generating an information file for the project code includes:

[0017] Determine, among the plurality of code modules, a code module other than a code module dependent on a preset vertex module as the first target code module, wherein the vertex module is a code module among the plurality of code modules;

[0018] generating the information file for the first target code module;

[0019] The generating of a visual dependency analysis component according to the information file comprises:

[0020] According to the information file, the first target code modules are grouped according to dependency relationships to obtain a plurality of module groups, wherein the first target code modules in the same module group are dependent on the same first target code module;

[0021] The visual dependency analysis component is generated according to the multiple module groups.

[0022] In some embodiments, the project code includes a baseline version and an updated version;

[0023] After generating the visual dependency analysis component according to the information file and before displaying the visual dependency analysis component, the method further includes:

[0024] Comparing the code modules included in the baseline version with the code modules included in the updated version to determine at least one second target code module having a code change;

[0025] Generate a change module dependency analysis component using the at least one second target code module and the information file, wherein the change module dependency analysis component includes a visual identifier of the at least one second target code module and a dependency relationship between each of the second target code modules and other code modules;

[0026] The change module dependency analysis component is added to the visualization dependency analysis component.

[0027] In some implementations, the plurality of code modules include a preset core module, and the importance of the core module is greater than a preset threshold;

[0028] After comparing the code modules included in the baseline version with the code modules included in the updated version to determine that at least one second target code module with code changes exists, the method further includes:

[0029] Determine, according to the information file, whether each of the second target codes is an associated module, wherein the associated module is a code module that depends on the core module, or a code module that is depended on by the core module;

[0030] In the case where the second target code is the associated module, a change prompt is sent to a user associated with the second target code.

[0031] In some implementations, obtaining a project code includes:

[0032] Acquire configuration information of the project code, the configuration information including a download address of the project code, and information of a baseline version and an updated version of the project code;

[0033] Determine whether a baseline version and an updated version of the project code exist locally according to the information of the baseline version and the information of the updated version;

[0034] When the base version and the updated version of the project code do not exist locally, the base version and the updated version of the project code are obtained by using the download address.

[0035] To achieve the above purpose, a second aspect of an embodiment of the present application provides a device for acquiring code dependency, the device comprising:

[0036] An acquisition module, used for acquiring a project code, wherein the project code includes a plurality of code modules;

[0037] A first generating module, used for generating an information file for the project code, wherein the information file is used for characterizing the dependency relationship between the first target code modules in the plurality of code modules;

[0038] A second generating module, configured to generate a visual dependency analysis component according to the information file, wherein the visual dependency analysis component includes visual identifiers of code modules at multiple levels;

[0039] A display module is used to display the visual dependency analysis component.

[0040] To achieve the above-mentioned purpose, the third aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the code dependency acquisition method described in the first aspect when executing the computer program.

[0041] To achieve the above objectives, the fourth aspect of an embodiment of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the code dependency acquisition method described in the first aspect above.

[0042] The code dependency acquisition method, device, electronic device and medium proposed in the present application, the electronic device first automatically obtains the project code containing multiple code modules and generates an information file to characterize the dependency relationship between the modules, especially the dependency relationship between multiple first target code modules. Relying on this information file, the electronic device generates a multi-level visual dependency analysis component, so that the hierarchical dependency relationship between the code modules can be clearly displayed. Through this component, the user can intuitively view the dependency path of each code module and accurately grasp the dependency relationship between code modules, which reduces the time required for manual analysis and possible errors, and improves the efficiency and accuracy of code dependency analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 It is a flowchart of a method for obtaining code dependency relationships provided in an embodiment of the present application;

[0044] Figure 2 It is a flowchart of the component generation process provided by the embodiment of the present application;

[0045] Figure 3 It is a flowchart of the code change analysis process provided by the embodiment of the present application;

[0046] Figure 4 It is a flowchart of the code acquisition process provided by the embodiment of the present application;

[0047] Figure 5It is a structural diagram of a code dependency acquisition device provided in an embodiment of the present application;

[0048] Figure 6 It is a schematic diagram of the hardware structure of the electronic device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0050] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0052] First, some nouns involved in this application are analyzed:

[0053] Code Analysis: Code analysis, especially the analysis of dependencies between code modules, refers to the systematic method of identifying and displaying the interdependencies between modules.

[0054] Dependencies between code modules can be understood as "the input data is the output data of another module". This relationship exists in many systems. For example, in a data processing pipeline, data may be passed from one module to the next, and each module depends on the output of the previous module. The core of module dependency lies in the relationship between the functions of modules: if the output of module A is the input of module B, then module B depends on module A.

[0055] Module dependency analysis is designed to help developers clearly understand the project structure, making the code reference relationship, call chain and module coupling level clear at a glance. Through code dependency analysis, developers can accurately identify the impact that changes to a module may have on other modules, which is particularly critical for large projects because the module hierarchy and reference relationships are complex. Inter-module dependency analysis can not only improve code maintenance efficiency, but also effectively reduce errors or performance issues caused by excessive module coupling.

[0056] At present, in the relevant code analysis technology, the dependencies between multiple code module files are usually analyzed by manual inspection or using some simple tools. Although this method can barely cope with small projects, when the project scale continues to expand and the number of modules increases significantly, this manual or simple analysis method becomes inefficient and cannot meet development needs. As the complexity of the code increases, developers face more and more challenges. Manual processing may lead to omissions or errors, which in turn affects the stability and maintainability of the entire project. Therefore, relying on traditional methods for code analysis is not only time-consuming, but also risky. More efficient technical means are urgently needed to improve analysis efficiency and accuracy.

[0057] Based on this, the embodiments of the present application provide a code dependency acquisition method, device, electronic device and medium, aiming to improve the efficiency and accuracy of code dependency analysis.

[0058] The code dependency acquisition method, device, electronic device and medium provided in the embodiments of the present application are specifically described through the following embodiments. First, the code dependency acquisition method in the embodiments of the present application is described.

[0059] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) 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 knowledge to obtain the best results.

[0060] AI basic technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. AI software technologies mainly include computer vision technology, robotics technology, biometrics technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0061] The code dependency acquisition method provided in the embodiment of the present application relates to the field of system operation and maintenance technology. The code dependency acquisition method provided in the embodiment of the present application can be applied to a terminal, can be applied to a server side, or can be software running in a terminal or a server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server side can be configured as an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the code dependency acquisition method, etc., but is not limited to the above forms.

[0062] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0063] It should be noted that in each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0064] See also Figure 1 , Figure 1It is a flow chart of a method for obtaining code dependencies provided in an embodiment of the present application. In a first aspect, an embodiment of the present application provides a method for obtaining code dependencies, comprising the following steps S110 to S140.

[0065] Step S110: Obtain a project code, where the project code includes multiple code modules.

[0066] The electronic device first needs to obtain the project code, which includes multiple related code modules. These code modules form the basis of the entire project, and analyzing the dependencies between these code modules is the key to the subsequent steps.

[0067] For example, there is an e-commerce platform project, and the project code includes modules User.js, Product.js, Cart.js, and Payment.js. The electronic device obtains and loads all these modules for subsequent dependency analysis.

[0068] Step S120: Generate an information file for the project code, where the information file is used to characterize the dependency relationship between the first target code modules in the plurality of code modules.

[0069] The electronic device analyzes the acquired project code, identifies the dependencies between the code modules, and generates an information file that records in detail the dependencies between the modules, especially the association with the first target code module.

[0070] Electronic devices can use the Webpack packaging tool to generate the information file. Webpack is the most popular static module packaging tool for modern web development. When Webpack is packaging, it will build a dependency graph from one or more entry points internally, and then combine each module required in the project into one or more bundles, which are all static resources. Whenever a file depends on another file, Webpack will treat the files as directly dependent. In the method provided in the embodiment of the present application, Webpack can be used to package the project code, and the dependency graph constructed is used as the above-mentioned information file (that is, the core purpose of using Webpack for "packaging" in the method provided in the embodiment of the present application is to build a file for dependency analysis, rather than directly outputting the resource file of the project code accessed by the user).

[0071] Exemplarily, during the analysis process of the electronic device, the electronic device recognizes that Payment.js depends on User.js and Cart.js, and the generated information file will record such dependency.

[0072] Step S130: Generate a visual dependency analysis component according to the information file, where the visual dependency analysis component includes visual identifiers of code modules at multiple levels.

[0073] The electronic device uses the generated information file to build a visual dependency analysis component. This component will display the dependency relationship between code modules in the form of a hierarchical structure, and each code module at each level will be its own visual identifier, so that technicians can intuitively understand the module dependency path.

[0074] Exemplarily, the electronic device uses the information file to construct a tree-like visual dependency analysis component. This structure clearly shows that Payment.js depends on User.js and Cart.js, and Cart.js depends on Product.js.

[0075] Step S140: Displaying a visual dependency analysis component.

[0076] The electronic device presents the generated visual dependency analysis component to the users of the code analysis platform. Users can use this component to quickly view and analyze the dependencies between code modules, helping them maintain and update the code.

[0077] For example, the electronic device publishes and deploys the visual dependency analysis component to the code analysis platform. Users can see the generated visual dependency analysis component on the code analysis platform. They can click on Payment.js to view the specific modules it depends on, which helps them evaluate the impact on other modules when making functional modifications. This visual display significantly improves the efficiency of code understanding and analysis.

[0078] Through the above steps S110-S140, the electronic device first automatically obtains the project code containing multiple code modules and generates an information file to characterize the dependencies between the modules, especially the dependencies between multiple first target code modules. Relying on this information file, the electronic device generates a multi-level visual dependency analysis component to clearly display the hierarchical dependencies between the code modules. Through this component, technicians can intuitively view the dependency paths of each code module and accurately grasp the dependencies between code modules, reducing the time required for manual analysis and possible errors, and improving the efficiency and accuracy of code dependency analysis.

[0079] See also Figure 2 , Figure 2 : is a flowchart of a component generation process provided by an embodiment of the present application. In some implementations, multiple code modules are first target code modules, and a visual dependency analysis component is generated according to an information file, including:

[0080] Step S210: according to the information file, multiple code modules are grouped according to dependency relationships to obtain multiple module groups, where code modules in the same module group are dependent on the same code module;

[0081] Step S220: generating a dependency analysis tree according to the plurality of module groups, wherein the dependency analysis tree includes a plurality of levels formed by identifiers of a plurality of code modules, wherein a code module of an upper level depends on a code module of a lower level;

[0082] Step S230: Visualize the target identifier in the dependency analysis tree to obtain a visualized dependency analysis component, wherein the target identifier is other identifiers in the dependency analysis tree except the first identifier, the first identifier is the identifier of the code module that depends on the preset vertex module, and the vertex module is a code module among multiple code modules.

[0083] In this embodiment, the multiple code modules included in the project code are all regarded as the first target code modules, and the electronic device groups the modules according to the dependency relationship according to the information file, thereby obtaining multiple module groups. The code modules in each module group are all dependent on the same other code modules, ensuring the accuracy and logic of the dependency relationship.

[0084] Next, the electronic device generates a dependency analysis tree based on these module groups. The tree consists of multiple levels of code module identifiers, where the code modules of the previous level depend on the code modules of the next level. This analysis tree can clearly show the dependency relationship between modules and facilitate subsequent analysis and maintenance.

[0085] Finally, the electronic device visualizes the target identifier in the dependency analysis tree to obtain the visualized dependency analysis component. The target identifier is the identifier other than the first identifier in the dependency analysis tree, and the first identifier is the identifier of all code modules that depend on the vertex module. The vertex module is preset by the user in multiple code modules of the project code as the starting point of the visualized dependency analysis component finally obtained.

[0086] In simple terms, the user presets a vertex module, and the electronic device removes all code modules that depend on the vertex module in the dependency analysis tree, and only visualizes the remaining parts, so that the final visualization dependency analysis component starts with the preset vertex module. In terms of specific operations, the electronic device can traverse all code modules in the dependency analysis tree, and when the identifier named vertex module is identified, the traversal ends and no visualization is performed. In this way, users can flexibly customize the vertex modules of their own projects and ignore unnecessary code modules in dependency analysis.

[0087] For example, assume that there are code modules ModuleA.js, ModuleB.js, ModuleC.js, and ModuleD.js. In this example, ModuleA.js is set as the apex module, ModuleB.js depends on ModuleA.js, ModuleA.js depends on ModuleC.js and ModuleD.js, ModuleD.js depends on ModuleC.js, and ModuleC.js depends on ModuleB.js. According to the information file, the electronic device groups these modules according to the dependency relationship to form multiple module groups. For example: (key is used to identify each module group, meaning that the code modules in the module group are all dependent on the code module represented by key)

[0088] Module group 1 (key is ModuleB.js): ModuleA.js;

[0089] Module group 2 (key is ModuleA.js): ModuleC.js, ModuleD.js;

[0090] Module group 3 (key is ModuleD.js): ModuleC.js;

[0091] Module group 4 (key is ModuleC.js): ModuleB.js;

[0092] Next, the dependency analysis tree generated by the electronic device will show a four-layer hierarchical structure, the first layer is ModuleB.js, the second layer is ModuleA.js, the third layer is ModuleC.js and ModuleD.js, the fourth layer is ModuleC.js (connected to ModuleD.js on the third layer), and ModuleB.js (connected to ModuleC.js on the third layer);

[0093] Finally, the electronic device visualizes the part of this analysis tree except the first level as the final visual dependency analysis component to help users clearly understand the dependency relationship and hierarchical structure between modules.

[0094] In some implementations, generating a dependency analysis tree according to a plurality of module groups includes:

[0095] Perform intra-group deduplication processing on multiple module groups, where the intra-group deduplication processing is used to remove duplicate code modules in the module groups;

[0096] A dependency analysis tree is generated based on multiple module groups obtained after performing intra-group deduplication processing.

[0097] In this embodiment, the electronic device first performs intra-group deduplication processing on the multiple module groups. The main function of this processing step is to remove repeated code modules in the module group to ensure that each module appears only once in its group.

[0098] After completing the deduplication within the group, the electronic device will generate a dependency analysis tree based on the obtained multiple module groups. The analysis tree shows the hierarchical dependency relationship between the code modules, allowing developers to intuitively understand the interaction and dependency path between modules.

[0099] This deduplication process not only improves the accuracy of the data, but also lays the foundation for subsequent analysis. The resulting dependency analysis tree not only clearly displays the hierarchical structure of the code modules, but also ensures the uniqueness of each module in the tree, making it easier for users to perform more efficient code analysis and maintenance.

[0100] For example, assume that there are the following multiple module groups:

[0101] Module Group 1: ModuleA.js, ModuleB.js, ModuleA.js (repeated)

[0102] Module Group 2: ModuleC.js, ModuleD.js, ModuleC.js (duplicate)

[0103] After deduplication within the group, the module group will become:

[0104] Module Group 1: ModuleA.js, ModuleB.js

[0105] Module Group 2: ModuleC.js, ModuleD.js

[0106] Subsequently, the electronic device generates a dependency analysis tree based on these deduplicated module groups.

[0107] In some implementations, an information file is generated for the project code, including:

[0108] Determine a code module among the multiple code modules, except for a code module that depends on a preset vertex module, as a first target code module, wherein the vertex module is a code module among the multiple code modules;

[0109] generating an information file for the first object code module;

[0110] Generate visual dependency analysis components based on information files, including:

[0111] According to the information file, the first target code modules are grouped according to dependency relationships to obtain a plurality of module groups, wherein the first target code modules in the same module group are dependent on the same first target code module;

[0112] Generate visual dependency analysis components based on multiple module groups.

[0113] In this embodiment, the electronic device first determines the first target code modules from the multiple code modules in the project code, which are other code modules except those that depend on the preset vertex modules. The vertex modules are preset by the user in the multiple code modules of the project code as the starting point of the visual dependency analysis component finally obtained. The electronic device marks all modules that meet the conditions as the first target code modules and generates information files for these modules. The information files record the dependency relationships between the first target code modules for further grouping and analysis.

[0114] Next, the electronic device groups the dependencies of these first target code modules according to the information file. The grouping rule is: modules that are dependent on the same module are divided into the same module group, thereby forming multiple module groups. Subsequently, the electronic device generates a visual dependency analysis component based on these module groups, which intuitively displays the dependency relationship between modules in a hierarchical manner and provides users with a clear module structure diagram. In this way, users can flexibly customize the vertex modules of their own projects, ignore unnecessary code modules, and prevent them from participating in the generation of information files that characterize dependency relationships.

[0115] For example, assume that there are code modules ModuleA.js, ModuleB.js, ModuleC.js, and ModuleD.js. In this example, ModuleA.js is set as the vertex module, ModuleB.js depends on ModuleA.js, ModuleA.js depends on ModuleC.js and ModuleD.js, and ModuleD.js depends on ModuleC.js. The electronic device determines ModuleA.js, ModuleC.js, and ModuleD.js as the first target code modules, generates an information file representing their dependency relationship, and then uses the information file to group them, and finally uses the multiple module groups obtained by grouping to generate a visual dependency analysis component.

[0116] See also Figure 3 , Figure 3 is a flowchart of a code change analysis process provided in an embodiment of the present application. In some implementations, the project code includes a baseline version and an updated version;

[0117] After generating the visual dependency analysis component according to the information file and before displaying the visual dependency analysis component, the method further includes:

[0118] Step S310: Compare the code modules included in the baseline version with the code modules included in the updated version to determine at least one second target code module with code changes;

[0119] Step S320: Generate a module dependency analysis component using at least one second target code module and the information file, where the module dependency analysis component includes a visual identifier of at least one second target code module and a dependency relationship between each second target code module and other code modules;

[0120] Step S330: adding the changed module dependency analysis component to the visual dependency analysis component.

[0121] In this implementation, the project code includes a baseline version and an updated version. The baseline version refers to the stable version of the project. It is usually used for comparison to understand the difference between the newly developed version or code and the stable version. The updated version is the version currently under development, which contains the modified content of this update or new function. By comparing it with the baseline version, it is possible to detect which code changes are in this update.

[0122] The electronic device compares the code modules in the baseline version with the code modules in the updated version, and identifies at least one second target code module with code changes, thereby ensuring that the user can quickly locate the module that has changed in the update.

[0123] Next, the electronic device uses the identified second target code module and the previously generated information file to construct a change module dependency analysis component. The component not only includes a visual identification of the second target code module, but also displays the dependency relationship between each second target code module and other code modules. By integrating the change module dependency analysis component into the visual dependency analysis component, the user can more comprehensively understand the impact of the code change and related dependencies.

[0124] For example, assume that the baseline version of the project contains modules User.js and Payment.js, while the updated version adds Order.js and modifies Payment.js. After comparison, the electronic device identifies Payment.js as the second target code module with changes. Then, based on the previously generated information file, the electronic device creates a changed module dependency analysis component to display the dependency relationship between Payment.js and User.js and Order.js. This integrated visual display can help users quickly understand the impact of the update on the overall structure of the project and the dependencies between related modules.

[0125] In some implementations, the plurality of code modules include a preset core module, and the importance of the core module is greater than a preset threshold;

[0126] After comparing the code modules included in the baseline version with the code modules included in the updated version and determining that at least one second target code module with code changes exists, the method further includes:

[0127] Determine whether each second target code is an associated module according to the information file, the associated module being a code module that depends on the core module, or a code module that is depended on by the core module;

[0128] In the case where the second target code is an associated module, a change prompt is sent to a user associated with the second target code.

[0129] In this embodiment, multiple code modules in the project include preset core modules. The importance of these modules exceeds the set threshold, which represents the code modules that are critical in the project and need special attention. These modules may be the core parts of the business, such as payment logic, user authentication, etc. Core modules usually need to be monitored intensively.

[0130] After the electronic device compares the code of the baseline version and the updated version, it identifies at least one second target code module that has changed. Next, the electronic device determines whether each second target code module is an associated module based on the information file, that is, whether the module depends on the core module or is relied upon by the core module. If a second target code module is confirmed to be an associated module, the electronic device will automatically send a change reminder to the user related to the module to ensure that changes in key modules can be noticed in time.

[0131] For example, assume that in the project code, Auth.js is set as a core module because it is responsible for user identity authentication and its importance exceeds the threshold. In an update, the electronic device identifies that the Payment.js and Order.js modules have changed. The electronic device then checks the dependencies of these changed modules with the core module Auth.js, and finds that Payment.js depends on Auth.js, so it identifies Payment.js as an associated module. Subsequently, the electronic device sends a change notification to the developer responsible for the Payment.js module, reminding him to pay attention to the potential impact caused by the dependency to ensure the security and stability of the project.

[0132] See also Figure 4 , Figure 4 : is a flowchart of a code acquisition process provided in an embodiment of the present application. In some implementations, acquiring a project code includes:

[0133] Step S410: Acquire configuration information of the project code, the configuration information including the download address of the project code, and information of the base version and updated version of the project code;

[0134] Step S420: Determine whether a baseline version and an updated version of the project code exist locally according to the information of the baseline version and the information of the updated version;

[0135] Step S430: When the baseline version and the updated version of the project code do not exist locally, the baseline version and the updated version of the project code are obtained using the download address.

[0136] In this embodiment, the step of obtaining the project code includes first obtaining the configuration information of the project code, which includes the download address of the project code, as well as the information of the base version and the updated version. Next, the electronic device will determine whether the base version and the updated version of the project code already exist locally based on this information. This check ensures that the electronic device can promptly identify the code version that needs to be updated or downloaded.

[0137] If the baseline version and updated version of the project code do not exist locally, the electronic device will use the obtained download address to obtain the two versions of the project code from the remote source. This approach ensures that developers can always obtain the latest and most complete project code to support subsequent analysis and development work.

[0138] Example: Assume that the configuration information of a project contains the following: the download address is https: / / example.com / project.git, the baseline version information is v1.0.0, and the updated version information is v1.1.0. In the process of obtaining the code, the electronic device first checks whether the two versions v1.0.0 and v1.1.0 exist locally. If it is found that neither version exists, the electronic device will automatically download the baseline version and the updated version of the code from the download address https: / / example.com / project.git. This ensures that the developer has the latest code version when he starts working, which is convenient for subsequent dependency analysis and development tasks.

[0139] Based on the above multiple implementations, the method provided in the embodiments of the present application can be described as follows:

[0140] During the implementation process, the acquisition of project code first includes obtaining configuration information, which includes the download address of the project code, as well as information about the baseline version and updated version of the project code. The electronic device will check whether the baseline version and updated version of the project code exist locally based on this information. If these two versions are not found locally, the electronic device will use the download address to obtain the required code version from the remote warehouse, ensuring that developers can always obtain the latest and most complete project code.

[0141] Once the project code is successfully acquired, the electronic device will generate information files for these code modules to record the dependencies between the modules. Specifically, the electronic device will determine the modules among the multiple code modules, except for the code modules that depend on the preset vertex modules, as the first target code modules. By analyzing these first target code modules, the electronic device can establish the dependencies between the modules and generate corresponding information files.

[0142] When generating a visual dependency analysis component, the electronic device groups the first target code module by dependency relationship to obtain multiple module groups. The code modules in each module group are dependent on the same code module, forming a clear dependency structure. Based on these module groups, the electronic device further generates a dependency analysis tree, and the hierarchical structure intuitively shows the relationship between the code module of the previous level and the code module of the next level.

[0143] In addition, the electronic device will analyze the identified second object code modules that have changed in the updated version. The electronic device will determine whether these modules are associated modules, that is, modules that depend on the core module or are depended on by the core module. For any second object code identified as an associated module, the electronic device will promptly send change notifications to the relevant developers to ensure that changes in key functions can receive appropriate attention.

[0144] Through this series of operations, electronic devices can provide developers with detailed code dependency analysis, ensuring that they can clearly understand the relationship between modules when maintaining and updating the code, reduce potential errors and risks, and improve the overall code quality and project stability. This method is not only suitable for small projects, but can also effectively meet the needs of dependency analysis between code modules in large and complex projects.

[0145] See also Figure 5 The embodiment of the present application further provides a device 500 for acquiring code dependency relationships, which can implement the above-mentioned method for acquiring code dependency relationships. The device 500 includes:

[0146] An acquisition module 510 is used to acquire a project code, where the project code includes multiple code modules;

[0147] A first generating module 520, used to generate an information file for the project code, where the information file is used to characterize the dependency relationship between the first target code modules in the plurality of code modules;

[0148] A second generating module 530 is used to generate a visual dependency analysis component according to the information file, wherein the visual dependency analysis component includes visual identifiers of code modules at multiple levels;

[0149] The display module 540 is used to display the visual dependency analysis component.

[0150] In some implementations, the plurality of code modules are first target code modules, and the second generation module 530 includes:

[0151] A grouping unit, used for grouping a plurality of code modules according to dependency relationships according to the information file, and obtaining a plurality of module groups, wherein the code modules in the same module group are dependent on the same code module;

[0152] An analysis tree generation unit, configured to generate a dependency analysis tree according to the plurality of module groups, wherein the dependency analysis tree comprises a plurality of levels formed by identifiers of a plurality of code modules, wherein a code module of an upper level depends on a code module of a lower level;

[0153] A visualization unit is used to visualize the target identifier in the dependency analysis tree to obtain a visualization dependency analysis component, wherein the target identifier is other identifiers in the dependency analysis tree except the first identifier, the first identifier is the identifier of the code module that depends on the preset vertex module, the vertex module is a code module among multiple code modules, and the vertex module is not dependent on other code modules.

[0154] In some implementations, the analysis tree generation unit includes:

[0155] A deduplication subunit is used to perform intra-group deduplication processing on multiple module groups, and the intra-group deduplication processing is used to remove duplicate code modules in the module group;

[0156] The generation subunit is used to generate a dependency analysis tree according to multiple module groups obtained after performing intra-group deduplication processing.

[0157] In some implementations, the first generation module 520 includes:

[0158] A determining unit, configured to determine, among the plurality of code modules, a code module other than a code module dependent on a preset vertex module as a first target code module, the vertex module being a code module among the plurality of code modules, and the vertex module being not dependent on by other code modules;

[0159] A generating unit, configured to generate information files for a plurality of first target code modules;

[0160] The second generation module 530 includes:

[0161] A grouping unit, configured to group the plurality of first target code modules according to the dependency relationship according to the information file, and obtain a plurality of module groups, wherein the first target code modules in the same module group are dependent on the same first target code module;

[0162] A generation unit is used to generate a visual dependency analysis component according to multiple module groups.

[0163] In some embodiments, the project code includes a baseline version and an updated version;

[0164] The apparatus 500 further comprises:

[0165] A comparison unit, configured to compare the code modules included in the baseline version with the code modules included in the updated version, and determine at least one second target code module having a code change;

[0166] A generating unit, configured to generate a change module dependency analysis component using at least one second target code module and an information file, wherein the change module dependency analysis component includes a visual identifier of at least one second target code module and a dependency relationship between each second target code module and other code modules;

[0167] The adding unit is used to add the change module dependency analysis component to the visual dependency analysis component.

[0168] In some implementations, the plurality of code modules include a preset core module, and the importance of the core module is greater than a preset threshold;

[0169] The apparatus 500 further comprises:

[0170] an association determination unit, configured to determine, according to the information file, whether each second target code is an associated module, wherein the associated module is a code module that depends on the core module, or a code module that is depended on by the core module;

[0171] The prompt sending unit is used to send a change prompt to a user associated with the second target code when the second target code is an associated module.

[0172] In some implementations, the acquisition module 510 includes:

[0173] An acquisition unit, used to acquire configuration information of the project code, the configuration information including a download address of the project code, and information of a baseline version and an updated version of the project code;

[0174] A determination unit, used to determine whether a baseline version and an updated version of the project code exist locally according to the information of the baseline version and the information of the updated version;

[0175] The download unit is used to obtain the baseline version and the updated version of the project code by using the download address when the baseline version and the updated version of the project code do not exist locally.

[0176] The specific implementation of the code dependency acquisition device 500 is basically the same as the specific implementation of the above-mentioned code dependency acquisition method, and will not be repeated here.

[0177] The embodiment of the present application also provides an electronic device, the electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the above-mentioned code dependency acquisition method when executing the computer program. The electronic device can be any intelligent terminal including a tablet computer, a car computer, etc.

[0178] See also Figure 6 , Figure 6 The hardware structure of an electronic device of another embodiment is illustrated, and the electronic device includes:

[0179] The processor 601 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0180] The memory 602 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 602, and the processor 601 calls and executes the code dependency acquisition method of the embodiment of this application;

[0181] Input / output interface 603, used to implement information input and output;

[0182] Communication interface 604, used to realize communication interaction between the device and other devices, which can be realized by wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WIFI, Bluetooth, etc.);

[0183] Bus 605 , which transmits information between various components of the device (e.g., processor 601 , memory 602 , input / output interface 603 , and communication interface 604 );

[0184] The processor 601 , the memory 602 , the input / output interface 603 and the communication interface 604 are connected to each other in communication within the device via a bus 605 .

[0185] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned code dependency acquisition method is implemented.

[0186] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0187] The code dependency acquisition method, device, electronic device and medium provided in the embodiments of the present application, the electronic device first automatically obtains the project code containing multiple code modules, and generates an information file, thereby characterizing the dependency relationship between the modules, especially the dependency relationship between multiple first target code modules. Relying on this information file, the electronic device generates a multi-level visual dependency analysis component, so that the hierarchical dependency relationship between the code modules can be clearly displayed. Through this component, technicians can intuitively view the dependency path of each code module, accurately grasp the dependency relationship between code modules, reduce the time required for manual analysis and possible errors, and improve the efficiency and accuracy of code dependency analysis.

[0188] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0189] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0190] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0191] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0192] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0193] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0194] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0196] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0197] If the integrated unit is implemented in the form of 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 the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0198] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

Claims

1. A method for obtaining code dependency, characterized in that: The method comprises: Obtaining a project code, wherein the project code includes a plurality of code modules; Generate an information file for the project code, the information file being used to characterize the dependency relationship between the first target code modules in the plurality of code modules; Generate a visual dependency analysis component according to the information file, wherein the visual dependency analysis component includes visual identifiers of code modules at multiple levels; The visual dependency analysis component is displayed.

2. The method according to claim 1, characterized in that The plurality of code modules are all the first target code modules, and generating a visual dependency analysis component according to the information file includes: According to the information file, the multiple code modules are grouped according to the dependency relationship to obtain multiple module groups, wherein the code modules in the same module group are dependent on the same code module; Generating a dependency analysis tree according to the plurality of module groups, the dependency analysis tree comprising a plurality of levels formed by identifiers of the plurality of code modules, wherein a code module of an upper level depends on a code module of a lower level; The target identifier in the dependency analysis tree is visualized to obtain the visualized dependency analysis component, wherein the target identifier is other identifiers in the dependency analysis tree except the first identifier, the first identifier is the identifier of a code module that depends on a preset vertex module, and the vertex module is a code module among the multiple code modules.

3. The method according to claim 2, characterized in that The step of generating a dependency analysis tree according to the plurality of module groups comprises: Performing intra-group deduplication processing on the multiple module groups, wherein the intra-group deduplication processing is used to remove duplicate code modules in the module groups; The dependency analysis tree is generated according to the multiple module groups obtained after the intra-group deduplication processing.

4. The method according to claim 1, characterized in that: The information file generated for the project code includes: Determine, among the plurality of code modules, a code module other than a code module dependent on a preset vertex module as the first target code module, wherein the vertex module is a code module among the plurality of code modules; generating the information file for the first target code module; The generating of a visual dependency analysis component according to the information file comprises: According to the information file, the first target code modules are grouped according to dependency relationships to obtain a plurality of module groups, wherein the first target code modules in the same module group are dependent on the same first target code module; The visual dependency analysis component is generated according to the multiple module groups.

5. The method according to claim 1, characterized in that The project code includes a baseline version and an updated version; After generating the visual dependency analysis component according to the information file and before displaying the visual dependency analysis component, the method further includes: Comparing the code modules included in the baseline version with the code modules included in the updated version to determine at least one second target code module having a code change; Generate a change module dependency analysis component using the at least one second target code module and the information file, wherein the change module dependency analysis component includes a visual identifier of the at least one second target code module and a dependency relationship between each of the second target code modules and other code modules; The change module dependency analysis component is added to the visualization dependency analysis component.

6. The method according to claim 5, characterized in that The multiple code modules include a preset core module, and the importance of the core module is greater than a preset threshold; After comparing the code modules included in the baseline version with the code modules included in the updated version to determine that at least one second target code module with code changes exists, the method further includes: Determine, according to the information file, whether each of the second target codes is an associated module, wherein the associated module is a code module that depends on the core module, or a code module that is depended on by the core module; In the case where the second target code is the associated module, a change prompt is sent to a user associated with the second target code.

7. The method according to claim 1, characterized in that The obtaining of the project code comprises: Acquire configuration information of the project code, the configuration information including a download address of the project code, and information of a baseline version and an updated version of the project code; Determine whether a baseline version and an updated version of the project code exist locally according to the information of the baseline version and the information of the updated version; When the base version and the updated version of the project code do not exist locally, the base version and the updated version of the project code are obtained by using the download address.

8. A device for acquiring code dependency, characterized in that: The device comprises: An acquisition module, used for acquiring a project code, wherein the project code includes a plurality of code modules; A first generating module, used for generating an information file for the project code, wherein the information file is used for characterizing the dependency relationship between the first target code modules in the plurality of code modules; A second generating module, configured to generate a visual dependency analysis component according to the information file, wherein the visual dependency analysis component includes visual identifiers of code modules at multiple levels; A display module is used to display the visual dependency analysis component.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the code dependency acquisition method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the code dependency acquisition method described in any one of claims 1 to 7 is implemented.

Images