A code item adaptation method and related device

Abstract

The embodiment of the specification discloses a code project adaptation method and related equipment, and relates to the technical field of computers. In the specification, the code project is statically analyzed and running data is collected to obtain metadata corresponding to the code project, the metadata is structurally processed based on the format of a target specification, and the structurally processed result is mapped based on a mapping rule to obtain a baseline specification, so that the baseline specification is compared with the target specification to obtain a difference result, an adaptation rule set corresponding to the code project is generated according to the difference result, and finally, an adaptation agent layer corresponding to the code project is generated according to the adaptation rule set. The adaptation agent layer is used to call the code project based on the target specification.

Description

Technical Field

[0001] This manual relates to the field of computer technology, and in particular to a code project adaptation method and related equipment. Background Technology

[0002] With the rapid development of artificial intelligence technology, specification-driven AI Coding has gradually become an important technical standard in the field of software engineering. This technical standard uses structured, parsable, and executable technical specifications (Spec) as core input data. Through an artificial intelligence code generation model, it automatically generates consistent code based on the technical specifications, thereby achieving synchronous maintenance of specifications and code, and improving the automation level and engineering consistency of software development.

[0003] However, in actual software engineering practice, many existing legacy code projects already in operation generally suffer from inherent problems such as a lack of complete technical specification documents, inconsistencies between interface definitions and implementation code, heterogeneous system architecture, and high coupling between modules. These code projects typically rely on outdated frameworks or third-party components, and after long-term iterations, they develop complex transaction logic and call relationships.

[0004] If specification-driven AI coding technology is directly applied to existing code projects, it requires manual steps such as line-by-line interpretation, reverse engineering of business logic, and manual completion of technical specifications before the code project can be restructured to adapt to the specification-driven model. This process is not only lengthy and costly, but also prone to introducing new defects due to misunderstandings of complex code projects, making it difficult for existing code projects to be smoothly integrated into the specification-driven AI coding system. Summary of the Invention

[0005] This specification provides a code project adaptation method and related equipment to solve the above-mentioned problems. The technical solution is as follows: Firstly, embodiments of this specification provide a code project adaptation method, the method comprising: Static analysis and runtime data collection are performed on the code project to obtain the metadata corresponding to the code project. The metadata is structured based on the target specification format, and the structured processing result is mapped based on mapping rules to obtain the baseline specification. The baseline specification is compared with the target specification to obtain the difference results, and an adaptation rule set corresponding to the code project is generated based on the difference results; Based on the set of adaptation rules, an adaptation proxy layer corresponding to the code project is generated; wherein, the adaptation proxy layer is used to call the code project based on the target specification.

[0006] Secondly, embodiments of this specification provide a code project adaptation device, the device comprising: The data acquisition module is used to perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project. The baseline specification module is used to perform structured processing on the metadata based on the format of the target specification, and to map the structured processing result to obtain the baseline specification based on the mapping rules. The adaptation rules module is used to compare the baseline specification with the target specification to obtain the difference results, and generate an adaptation rule set corresponding to the code project based on the difference results; The proxy generation module is used to generate an adaptation proxy layer corresponding to the code project according to the adaptation rule set; wherein the adaptation proxy layer is used to call the code project based on the target specification.

[0007] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0008] Fourthly, embodiments of this specification provide a computer program product that stores multiple instructions adapted for loading by a processor and executing the above-described method steps.

[0009] Fifthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0010] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In the embodiments of this specification, static parsing and runtime data collection are performed simultaneously on the code project to obtain the metadata corresponding to the code project. This ensures that the metadata includes both static metadata reflecting source code information and dynamic metadata reflecting actual runtime behavior information, providing a comprehensive data foundation for generating the baseline specification. Furthermore, the metadata is structured based on the target specification's format, and the structured processing results are mapped using mapping rules to obtain the baseline specification. This allows the baseline specification to represent the actual interface behavior of the code project using the unified semantic paradigm defined by the target specification, enabling it to be parsed and used by the target specification system. Further, the baseline specification is compared with the target specification to obtain the difference results, and a set of adaptation rules corresponding to the code project is generated based on these differences. Each adaptation rule in the set closely corresponds to the actual difference between the code project and the target specification, ensuring the accuracy of the adaptation rule set without requiring manual organization and writing of adaptation logic. Finally, an adaptation proxy layer corresponding to the code project is generated based on the adaptation rule set. This adaptation proxy layer responds to call requests and provides the services corresponding to the code project, achieving compatibility between the code project and the target specification system. In other words, the embodiments in this specification achieve full-process automation of adaptation without modifying the core code and logic of the code project, thus avoiding the risk of stability damage caused by intrusive adaptation modifications. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the architecture of a code project adaptation method provided in the embodiments of this specification; Figure 2 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 1 ; Figure 3 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 2 ; Figure 4 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 3 ; Figure 5 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 4 ; Figure 6This is a schematic diagram of a process for obtaining target invocation behavior provided in the embodiments of this specification. Figure 5 ; Figure 7 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 6 ; Figure 8 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 7 ; Figure 9 This is a schematic diagram of the structure of a code project adaptation device provided in the embodiments of this specification; Figure 10 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

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

[0014] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0015] The present specification will now be described in detail with reference to specific embodiments.

[0016] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, information, and data involved in this specification were all obtained under full authorization.

[0017] like Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of a code project adaptation method provided in the embodiments of this specification. Figure 1 It includes at least a server 101 that executes the code project adaptation method, and also includes electronic devices storing the code project. The multiple electronic devices include at least a first electronic device 1021, a second electronic device 1022, and a third electronic device 1023. It is understood that... Figure 1 The number of servers and electronic devices shown is for illustrative purposes only, and the embodiments in this specification do not impose any limitations on them.

[0018] The aforementioned server 101 can be a standalone server device, such as a rack-mounted, tower-mounted, or cabinet-type server device, or a workstation, mainframe computer, or other hardware device with strong computing power; it can also be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, where each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services to the outside world independently. Providing services independently can be understood as not requiring the assistance of other servers.

[0019] For example, a server can be multiple physical servers, each with independent hardware. Alternatively, a server can be multiple virtual servers deployed within the same hardware resource pool. Virtual server deployment methods include, but are not limited to, VMware, VirtualBox, and Virtual PC.

[0020] It is understood that server 101 also possesses other service capabilities and functions to complete the tasks described in the following embodiments. For example, server 101 also provides portal services, resource management services, and CI / CD services, etc.

[0021] Electronic devices include, but are not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0022] In the embodiments of this specification, display devices may also be installed on the first electronic device 1021, the second electronic device 1022, and the third electronic device 1023. These display devices can be various devices capable of displaying functions, such as cathode ray tube displays (CRTs), light-emitting diode displays (LEDs), electronic ink screens, liquid crystal displays (LCDs), and plasma display panels (PDPs). For example, a user can use the first electronic device 1021 to send a call request to the server 101 to invoke a specific code item through an adapter proxy layer.

[0023] Multiple electronic devices and multiple servers can communicate through communication links established by communication protocols. For example, the network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some of the links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0024] In one embodiment, such as Figure 2 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. This method can be implemented using a computer program and can run on a code project adaptation device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0025] Specifically, the code project adaptation methods include: S102. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0026] Metadata includes static metadata and dynamic metadata. Static metadata is obtained through static parsing of the code project, while dynamic metadata is obtained through data collection during code project runtime. Static metadata reflects the structural characteristics and interface definitions of the code project at the code level, while dynamic metadata reflects the actual behavioral characteristics of the code project during runtime.

[0027] Specifically, static semantic parsing technology is used to scan the code files, interface definition files (including HTTP protocol interfaces and RPC protocol interfaces), configuration files, database table definitions and entity class definitions in the code project, and extract core information such as class names, method names, interface parameters, call relationships and configuration parameters to obtain static metadata.

[0028] Static metadata may include, but is not limited to, source code structure information, interface definition information, interface parameter type information, return value type information, call relationship information, database table structure information, entity class attribute information, and configuration parameter information.

[0029] Runtime data collection is performed while the code project is running, acquiring behavioral data of the code project during runtime through various non-intrusive methods. Runtime interception logic can be configured at the runtime framework or middleware level upon which the code project depends to automatically record API call data when the code project executes API calls. Traffic data can also be copied at the network gateway level through which the code project passes to obtain request and response data during API calls. Furthermore, runtime logs generated during the code project's operation can be collected and parsed in real time to extract API call parameters and return results.

[0030] Dynamic metadata can include, but is not limited to, API call data, API input parameters, API output parameters, call chain data, and exception branch data. Dynamic metadata is used to supplement runtime characteristics that static parsing cannot cover, ensuring that the metadata is consistent with the actual runtime behavior of the code project.

[0031] Static analysis and runtime data collection do not modify the source data, configuration files, deployment configurations, or other information of the code project, and the code project is not repackaged and deployed.

[0032] S104. The metadata is structured based on the target specification format, and the structured processing results are mapped based on the mapping rules to obtain the baseline specification.

[0033] The target specification is a predefined structured interface description specification for a specification-driven coding system, used to define interface contracts, data formats, and transaction rules. The target specification can be a RESTful interface description specification, an RPC interface definition specification (such as the gRPC Protocol Buffers specification, Thrift IDL specification, Apache Avro IDL specification), a Spec specification, or other specifications.

[0034] Structured processing refers to the process of organizing, classifying, and formatting metadata according to a predefined format template in the target specification. Specifically, it involves reorganizing the content of metadata according to the field structure, hierarchical relationships, and data types defined in the target specification to form structured data with a unified format.

[0035] Mapping rules define the correspondence between code-level symbols and specification-level fields. Code-level symbols include class names, method names, interface signatures, interface parameter names, database field names, and configuration item names. Specification-level fields are interface names, request methods, parameter lists, return formats, and constraint rules defined based on the target specification. Based on the mapping rules, the structured processing results are mapped, transforming code-level symbols in the structured data into specification-level fields to obtain the baseline specification.

[0036] The baseline specification is a structured specification document that reflects the actual interface behavior and data logic of the code project. The baseline specification includes interface definition information, parameter constraint information, call chain information, return format information, and exception handling information.

[0037] S106. Compare the baseline specification with the target specification to obtain the difference results, and generate the set of adaptation rules corresponding to the code project based on the difference results.

[0038] The discrepancy results are inconsistencies between the interface behavior, data format, or transaction logic described in the baseline specification and the interface standards, data formats, or transaction logic defined in the target specification. Since the baseline specification reflects the actual content of the code project, while the target specification defines the standard content that external systems expect to call, inconsistencies exist between the baseline specification and the target specification in dimensions such as interface behavior, data format, or transaction logic. These inconsistencies constitute the discrepancy items.

[0039] Based on the differences, a set of adaptation rules is generated for the code project. This set records the conversion logic for the differences between the baseline and target specifications. Since the code project has not undergone intrusive refactoring, its original content remains unchanged and it cannot directly recognize call requests based on the target specification. By generating the set of adaptation rules, the differences between the baseline and target specifications are converted into executable conversion logic. This allows the adaptation proxy layer, upon receiving a call request based on the target specification, to convert the request into a request recognizable by the code project according to the set of adaptation rules, and to convert the results returned by the code project into response data conforming to the target specification. This enables the code project to provide interface services conforming to the target specification through the adaptation proxy layer.

[0040] S108. Generate the corresponding adaptation proxy layer for the code project based on the set of adaptation rules.

[0041] The code generation engine automatically generates adaptation proxy layer code based on multiple adaptation rules in the adaptation rule set, including modules such as interface conversion, data format conversion, logic adaptation, and exception pass-through.

[0042] The adaptation proxy layer is used to invoke the code project based on the target specification. Upon receiving a call request from an external system according to the target specification, the adaptation proxy layer converts the interface path, parameter fields, communication protocol, and other content included in the call request into the original format of the code project based on the adaptation rule set, and then forwards the converted call request to the code project. After the code project returns response data based on the converted call request, the adaptation proxy layer converts the response data and any possible exception information into the target specification format and returns it to the external system.

[0043] In the embodiments of this specification, static parsing and runtime data collection are performed simultaneously on the code project to obtain the metadata corresponding to the code project. This ensures that the metadata includes both static metadata reflecting source code information and dynamic metadata reflecting actual runtime behavior information, providing a comprehensive data foundation for generating the baseline specification. Furthermore, the metadata is structured based on the target specification's format, and the structured processing results are mapped using mapping rules to obtain the baseline specification. This allows the baseline specification to represent the actual interface behavior of the code project using the unified semantic paradigm defined by the target specification, enabling it to be parsed and used by the target specification system. Further, the baseline specification is compared with the target specification to obtain the difference results, and a set of adaptation rules corresponding to the code project is generated based on these differences. Each adaptation rule in the set closely corresponds to the actual difference between the code project and the target specification, ensuring the accuracy of the adaptation rule set without requiring manual organization and writing of adaptation logic. Finally, an adaptation proxy layer corresponding to the code project is generated based on the adaptation rule set. This adaptation proxy layer responds to call requests and provides the services corresponding to the code project, achieving compatibility between the code project and the target specification system. In other words, the embodiments in this specification achieve full-process automation of adaptation without modifying the core code and logic of the code project, thus avoiding the risk of stability damage caused by intrusive adaptation modifications.

[0044] In one embodiment, after generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the method further includes: independently deploying the adaptation proxy layer between the code project and the external system of the target specification.

[0045] Independent deployment refers to deploying and running the adapter proxy layer as an independent software component separate from the code project. This allows the code project to have interface capabilities that conform to the target specification without being embedded in the code project's code repository, without intruding into the code project's runtime environment, and without modifying the code project's source code, compilation artifacts, configuration files, or deployment topology.

[0046] The deployment location is on the network communication path between the code project and the external system, so that the call requests initiated by the external system to the code project first pass through the adaptation proxy layer, and then the adaptation proxy layer forwards them to the code project.

[0047] The deployment forms that can adapt to the proxy layer include at least one of the following: independently deployed gateway service, independently deployed middleware process, independently deployed containerized instance, or independently deployed virtual machine instance.

[0048] In this embodiment, by independently deploying the adaptation proxy layer, the code project maintains its original deployment form and running configuration, avoiding regression defects and transaction interruption risks introduced by modifying existing code, and achieving risk isolation. The upgrade, maintenance, and fault recovery of the adaptation proxy layer are decoupled from the code project. Anomalies in the adaptation proxy layer do not affect direct access to the original interfaces of the code project. Furthermore, it supports dual-track parallel operation. External systems based on the target specification access the code project through the adaptation proxy layer, while calls based on the original interfaces of the code project can still directly access the code project. The two access paths coexist in the same running environment.

[0049] In one embodiment, after generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the method further includes: updating the adaptation proxy layer based on the changes in the target specification when the target specification changes.

[0050] The target specification, as a unified interface description standard for the system, continues to change as requirements evolve, technical architecture is upgraded, industry standards are updated, or artificial intelligence code generation models iterate.

[0051] When the target specification changes, since the code project remains unchanged, the baseline specification still accurately reflects the actual interface behavior and data logic of the code project. Further comparison is made between the baseline specification and the changed target specification, and incremental difference comparison is performed only on the changed parts of the target specification to identify incremental difference items, which may include items such as adding interface definitions, deleting interface definitions, adjusting field names, changing field types, modifying parameter constraints, expanding return structure, upgrading protocol versions, or adjusting exception code mapping.

[0052] An incremental adaptation rule set is generated based on the incremental differences. The incremental adaptation rule set only includes adaptation rules corresponding to the changes in the target specification, and does not include existing adaptation rules for unchanged parts, thus avoiding the generation of duplicate rules for unchanged interfaces, fields, and logic.

[0053] The incremental adaptation rule set is loaded into the running adaptation proxy layer through a configuration hot update mechanism or rule hot loading mechanism, thereby automatically merging the incremental adaptation rules into the existing rule set of the adaptation proxy layer, replacing the rule entries affected by the target specification changes, adding rule entries corresponding to the new content of the target specification, and retaining the original rule entries that have not been changed.

[0054] Since the actual interface behavior and data logic of the code project remain unchanged, the baseline specification remains valid, eliminating the need to re-execute the code project's static parsing, runtime data collection, metadata structuring, baseline specification generation, and full-scale difference comparison process. In other words, only three steps are required: incremental difference comparison, incremental adaptation rule generation, and online rule loading. This completes the synchronization between the adaptation proxy layer and the changed target specification, shortening the synchronization cycle of the adaptation proxy layer and the target specification iteration, significantly improving iteration efficiency, and reducing maintenance costs.

[0055] based on Figure 2 Please refer to the embodiments shown below. Figure 3 The embodiment shown, Figure 3 This is a flowchart illustrating a code project adaptation method provided in the embodiments of this specification. Figure 2 S102 includes the following steps: S102-1. Perform static analysis on the code project to obtain the static metadata of the code project.

[0056] Static parsing refers to the technical process of performing read-only scanning and semantic analysis on the source code files, configuration files, interface definition files, and data structure definition files of a code project to extract structural features and interface definitions.

[0057] Static metadata may include, but is not limited to, source code structure information, interface definition information, interface parameter type information, return value type information, call relationship information, database table structure information, entity class attribute information, and configuration parameter information.

[0058] S102-2. By attaching a bypass probe to the runtime environment of the code project, dynamic metadata of the code project is collected during the runtime of the code project.

[0059] Metadata includes static metadata and dynamic metadata.

[0060] A bypass probe is an independent data collection component deployed within the runtime environment of the code project. The bypass probe exists independently of the code project's transaction processes. It is attached to the code project's runtime environment through a runtime mounting mechanism, detecting and recording the runtime behavior of the code project without intruding on it.

[0061] Bypass probes can be categorized into runtime probes, network traffic probes, log collection probes, and framework middleware probes. For example, runtime probes are mounted within the running process of the code project via Java Virtual Machine proxy mechanisms or bytecode enhancement mechanisms, while network traffic probes are deployed on the network node where the code project resides via gateway mirroring mechanisms or network interface replication mechanisms.

[0062] The bypass probe has four states: initialization, mounting, acquisition, and unmounting. Specifically, in the initialization state, the bypass probe completes component loading and configuration reading; in the mounting state, it establishes a data channel with the code project's runtime environment; in the acquisition state, it continuously captures runtime data; and in the unmounting state, it disconnects from the code project's runtime environment without affecting the code project's operation.

[0063] Dynamic metadata obtained through bypass probes may include, but is not limited to, API call data, API input parameters, API output parameters, call chain data, and exception branch data. API input parameters include parameter name, parameter type, parameter value range, and parameter validation results. API output parameters include return value structure, return value fields, return value type, and return value length. Call chain data includes call chain identifier, call hierarchy, call time distribution, and call dependency topology. Exception branch data includes exception type, exception triggering conditions, exception propagation path, and exception handling results.

[0064] In one embodiment, such as Figure 4 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. Figure 3 This method can be implemented using a computer program and can run on code projects adapted to the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0065] Specifically, the code project adaptation methods include: S202. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0066] See S102 above, which will not be repeated here.

[0067] S204. Based on the target specification format, perform structured processing on the metadata to obtain multiple structured processing results.

[0068] Structured processing refers to the process of organizing, classifying, and formatting metadata according to a predefined format template in the target specification. Specifically, it involves reorganizing the content of metadata according to the field structure, hierarchical relationships, and data types defined in the target specification to form structured data with a unified format.

[0069] Each structured processing result corresponds to a target specification format template instance, which may include structured processing results of interface definition, structured processing results of parameter description, structured processing results of return structure, structured processing results of constraint rules, and structured processing results of call chain, etc.

[0070] S206. Based on the mapping rules, map multiple structured processing results, resolve conflicting fields and / or complete missing fields in the structured processing results to obtain the baseline specification.

[0071] Mapping refers to the technical process of converting code-level symbols in structured processing results into field definitions in the specification layer according to preset mapping rules. This includes naming style conversion rules, data type mapping rules, path format conversion rules, and hierarchical structure mapping rules, etc.

[0072] Conflicting fields refer to fields in multiple structured processing results where static metadata and dynamic metadata provide inconsistent descriptions for the same interface, parameter, or data field. Examples of conflicting fields include interface path conflicts, parameter type conflicts, return structure conflicts, and call chain conflicts.

[0073] When the structured processing results include conflicting fields, these fields are resolved. Specifically, the conflicting fields are processed according to a first preset strategy to determine the valid descriptive content. The first preset strategy may include a static priority strategy, a dynamic priority strategy, a frequency-weighted strategy, and a manual verification strategy. The static priority strategy uses the static parsing results as the valid descriptive content for the conflicting fields. The dynamic priority strategy uses the dynamically collected results as the valid descriptive content for the conflicting fields, suitable for scenarios where runtime patches or dynamic proxies in the code project cause inconsistencies between static definitions and actual behavior. The frequency-weighted strategy counts the frequency of each field value during dynamic collection and uses the most frequent values ​​as the valid descriptive content for the conflicting fields. The manual verification strategy marks the conflicting fields as pending confirmation, requiring manual intervention to determine the valid descriptive content.

[0074] Missing fields refer to data items in structured processing results where the field content required by the target specification template is incomplete due to the absence of static or dynamic metadata. Missing fields can include statically missing fields and dynamically missing fields.

[0075] When missing fields exist in the structured processing results, these fields are filled in. Specifically, the missing fields are inferred and filled in according to a second preset strategy, ensuring that the structured processing results fully cover the technical process of the actual interface behavior in the code project. The second preset strategy may include a dynamic inference strategy, a static inference strategy, a context-related strategy, and a default value filling strategy. The dynamic inference strategy infers missing fields based on dynamically collected interface call data, parameter transmission data, and return result data. The static inference strategy infers missing fields based on statically parsed interface definition information, parameter declaration information, and return structure information. The context-related strategy infers reasonable values ​​and type definitions for missing fields based on the call chain context, interface dependencies, and parameter passing paths. The default value filling strategy fills in preset default values ​​for missing fields that cannot be inferred and marks the field as an inference completion item.

[0076] In this embodiment, by resolving conflicting fields and completing missing fields, the baseline specification is ensured to match the actual interface behavior and data logic of the code project. This avoids specification distortion caused by the limitations of a single data source or inconsistency between static and dynamic data. Furthermore, it eliminates the need for manual line-by-line verification of the code project or metadata dataset, or manual correction of the baseline specification.

[0077] In one embodiment, the code project adaptation method further includes: verifying whether the baseline specification meets the integrity and correctness requirements; and when it is determined that the baseline specification meets the integrity and correctness requirements, associating and storing the baseline specification and the code project.

[0078] Specifically, the baseline specification is automatically scanned and verified item by item by loading integrity verification rules and correctness verification rules through the rule verification engine. Integrity verification refers to verifying the content coverage and logical closure of the baseline specification, including interface definition integrity verification, parameter constraint integrity verification, call chain integrity verification, and exception branch integrity verification. Correctness verification refers to verifying the syntax compliance and logical consistency of the baseline specification, including format syntax correctness verification, data type correctness verification, logical constraint correctness verification, and reference consistency verification.

[0079] The rule validation engine outputs integrity and correctness validation results. Integrity validation results can include lists of missing and complete items, while correctness validation results include lists of syntax errors, type conflicts, and logical contradictions. Based on these results, it is determined whether the baseline specification meets the integrity and correctness requirements.

[0080] Once the baseline specification meets the integrity and correctness requirements, it is stored in association with the code project. Association storage refers to establishing a binding relationship between the baseline specification and the code project identifier in the specification management repository, allowing the baseline specification to be persistently stored as a specification asset of the code project. When storing the baseline specification, the specification version identifier, generation timestamp, corresponding code project identifier, and metadata source identifier are recorded.

[0081] In this embodiment, integrity and correctness checks ensure that the baseline specifications stored in the specification management library are accurate, complete, and reliable. This prevents missing or erroneous baseline specifications from entering the subsequent difference comparison and adaptation rule generation stages, reducing the risk of adaptation rule failure due to baseline specification defects. By associating baseline specifications with code projects for storage, standardization and asset-based management of existing code project specifications are achieved.

[0082] S208. Compare the baseline specification with the target specification to obtain the difference results, and generate the set of adaptation rules corresponding to the code project based on the difference results.

[0083] See S106 above, which will not be repeated here.

[0084] S210. Generate the corresponding adaptation proxy layer for the code project based on the set of adaptation rules.

[0085] See S108 above; it will not be repeated here.

[0086] In one embodiment, such as Figure 5 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. Figure 4 This method can be implemented using a computer program and can run on code projects adapted to the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0087] Specifically, the code project adaptation methods include: S302. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0088] See S102 above, which will not be repeated here.

[0089] S304. The metadata is structured based on the target specification format, and the structured processing results are mapped based on the mapping rules to obtain the baseline specification.

[0090] See S104 above, which will not be repeated here.

[0091] S306. Compare the baseline specification with the target specification based on multiple dimensions to obtain the difference results.

[0092] The dimensions include at least one of the following: interface dimension, data dimension, and logic dimension. Specifically, the interface dimension refers to structural differences at the interface level, including differences in interface name, request method, interface path, interface version, and interface visibility. The data dimension refers to format differences at the data entity and field level, including differences in field name, data type, field length constraints, required attributes, default values, and enumeration values. The logic dimension refers to semantic differences at the transaction logic and behavior level, including differences in parameter validation rules, exception handling logic, call chain, retry strategies, and timeout configurations.

[0093] The baseline specification is compared with the target specification based on multiple dimensions. Specifically, the differences in different differences under each dimension are compared to obtain the difference results of the difference information corresponding to each difference item.

[0094] In addition to interface, data, and logic dimensions, differences can also be extended to performance, security, and version dimensions. The performance dimension focuses on differences in interface response timeout thresholds, concurrency limits, and traffic control strategies. The security dimension focuses on differences in interface authentication methods, encryption algorithms, transport layer security protocols, and access control lists. The version dimension focuses on differences in interface compatibility flags, deprecation declarations, and lifecycle states.

[0095] S308. Classify the difference results according to the preset strategy, and determine the difference items in the difference results that meet the corresponding requirements of the preset strategy to form an adaptation rule set.

[0096] The default strategy is a criterion for classifying differences, used to categorize differences in the results into mandatory and optional adaptation categories based on their impact and processing priority. Mandatory adaptation categories refer to differences that prevent direct interoperability between the baseline and target specifications; without handling, external systems' calls based on the target specification will not be correctly recognized or responded to by the code project. Optional adaptation categories refer to differences that do not affect basic interface interoperability, only causing degradation of non-core functions or incomplete information display, and can be selectively handled.

[0097] Required adaptation items may include differences such as changes to the interface path, request method, core field data type, addition of required constraints, and protocol version upgrades. Optional adaptation items may include differences such as adjusting the length of non-core fields, improving description information, updating sample values, optimizing default values ​​for non-required fields, and standardizing log formats.

[0098] The difference results are classified according to the preset strategy. The difference items are traversed, and the category of the difference item in different dimensions is determined according to the classification judgment rules in the preset strategy. The difference item is determined to be an optional adaptation category or a mandatory adaptation category. The difference information corresponding to the difference item of the mandatory adaptation category is included in the adaptation rule combination.

[0099] In this embodiment, multi-dimensional difference comparison is used to cover multiple differences across different dimensions, avoiding omissions caused by single-dimensional comparison and improving the completeness of difference identification. Furthermore, a preset strategy is used to classify the difference results into mandatory and optional adaptations, focusing on core differences that affect interface integration capabilities, and including only mandatory adaptation differences in the adaptation rule set, thereby minimizing the generation of adaptation rules, shortening the adaptation proxy layer construction cycle, and reducing adaptation costs.

[0100] S310. Generate the corresponding adaptation proxy layer for the code project based on the set of adaptation rules.

[0101] See S108 above; it will not be repeated here.

[0102] In one embodiment, such as Figure 6 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. Figure 5 This method can be implemented using a computer program and can run on code projects adapted to the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0103] Specifically, the code project adaptation methods include: S402. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0104] See S102 above, which will not be repeated here.

[0105] S404. The metadata is structured based on the target specification format, and the structured processing results are mapped based on the mapping rules to obtain the baseline specification.

[0106] See S104 above, which will not be repeated here.

[0107] S406. Compare the baseline specification with the target specification to obtain the difference results, and generate the set of adaptation rules corresponding to the code project based on the difference results.

[0108] See S106 above, which will not be repeated here.

[0109] S408. Perform conflict and matching checks on the set of adaptation rules.

[0110] Conflict checking is used to detect whether there are logical conflicts between the adaptation rules in the adaptation rule set, and consistency checking is used to detect whether each adaptation rule matches the code project and the target specification.

[0111] Specifically, conflict checking detects whether there are logical conflicts such as the same source field being mapped to multiple different target fields, multiple source fields being mapped to the same target field but with mutually exclusive conversion logic, contradictory directions in the data type conversion chain, or path conflicts in the protocol conversion rules. Matching verification verifies the feasibility of the adaptation rules and whether they match the code project and target specifications, including whether the conversion logic conforms to the actual interface behavior of the code project and whether the conversion results are compatible with the target specification definition.

[0112] The system automatically optimizes detected logical conflicts, such as retaining rules generated based on dynamic metadata and removing conflicting rules generated based on static metadata, or retaining rules generated later and removing conflicting rules generated earlier, or removing invalid rules and merging duplicate rules to ensure that the verified set of adaptation rules has no logical conflicts and matches the code project and target specifications, and can be directly used to adapt the proxy layer construction.

[0113] S410. When the set of adaptation rules is determined to pass the conflict check and matching check, an adaptation proxy layer corresponding to the code project is generated based on the set of adaptation rules.

[0114] When the set of adaptation rules passes the conflict check and matching check, the adaptation proxy layer generation process is triggered, and the adaptation proxy layer code is automatically generated, including modules such as interface conversion module, data format conversion module, logic adaptation module, and exception pass-through module.

[0115] In this embodiment, conflict checking avoids contradictory rules in the adaptation rule set, preventing request processing failures or data corruption due to rule conflicts during the runtime of the adaptation proxy layer. Matching verification ensures that each adaptation rule is truly usable on the code project side and truly compliant on the target specification side, avoiding the generation of unworkable adaptation proxy layer code. In other words, by simplifying and optimizing the size of the adaptation rule set, it ensures that the adaptation proxy layer is built on verified and reliable rules, guaranteeing the stability and correctness of external systems calling the code project through the adaptation proxy layer.

[0116] In one embodiment, such as Figure 7 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. Figure 6 This method can be implemented using a computer program and can run on code projects adapted to the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0117] Specifically, the code project adaptation methods include: S502. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0118] See S102 above, which will not be repeated here.

[0119] S504. The metadata is structured based on the target specification format, and the structured processing results are mapped based on the mapping rules to obtain the baseline specification.

[0120] See S104 above, which will not be repeated here.

[0121] S506. Compare the baseline specification with the target specification to obtain the difference results, and generate the set of adaptation rules corresponding to the code project based on the difference results.

[0122] See S106 above, which will not be repeated here.

[0123] S508. Generate an adaptation proxy layer corresponding to the code project based on the adaptation rule set; wherein, the adaptation proxy layer is used to call the code project based on the target specification.

[0124] See S108 above; it will not be repeated here.

[0125] S510. In the test environment, the first request corresponding to the target specification is called through the adaptation proxy layer to obtain the first test result, and the second request corresponding to the interface of the code project is called to obtain the second test result.

[0126] The test environment is an isolated operating environment independent of the production operating environment, with the same network topology, dependent components, and data resources as the production operating environment, to ensure that the test results are equivalent to the production operating behavior.

[0127] The first request is constructed based on the target specification definition, including the interface path conforming to the target specification definition, the request method, the request headers, the request parameter structure, and the parameter values. The first request is sent to the adaptation proxy layer, which then calls the code project to obtain the response data as the first test result.

[0128] A second request is constructed based on the existing interface definition of the code project, including the original interface path, original request method, original request headers, original request parameter structure, and parameter values. The second request is sent directly to the code project without going through the adaptation proxy layer to obtain the response data as the second test result.

[0129] S512. Compare the results of the first test and the second test to see if they are the same.

[0130] Extract the response data from the first test result and compare it with the response data from the second test result. The comparison may include field value comparison, data structure comparison, status code comparison, and exception information comparison, to ensure that the transaction field values, hierarchical structure, response status codes, and other contents are consistent.

[0131] In this embodiment, a preset difference tolerance threshold can be established. The difference tolerance threshold includes a response time difference threshold, a floating-point precision difference threshold, and a field order difference threshold. When the difference between the first test result and the second test result is within the difference tolerance threshold range, the first test result and the second test result are determined to be the same. When the difference exceeds the difference tolerance threshold, the first test result and the second test result are determined to be different.

[0132] S514. When the results of the first test and the second test are the same, establish the call association between the adaptation proxy layer and the code project.

[0133] By establishing call relationships and passing testing, the adapted proxy layer was officially integrated into the external service chain of the code project. The adapted proxy layer exposes the target specification interface externally and forwards the original interfaces of the code project internally, enabling external systems to call the code project based on the target specification.

[0134] In this embodiment, by setting up an isolated test environment and performing dual-track testing, the correctness of the adaptation proxy layer's conversion logic is verified without affecting the running status of the code project. This ensures that the output of the adaptation proxy layer is consistent with the actual behavior of the code project. Furthermore, after passing the test, the calling relationship between the adaptation proxy layer and the code project is established, preventing the adaptation proxy layer from being directly connected to the production environment without testing and verification, which could lead to calling errors.

[0135] In one embodiment, such as Figure 8 The diagram shown is a flowchart illustrating a code project adaptation method provided in an embodiment of this specification. Figure 7 This method can be implemented using a computer program and can run on code projects adapted to the von Neumann architecture. This computer program can be integrated into applications or run as a standalone utility application.

[0136] Specifically, the code project adaptation methods include: S602. Perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project.

[0137] See S102 above, which will not be repeated here.

[0138] S604. The metadata is structured based on the target specification format, and the structured processing results are mapped based on mapping rules to obtain the baseline specification.

[0139] See S104 above, which will not be repeated here.

[0140] S606. Compare the baseline specification with the target specification to obtain the difference results, and generate the set of adaptation rules corresponding to the code project based on the difference results.

[0141] See S106 above, which will not be repeated here.

[0142] S608. Generate an adaptation proxy layer corresponding to the code project based on the adaptation rule set; wherein, the adaptation proxy layer is used to call the code project based on the target specification.

[0143] See S108 above; it will not be repeated here.

[0144] S610. Compare the runtime behavior of the code project with the runtime behavior of the adaptation proxy layer, and check the consistency between the baseline specification and the code project based on the comparison results.

[0145] Detecting the consistency between the baseline specification and the code project refers to verifying whether the interface behavior, data format, and transaction logic recorded in the baseline specification are consistent with the code project during the system operation phase, identifying deviations between the runtime behavior of the code project and the runtime behavior of the adapted proxy layer, and ensuring that the baseline specification continuously and accurately reflects the current interface capabilities of the code project.

[0146] Specifically, using the baseline specification and target specification as a contract, online contract verification is performed on the actual online request-response data. Inconsistencies between the baseline specification, target specification, code project operation behavior, and adaptation proxy layer operation behavior are continuously compared among the four entities. Inconsistencies between the baseline specification and code project caused by code project changes, target specification iterations, and abnormal proxy layer conversion logic are proactively detected.

[0147] For example, the behavior of the code project is compared with that of the adaptation proxy layer. This includes comparing the returned field structure, field type, field value range, and status code information in the response data returned by the code project with the return format recorded in the baseline specification to verify whether the response data conforms to the return structure defined in the baseline specification.

[0148] S612. When inconsistencies are found between baseline specifications and code items, pre-set warning measures shall be taken.

[0149] When an inconsistency is detected between the baseline specification and the code project, an alarm event is generated and preset warning measures are taken. Alarm events include missing field alarms, field type mismatch alarms, interface path miss alarms, and abnormal return structure alarms. Warning measures are emergency operations automatically executed by the system, which may include traffic redirection measures, switching external system call traffic based on the target specification from the adaptation proxy layer back to the historical interface of the code project, and may also include pushing the alarm event to the operation and maintenance system or management terminal through preset channels.

[0150] In this embodiment, a real-time detection mechanism is used to compare the running behavior of the code project with that of the adaptation proxy layer, using the baseline specification and the target specification as contract benchmarks. This detects whether the baseline specification is always consistent with the code project, preventing the adaptation proxy layer from failing to call due to long-term inaccuracy of the baseline specification after changes to the code project. Furthermore, when the baseline specification and the code project are inconsistent, alarm measures such as automatic traffic switching are triggered to ensure the transaction continuity of external systems calling the code project.

[0151] In one embodiment, after comparing the running behavior of the code project with the running behavior of the adaptation proxy layer and detecting the consistency between the baseline specification and the code project based on the comparison results, the method further includes: when it is determined that the baseline specification and the code project are consistent, switching the request to call the code project from the interface of the code project to the adaptation proxy layer.

[0152] Once the baseline specification and code project are confirmed to be consistent, a canary rollout process is triggered. Specifically, the consistency verification results between the baseline specification and the code project, the accuracy verification results of the adaptation proxy layer conversion, and the consistency verification results between the target specification and the adaptation proxy layer are used as the basis for the canary rollout decision to determine whether it is currently feasible to switch production traffic from the original interface of the code project to the target specification interface of the adaptation proxy layer. The preset canary rollout strategy also includes at least one of the following: switching by traffic ratio, switching by caller identifier, and switching by interface granularity.

[0153] When switching based on traffic ratio, an initial traffic ratio threshold is configured. A predetermined percentage of requests from external system calls to the code project are routed to the adaptation proxy layer, while the remaining traffic continues to directly access the code project's historical interfaces. When the traffic ratio reaches the predetermined value, all requests from external system calls to the code project are forwarded through the adaptation proxy layer.

[0154] When switching based on caller identifier, the system identifies a set of callers with independent identities in the external system. A preset number of callers are selected as the first batch of switch targets based on their caller identifiers, and requests initiated by these first batch of callers are routed to the adaptation proxy layer. After the first batch of callers runs stably and the conversion accuracy and consistency verification meet the standards, the switch scope is expanded to more caller identifiers until all caller identifiers have been switched.

[0155] When switching at the interface level, the system identifies multiple existing interfaces exposed by the code project, selects a preset number of these interfaces as the first batch of switching targets, and routes the call requests corresponding to these first batch of interfaces to the adaptation proxy layer. After the first batch of interfaces runs stably and the conversion accuracy and consistency verification meet the standards, the switching scope is expanded to more interfaces until all interfaces have been switched.

[0156] During the grayscale transition process, the accuracy of the adaptation proxy layer conversion and its consistency with the specifications are continuously monitored. If any inconsistencies are detected between the baseline specifications and the code project, between the target specifications and the adaptation proxy layer, or if the adaptation proxy layer conversion is abnormal or the conversion accuracy is lower than the preset value, a rollback operation is automatically performed.

[0157] In this embodiment, the above steps achieve consistency-driven canary traffic switching and rollback, ensuring that production traffic is gradually switched to the adapting proxy layer only when the behavior of the adapting proxy layer and the code project is consistent and the conversion logic of the adapting proxy layer is accurate. By gradually increasing the volume according to traffic ratio, caller identifier, or interface granularity, the switching risk is distributed to a controllable range, avoiding systemic failures caused by a full switch. Through an automatic rollback mechanism, the direct access capability of the code project's historical interfaces is immediately restored when specification deviations or conversion anomalies are detected.

[0158] The following are embodiments of the apparatus described in this specification, which can be used to execute the embodiments of the methods described in this specification. For details not disclosed in the apparatus embodiments of this specification, please refer to the embodiments of the methods described in this specification.

[0159] Please see Figure 9 This diagram illustrates the structure of a code project adaptation device provided in an exemplary embodiment of this specification. The code project adaptation device can be implemented as all or part of a device through software, hardware, or a combination of both. The device includes a data acquisition module 701, a baseline specification module 702, an adaptation rule module 703, and a proxy generation module 704.

[0160] The data acquisition module 701 is used to perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project. The baseline specification module 702 is used to perform structured processing on the metadata based on the format of the target specification, and to map the structured processing result based on mapping rules to obtain the baseline specification. The adaptation rule module 703 is used to compare the baseline specification with the target specification to obtain the difference result, and generate an adaptation rule set corresponding to the code project based on the difference result; The proxy generation module 704 is used to generate an adaptation proxy layer corresponding to the code project according to the adaptation rule set; wherein the adaptation proxy layer is used to call the code project based on the target specification.

[0161] In one or more embodiments, the data acquisition module 701 is specifically used to perform static parsing on the code project to obtain static metadata of the code project; and to collect dynamic metadata of the code project during runtime by using a bypass probe mounted on the runtime environment of the code project; wherein the metadata includes the static metadata and the dynamic metadata.

[0162] In one or more embodiments, the baseline specification module 702 is specifically used to perform structured processing on the metadata based on the format of the target specification to obtain multiple structured processing results; to map the multiple structured processing results based on mapping rules, and to resolve conflicting fields and / or complete missing fields in the structured processing results to obtain the baseline specification.

[0163] In one or more embodiments, the code project adaptation device further includes: The specification verification module is used to verify whether the baseline specification meets the integrity requirements and the correctness requirements; when it is determined that the baseline specification meets the integrity requirements and the correctness requirements, the baseline specification and the code project are associated and stored.

[0164] In one or more embodiments, the adaptation rule module 703 is specifically used to compare the baseline specification with the target specification based on multiple dimensions to obtain the difference results; wherein, the multiple dimensions include at least one of the interface dimension, data dimension, and logic dimension; classify the difference results according to a preset strategy, and determine the difference items in the difference results that meet the requirements of the preset strategy to form an adaptation rule set.

[0165] In one or more embodiments, the code project adaptation device further includes: The set of adaptation rules is subjected to conflict verification and matching verification; wherein, the conflict verification is used to detect whether there is a logical conflict between the adaptation rules in the set of adaptation rules, and the matching verification is used to detect whether each adaptation rule matches the code project and the target specification; The proxy generation module 704 is specifically used to generate an adaptation proxy layer corresponding to the code project based on the adaptation rule set when it is determined that the adaptation rule set passes the conflict check and matching check.

[0166] In one or more embodiments, the code project adaptation device further includes: A compatibility testing module is used to, in a test environment, call the code project through the adaptation proxy layer to obtain a first test result based on a first request corresponding to the target specification, and call the code project through the adaptation proxy layer to obtain a second test result based on a second request corresponding to the interface of the code project; compare whether the first test result and the second test result are the same; and when it is determined that the first test result and the second test result are the same, establish a call association relationship between the adaptation proxy layer and the code project.

[0167] In one or more embodiments, the code project adaptation device further includes: An independent deployment module is used to independently deploy the adaptation proxy layer between the code project and the external system of the target specification.

[0168] In one or more embodiments, the code project adaptation device further includes: The consistency verification module is used to compare the running behavior of the code project with the running behavior of the adaptation proxy layer, and detect the consistency between the baseline specification and the code project based on the comparison results; when it is determined that the baseline specification and the code project are inconsistent, preset warning measures are taken.

[0169] In one or more embodiments, the code project adaptation device further includes: The grayscale switching module is used to switch requests calling the code project from the interface of the code project to the adaptation proxy layer when it is determined that the baseline specification and the code project are consistent.

[0170] In one or more embodiments, the code project adaptation device further includes: The adaptation update module is used to update the adaptation proxy layer based on the changes in the target specification when the target specification changes.

[0171] In the embodiments of this specification, the metadata includes static metadata reflecting source code information and dynamic metadata reflecting actual runtime behavior information. Based on the target specification's format, the metadata is processed to obtain a baseline specification. The baseline specification can characterize the actual interface behavior of the code project using the unified semantic paradigm defined by the target specification, and can be parsed and used by the target specification system. Furthermore, the baseline specification is compared with the target specification to obtain the difference results, and an adaptation rule set corresponding to the code project is generated based on these differences. Each adaptation rule in the set closely corresponds to the actual difference between the code project and the target specification, ensuring the accuracy of the adaptation rule set without requiring manual organization and writing of adaptation logic. Furthermore, an adaptation proxy layer corresponding to the code project is generated based on the adaptation rule set. The adaptation proxy layer responds to call requests and provides the services corresponding to the code project, achieving compatibility between the code project and the target specification system.

[0172] It should be noted that the code project adaptation device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the code project adaptation method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the code project adaptation device and the code project adaptation method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0173] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0174] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figure 1 - Figure 8 The code project adaptation method shown in the embodiment can be found in the following documentation for the specific execution process: Figure 1 - Figure 8 The specific details of the illustrated embodiments will not be elaborated here.

[0175] This specification also provides a computer program product that stores at least one instruction, which is loaded and executed by a processor as described above. Figure 1 - Figure 8 The code project adaptation method shown in the embodiment can be found in the following documentation for the specific execution process: Figure 1 - Figure 8 The specific details of the illustrated embodiments will not be elaborated here.

[0176] Please see Figure 10 This document provides a schematic diagram of the structure of an electronic device as an embodiment of the present specification. Figure 10 As shown, the electronic device 800 may include: at least one processor 801, at least one network interface 804, a user interface 803, a memory 805, and at least one communication bus 802.

[0177] The communication bus 802 is used to enable communication between these components.

[0178] The user interface 803 may include a display screen and a camera. Optionally, the user interface 803 may also include a standard wired interface and a wireless interface.

[0179] The network interface 804 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0180] The processor 801 may include one or more processing cores. The processor 801 connects to various parts within the electronic device 800 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 805, and by calling data stored in the memory 805. Optionally, the processor 801 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 801 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 801 and may be implemented as a separate chip.

[0181] The memory 805 may include random access memory (RAM) or read-only memory. Optionally, the memory 805 may include a non-transitory computer-readable storage medium. The memory 805 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 805 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 805 may also be at least one storage device located remotely from the aforementioned processor 801. Figure 10 As shown, the memory 805, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and code project adaptation applications.

[0182] exist Figure 10In the illustrated electronic device 800, the user interface 803 is mainly used to provide an input interface for the user and to obtain user input data; while the processor 801 can be used to call the code items stored in the memory 805 to adapt the application and specifically perform the following operations: Static analysis and runtime data collection are performed on the code project to obtain the metadata corresponding to the code project. The metadata is structured based on the target specification format, and the structured processing result is mapped based on mapping rules to obtain the baseline specification. The baseline specification is compared with the target specification to obtain the difference results, and an adaptation rule set corresponding to the code project is generated based on the difference results; Based on the set of adaptation rules, an adaptation proxy layer corresponding to the code project is generated; wherein, the adaptation proxy layer is used to call the code project based on the target specification.

[0183] In one or more embodiments, the processor executes step 801 to perform static analysis and runtime data collection on the code project to obtain metadata corresponding to the code project, specifically executing: Static analysis is performed on the code project to obtain its static metadata; By using a bypass probe mounted on the runtime environment of the code project, dynamic metadata of the code project is collected during runtime; wherein, the metadata includes the static metadata and the dynamic metadata.

[0184] In one or more embodiments, the processor executes step 801 to perform structured processing on the metadata based on the target specification format, and maps the structured processing result to obtain a baseline specification based on mapping rules, specifically: The metadata is structured based on the target specification format to obtain multiple structured processing results; The multiple structured processing results are mapped based on mapping rules, and conflicting fields in the structured processing results are resolved and / or missing fields are filled in to obtain the baseline specification.

[0185] In one or more embodiments, after the processor executes step 801 to map the plurality of structured processing results based on the mapping rules, resolves conflicting fields and / or completes missing fields in the structured processing results to obtain the baseline specification, it further executes: Verify whether the baseline specifications meet the integrity and correctness requirements; Once it is determined that the baseline specification meets the integrity requirements and the correctness requirements, the baseline specification and the code project are associated and stored.

[0186] In one or more embodiments, the processor executes step 801 to compare the baseline specification with the target specification to obtain the difference result, and generates a set of adaptation rules corresponding to the code project based on the difference result. Specifically, the following steps are performed: The baseline specification is compared with the target specification based on multiple dimensions to obtain the difference results; wherein, the multiple dimensions include at least one of the interface dimension, data dimension, and logic dimension; The difference results are classified according to a preset strategy, and the difference items that meet the requirements of the preset strategy are identified to form an adaptation rule set.

[0187] In one or more embodiments, before the processor executes step 801 to generate the adaptation proxy layer corresponding to the code project according to the adaptation rule set, it also executes: The set of adaptation rules is subjected to conflict verification and matching verification; wherein, the conflict verification is used to detect whether there is a logical conflict between the adaptation rules in the set of adaptation rules, and the matching verification is used to detect whether each adaptation rule matches the code project and the target specification; The processor executes step 801 to generate the adaptation proxy layer corresponding to the code project based on the adaptation rule set. Specifically, the following steps are performed: When the set of adaptation rules is determined to pass the conflict check and matching check, an adaptation proxy layer corresponding to the code project is generated based on the set of adaptation rules.

[0188] In one or more embodiments, after the processor executes step 801 to generate the adaptation proxy layer corresponding to the code project according to the adaptation rule set, it further executes: In the test environment, a first test result is obtained by calling the code project through the adaptation proxy layer based on the first request corresponding to the target specification, and a second test result is obtained by calling the code project based on the second request corresponding to the interface of the code project. Compare whether the first test result and the second test result are the same; When the first test result and the second test result are determined to be the same, a call association relationship is established between the adaptation proxy layer and the code project.

[0189] In one or more embodiments, after the processor executes step 801 to generate the adaptation proxy layer corresponding to the code project according to the adaptation rule set, it further executes: The adaptation proxy layer is deployed independently between the code project and the external system of the target specification.

[0190] In one or more embodiments, after the processor executes step 801 to generate the adaptation proxy layer corresponding to the code project according to the adaptation rule set, it further executes: The runtime behavior of the code project is compared with the runtime behavior of the adaptation proxy layer, and the consistency between the baseline specification and the code project is detected based on the comparison results; When inconsistencies are found between the baseline specification and the code project, a pre-defined warning is issued.

[0191] In one or more embodiments, after the processor executes step 801 to compare the running behavior of the code project with the running behavior of the adaptation proxy layer, and detects the consistency between the baseline specification and the code project based on the comparison result, it further executes: When it is determined that the baseline specification and the code project are consistent, the request to call the code project will be switched from the interface of the code project to the adaptation proxy layer.

[0192] In one or more embodiments, after the processor executes step 801 to generate the adaptation proxy layer corresponding to the code project according to the adaptation rule set, it further executes: When the target specification changes, the adaptation proxy layer is updated based on the changes in the target specification.

[0193] In the embodiments of this specification, the metadata includes static metadata reflecting source code information and dynamic metadata reflecting actual runtime behavior information. Based on the target specification's format, the metadata is processed to obtain a baseline specification. The baseline specification can characterize the actual interface behavior of the code project using the unified semantic paradigm defined by the target specification, and can be parsed and used by the target specification system. Furthermore, the baseline specification is compared with the target specification to obtain the difference results, and an adaptation rule set corresponding to the code project is generated based on these differences. Each adaptation rule in the set closely corresponds to the actual difference between the code project and the target specification, ensuring the accuracy of the adaptation rule set without requiring manual organization and writing of adaptation logic. Furthermore, an adaptation proxy layer corresponding to the code project is generated based on the adaptation rule set. The adaptation proxy layer responds to call requests and provides the services corresponding to the code project, achieving compatibility between the code project and the target specification system.

[0194] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented. Each of the above methods can be executed by a computer program instructing related hardware. The program corresponding to the above methods can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium of the electronic device 800 can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0195] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0196] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A code project adaptation method, characterized in that, The method includes: Static analysis and runtime data collection are performed on the code project to obtain the metadata corresponding to the code project. The metadata is structured based on the target specification format, and the structured processing result is mapped based on mapping rules to obtain the baseline specification. The baseline specification is compared with the target specification to obtain the difference results, and an adaptation rule set corresponding to the code project is generated based on the difference results; Based on the set of adaptation rules, an adaptation proxy layer corresponding to the code project is generated; wherein, the adaptation proxy layer is used to call the code project based on the target specification.

2. The code project adaptation method according to claim 1, characterized in that, The static analysis and runtime data collection of the code project yields the metadata corresponding to the code project, including: Static analysis is performed on the code project to obtain its static metadata; By attaching a bypass probe to the runtime environment of the code project, dynamic metadata of the code project is collected during runtime; wherein, the metadata includes the static metadata and the dynamic metadata.

3. The code project adaptation method according to claim 1, characterized in that, The process of structuring the metadata based on the target specification format and mapping the structuring results to obtain the baseline specification based on mapping rules includes: The metadata is structured based on the target specification format to obtain multiple structured processing results; The multiple structured processing results are mapped based on mapping rules, and conflicting fields in the structured processing results are resolved and / or missing fields are filled in to obtain the baseline specification.

4. The code project adaptation method according to claim 3, characterized in that, After mapping the multiple structured processing results based on mapping rules, resolving conflicting fields and / or completing missing fields in the structured processing results to obtain the baseline specification, the process further includes: Verify whether the baseline specifications meet the integrity and correctness requirements; Once it is determined that the baseline specification meets the integrity requirements and the correctness requirements, the baseline specification and the code project are associated and stored.

5. The code project adaptation method according to claim 1, characterized in that, The step of comparing the baseline specification with the target specification to obtain the difference result, and generating an adaptation rule set corresponding to the code project based on the difference result, includes: The baseline specification is compared with the target specification based on multiple dimensions to obtain the difference results; wherein, the multiple dimensions include at least one of the interface dimension, data dimension, and logic dimension; The difference results are classified according to a preset strategy, and the difference items that meet the requirements of the preset strategy are identified to form an adaptation rule set.

6. The code project adaptation method according to claim 1, characterized in that, Before generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the method further includes: The set of adaptation rules is subjected to conflict verification and matching verification; wherein, the conflict verification is used to detect whether there is a logical conflict between the adaptation rules in the set of adaptation rules, and the matching verification is used to detect whether each adaptation rule matches the code project and the target specification; The step of generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set includes: When the set of adaptation rules is determined to pass the conflict check and matching check, an adaptation proxy layer corresponding to the code project is generated based on the set of adaptation rules.

7. The code project adaptation method according to claim 1, characterized in that, After generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the process further includes: In the test environment, a first test result is obtained by calling the code project through the adaptation proxy layer based on the first request corresponding to the target specification, and a second test result is obtained by calling the code project based on the second request corresponding to the interface of the code project. Compare whether the first test result and the second test result are the same; When the first test result and the second test result are determined to be the same, a call association relationship is established between the adaptation proxy layer and the code project.

8. The code project adaptation method according to claim 1, characterized in that, After generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the process further includes: The adaptation proxy layer is deployed independently between the code project and the external system of the target specification.

9. The code project adaptation method according to claim 1, characterized in that, After generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the process further includes: The runtime behavior of the code project is compared with the runtime behavior of the adaptation proxy layer, and the consistency between the baseline specification and the code project is detected based on the comparison results; When a discrepancy is found between the baseline specification and the code project, a pre-defined warning is issued.

10. The code project adaptation method according to claim 9, characterized in that, After comparing the runtime behavior of the code project with the runtime behavior of the adapted proxy layer, and detecting the consistency between the baseline specification and the code project based on the comparison results, the method further includes: When it is determined that the baseline specification and the code project are consistent, the request to call the code project will be switched from the interface of the code project to the adaptation proxy layer.

11. The code project adaptation method according to claim 1, characterized in that, After generating the adaptation proxy layer corresponding to the code project based on the adaptation rule set, the process further includes: When the target specification changes, the adaptation proxy layer is updated based on the changes in the target specification.

12. A code project adaptation device, characterized in that, The device includes: The data acquisition module is used to perform static analysis and runtime data collection on the code project to obtain the metadata corresponding to the code project. The baseline specification module is used to perform structured processing on the metadata based on the format of the target specification, and to map the structured processing result to obtain the baseline specification based on the mapping rules. The adaptation rules module is used to compare the baseline specification with the target specification to obtain the difference results, and generate an adaptation rule set corresponding to the code project based on the difference results; The proxy generation module is used to generate an adaptation proxy layer corresponding to the code project according to the adaptation rule set; wherein the adaptation proxy layer is used to call the code project based on the target specification.

13. A computer program product, characterized in that, The computer program product stores multiple instructions, which are adapted to be loaded by a processor and executed as the method steps of any one of claims 1 to 11.

14. A computer storage medium, characterized in that, The computer storage medium stores multiple instructions, which are adapted to be loaded by a processor and executed as the method steps of any one of claims 1 to 11.

15. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps of any one of claims 1 to 11.

Images