Front-end service code differentiation generation and updating method and system based on AST

Abstract

The invention discloses a front-end service code differentiation generation and updating method and system based on AST, and belongs to the technical field of computers, and the key points of the technical scheme are that the method comprises the following steps: converting a service code into an abstract syntax tree, traversing each node in the abstract syntax tree, and determining a method name; determining a first node and a second node according to a zero-width character mark in the method name, wherein the zero-width character mark is generated according to the interface document metadata; the first node is subjected to semantic matching detection, the first node is updated according to the detection result, the node type is accurately recognized by embedding the zero-width character subjected to special coding, differentiation comparison of code logic is achieved through subsequent semantic matching detection, then leaf nodes with differences are accurately replaced, and therefore the accuracy of the method is improved. According to the method, the performance loss caused by global comparison is avoided, the code generation and replacement of a single interface level can be realized, and the redundancy change caused by batch operation is avoided.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and more particularly to an AST-based front-end service code differential generation and update method and system. Background Art

[0002] In modern front-end development, interface document management tools, such as Yapi and Swagger, are often used to automatically generate service layer code. Traditional code generation methods usually rely on string concatenation. With this generation method, when developers modify the generated Service file, regenerating it will completely overwrite the previously manually modified content. Developers cannot additionally generate code for different interface groups in the same Service file, nor can they independently update a single interface. Batch full-scale operations are required, so the existing technology has shortcomings. Summary of the Invention

[0003] In view of the shortcomings of the existing technology, the purpose of the present invention is to provide a front-end service code differentiated generation and update method and system based on AST. Through the recognition of zero-width characters and node-level replacement steps, it can distinguish the code automatically generated by the system and the code modified by the developer, and accurately identify the modification status, realize on-demand replacement, and avoid global comparison.

[0004] To achieve the above object, the present invention provides the following technical solutions:

[0005] The present invention provides a front-end service code differential generation and update method based on AST, including:

[0006] Convert the service code into an abstract syntax tree, and traverse each node in the abstract syntax tree to determine the method name;

[0007] Determine a first node and a second node according to the method name, wherein the first node is a node corresponding to the system-generated code, and the second node is a node corresponding to the custom code;

[0008] Perform a semantic matching check on the first node, and update the first node according to the check result.

[0009] As a further improvement of the present invention, determining the first node and the second node according to the method name includes:

[0010] Determine whether there is a zero-width character mark in the method name, where the zero-width character mark is generated according to the interface document metadata;

[0011] If the zero-width character mark exists, the node corresponding to the method name is the first node;

[0012] If the zero-width character mark does not exist, the node corresponding to the method name is the second node.

[0013] As a further improvement of the present invention, the zero-width character mark is generated according to the interface document metadata, including:

[0014] Extracting key identifiers from the interface document metadata, the key identifiers including interface categories and interface items;

[0015] The zero-width character mark is generated according to the key identifier and the shift encryption algorithm, and the zero-width character mark is appended to the end of the method name.

[0016] As a further improvement of the present invention, performing semantic matching detection on the first node and updating the first node according to the detection result includes:

[0017] Reversely parse the zero-width character mark corresponding to the first node to obtain the original interface identifier;

[0018] Determining an interface corresponding to the first node according to the original interface identifier and the current interface document;

[0019] Perform a semantic matching check on the first node according to the interface, and update the first node according to the check result.

[0020] As a further improvement of the present invention, performing semantic matching detection on the first node according to the interface and updating the first node according to the detection result includes:

[0021] Performing semantic matching detection on the first node according to the interface definition;

[0022] According to the detection result and a preset standard, the first node is divided into an unmodified node and a modified node;

[0023] The unmodified node and the modified node are updated respectively.

[0024] As a further improvement of the present invention, updating the unmodified node includes:

[0025] Generate code according to the interface definition, and convert the code generated according to the interface definition into a syntax tree node;

[0026] The unmodified node is replaced with the syntax tree node.

[0027] As a further improvement of the present invention, updating the modified node includes:

[0028] Determining, from the modified nodes according to the interface definition, a node associated with the interface definition;

[0029] Determining a changed leaf node from leaf nodes corresponding to the nodes associated with the interface definition according to the changed portion of the interface definition;

[0030] Generate code according to the changed portion, and convert the code generated according to the changed portion into syntax tree child nodes;

[0031] The changed leaf node is replaced with the syntax tree leaf node.

[0032] As a further improvement of the present invention, the front-end service code differential generation and update method also includes retaining the custom business logic when updating the first node.

[0033] As a further improvement of the present invention, the front-end service code differential generation and update method further includes:

[0034] Determining an associated scope variable according to the changed leaf node;

[0035] Type deduction and compatibility checking are performed on the associated scope variables.

[0036] The present invention provides a front-end service code differentiation generation and update system based on AST, including:

[0037] A conversion module, configured to convert the service code into an abstract syntax tree, and traverse each node in the abstract syntax tree to determine the method name;

[0038] a determination module, configured to determine a first node and a second node according to the method name, wherein the first node is a node corresponding to the system-generated code, and the second node is a node corresponding to the custom code;

[0039] An updating module is used to perform a semantic matching detection on the first node and update the first node according to the detection result.

[0040] The present invention adds a zero-width character mark to the method name, and determines whether the corresponding node has been modified by identifying the zero-width character mark, without traversing all nodes and determining the modified nodes. In addition, the present invention only updates the leaf nodes related to the interface changes, which can minimize the scope of code modification and realize the independent update of a single interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a flow chart of the method steps of the present invention;

[0042] Figure 2 A schematic diagram of the steps for determining the first node and the second node;

[0043] Figure 3 Schematic diagram of the steps for updating the first node;

[0044] Figure 4 Schematic diagram of the steps to update a modified node. DETAILED DESCRIPTION

[0045] The technical solution of the present invention is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations of the technical solution of the present invention.

[0046] The term "and / or" in the following text simply describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " generally indicates an "or" relationship between the related objects.

[0047] In modern front-end development, interface document management tools, such as Yapi and Swagger, are often used to automatically generate Service layer code. Traditional code generation methods usually rely on string concatenation. When developers modify the generated Service files, regeneration will cause the manually modified content to be completely overwritten. For example, tools such as Swagger Codegen will generate a complete Service layer code file based on the overall information of the interface document and a preset template. When the code is regenerated, the entire file will be directly overwritten with the newly generated content. This is because its original design intention is to generate code quickly and uniformly, and it does not take into account that developers will make personalized modifications to the generated code.

[0048] Moreover, in traditional code generation, interfaces in interface documents are usually organized into interface groups. When generating Service layer code, code generation tools generate code based on the information of the entire interface group, that is, all interface-related codes in an interface group are generated at once, rather than processing each interface independently. This generation method based on interface groups makes it difficult to append and generate code for different interface groups in the same Service file. At the same time, traditional generation methods also make it difficult to independently update a single interface, because it is necessary to re-parse the information of the entire interface group and then process the code generation for a single interface separately. Existing tools generally do not provide such functionality, so only batch full operations can be performed. Although the abstract syntax tree (AST) can be used to analyze code structure, existing AST generation solutions lack a code modification status tracking mechanism and cannot distinguish between code automatically generated by the system and code modified by the developer.

[0049] Therefore, in order to solve the above problems, Figure 1As shown, the embodiment of the present application provides a front-end service code differential generation and update method based on AST, including:

[0050] Convert the service code into an abstract syntax tree and traverse each node in the abstract syntax tree to determine the method name;

[0051] Determine the first node and the second node according to the method name, the first node is the node corresponding to the system-generated code, and the second node is the node corresponding to the custom code;

[0052] Perform a semantic matching check on the first node, and update the first node according to the check result.

[0053] The service code can be converted into an abstract syntax tree (AST) using an AST parsing engine. An AST parsing engine is a program that reads the service code text, parses the code according to specific grammatical rules, and converts it into a tree structure, an abstract syntax tree. In this tree structure, each node represents a grammatical structure or element in the code, and the relationships between nodes reflect the grammatical and logical structure of the code.

[0054] Specifically, the nodes in the abstract syntax tree cover various components in the program, such as variable declarations, expressions, statements, comments, etc. The method name is the name used to identify a specific behavior or operation in a class or object, and not all nodes have corresponding method names. Usually, when declaring a function or defining a method, the corresponding node is used to represent the method name. For example, in JavaScript, the function declaration will be parsed into a FunctionDeclaration node, where the Identifier node corresponding to the id attribute represents the method name; in the class method definition, the Identifier node corresponding to the key attribute of the ClassMethod node represents the method name. Therefore, this embodiment needs to traverse each node and then determine each method name.

[0055] Further, such as Figure 2 As shown, this embodiment provides a step of determining a first node and a second node according to a method name, including:

[0056] Determine whether there is a zero-width character mark in the method name. The zero-width character mark is generated according to the interface document metadata.

[0057] If there is a zero-width character token, the node corresponding to the method name is the first node;

[0058] If there is no zero-width character mark, the node corresponding to the method name is the second node.

[0059] Furthermore, this embodiment provides a step of generating a zero-width character mark according to the interface document metadata, including:

[0060] Extract key identifiers from the interface document metadata, including interface category and interface item;

[0061] Generate a zero-width character token according to the key identifier and the shift encryption algorithm, and append the zero-width character token to the end of the method name.

[0062] Among them, interface document metadata is some descriptive data about the interface document, such as the title, author, creation time, modification time, version number of the interface document, as well as some specific attributes used to identify and classify documents in the document management system, such as catid (category ID) and projectid (project ID) in YAPI.

[0063] When generating service code, it is necessary to extract key identifiers from the interface document metadata, and then generate invisible zero-width character token sequences through a displacement encryption algorithm, and inject these tokens into the generated code. The displacement encryption algorithm converts digital identifiers into Unicode zero-width character token combinations. Zero-width character tokens are usually invisible in text, which can ensure the uniqueness and concealment of the tokens. Generating zero-width character tokens is a one-time operation and only needs to be performed when the code is generated for the first time.

[0064] Specifically, the key identifiers in the interface document metadata refer to those important information that can uniquely identify the interface. For example, in interface management tools such as YAPI, catid represents the category ID to which the interface belongs. Interfaces are generally classified according to functions, modules, etc., and each category has a unique ID. For example, in an e-commerce system, there may be categories such as "product interface", "order interface", and "user interface". Each category has a corresponding catid, and the category to which the interface belongs can be clearly identified through the catid; projectid is the ID of the project to which the interface belongs. A project may contain multiple interface categories, and each project has a unique projectid. Therefore, combining catid and projectid can uniquely identify an interface. Therefore, when generating code, this embodiment generates zero-width character tags based on these key identifiers and injects them into the code, so that a one-to-one correspondence can be established between the code and the interface. After the code is converted into a node of the abstract syntax tree, a correspondence between the node and the interface can be established.

[0065] For example, assuming that the method name is getUserInfo, the zero-width character mark is represented by \u200B\u200C, and the zero-width character mark is appended to the end of the method name to obtain getUserInfo\u200B\u200C.

[0066] Furthermore, the above method of adding zero-width character marks can also be used to bind code and interface with the help of hidden fields in JSDoc comments. JSDoc is a specification and tool for adding comments to JavaScript code. For example, encrypted tags can be injected into the hidden fields of JSDoc comments, such as adding a custom tag "@generated-id" to store the ciphertext of the original interface ID, so that when parsing the code comments, the interface corresponding to the code can be obtained.

[0067] Finally, after traversing each node and identifying each method name, identify whether each method name contains a zero-width character mark. If it does, it means that the code corresponding to the method name is system-generated code. The system-generated code is usually automatically generated based on the interface definition. When the interface changes, this part of the code may need to be updated accordingly to adapt to the new interface specification, so subsequent in-depth analysis is required; if it does not, it means that the code corresponding to the method name is customized by the developer. The developer's customized code often contains specific business logic, personalized function implementation, or supplement and extension of the system-generated code. Retaining this part of the code can ensure the integrity and correctness of the business logic.

[0068] Further, such as Figure 3 As shown, this embodiment provides a step of performing semantic matching detection on a first node and updating the first node according to the detection result, including:

[0069] Reversely parse the zero-width character mark corresponding to the first node to obtain the original interface identifier;

[0070] Determine the interface corresponding to the first node according to the original interface identifier and the current interface document;

[0071] Perform semantic matching detection on the first node according to the interface, and update the first node according to the detection result.

[0072] Specifically, a bit shift encryption algorithm, the reverse of the encryption process, is first used to restore the zero-width character token to the original interface ID. For example, if each bit of a number is mapped to a specific zero-width character during encryption, the zero-width character is mapped back to a number during reverse parsing. The current interface document is then retrieved, and each interface ID in the document is iterated over to find the one that matches the original interface ID. This is then used as the interface corresponding to the first node.

[0073] For example, suppose the method name corresponding to the first node is getUserInfo\u200B\u200C, where \u200B\u200C is a zero-width character token. Reverse-analyzing this token reveals the original interface ID is 123. Then, using the YAPI API to retrieve all interface information for the current interface document, a search reveals an interface with the ID 123, named "Get User Information," and the request path is / api / user / info. Therefore, we can determine that the specific interface corresponding to getUserInfo is the "Get User Information" interface.

[0074] Furthermore, this embodiment provides a step of performing a semantic matching detection on a first node according to an interface, and updating the first node according to the detection result, including:

[0075] Performing semantic matching detection on the first node according to the interface definition;

[0076] According to the detection result and the preset standard, the first node is divided into an unmodified node and a modified node;

[0077] Update unmodified nodes and modified nodes separately.

[0078] The interface definition is a detailed description of the interface, including key information such as the interface's function, input, output, and usage.

[0079] After finding the corresponding interface ID from the current interface document, the definition of the interface is obtained from it, and a semantic matching check is performed based on the interface definition. The semantic matching includes consistency checks at the key structure, code logic, and semantic levels.

[0080] Specifically, we first focus on the similarity between the first node and the interface definition in terms of key structure. Taking the HTTP request interface as an example, the request path, request method (GET, POST, etc.), and parameter structure are all key structural elements. If the request path corresponding to the first node is exactly the same as the interface definition, and the number, type, and order of parameters also match, it means that the first node and the interface definition have a high degree of match in terms of key structure. For example, assuming that the request path in the interface definition is / api / users / {id}, the request path corresponding to the corresponding AST node in the code is also / api / users / {id}, and the structure of the passed parameters is also consistent with the interface definition, it means that the first node and the interface definition have a high degree of match in terms of key structure.

[0081] Next, the consistency check of the code logic is carried out. The code logic includes the processing logic for the data returned by the interface, the implementation method of the business rules, etc. If the interface definition stipulates that the data returned by the interface needs to be parsed and converted in a specific format, and the code logic corresponding to the first node is consistent with the interface definition, it means that the code logic matches well. For example, assuming that the data returned by the interface is in JSON format and contains the name and age fields, the code corresponding to the first node can correctly extract these two fields and process them according to business requirements, such as capitalizing the first letter of the name and performing a validity check on the age. This is consistent with the expected processing logic in the interface definition, indicating that the interface definition and the first node have a high degree of match in code logic.

[0082] Ultimately, it's necessary to determine, at a semantic level, whether the meaning expressed by the first node is consistent with the interface definition. This means that even if the syntax of the code corresponding to the first node differs slightly, as long as the semantics expressed are the same, the match is still high. For example, when processing interface response data, one implementation uses an if-else statement to determine the response status code, while another uses a switch statement. Although the grammatical forms differ, both semantically determine and process the response status in a reasonable manner, meeting the semantic requirements of the interface definition, indicating a high degree of match at the semantic level.

[0083] The first nodes are divided into unmodified nodes and modified nodes based on the results of the above semantic matching detection and preset criteria. The preset criteria can be determined based on actual conditions. For example, the first node with a high degree of matching in key structure, code logic, and semantic level can be marked as an unmodified node, and the other first nodes can be marked as modified nodes.

[0084] Furthermore, this embodiment provides a step of updating an unmodified node, including:

[0085] Generate code according to the interface definition, and convert the code generated according to the interface definition into syntax tree nodes;

[0086] Replaces an unmodified node with a syntax tree node.

[0087] Specifically, the interface document may be updated as business needs change. For example, when generating the method name, the data returned by the product list interface only includes the product name and price, while the interface definition in the current interface document has added product inventory information. At this time, although the degree of semantic matching is high, indicating that these nodes have not been substantially modified, there are still subtle differences. Therefore, in order to ensure that the code corresponding to these nodes can reflect the latest status of the current interface document, these nodes still need to be updated.

[0088] At this time, a matching code structure is directly generated based on the current latest interface definition, and these codes can be converted into nodes in the syntax tree. The unmodified nodes are directly replaced with the syntax tree nodes, avoiding complex local modifications to each node and reducing the possibility of errors.

[0089] Further, such as Figure 4 As shown, this embodiment provides a step of updating a modified node, including:

[0090] Determine, from the modified nodes, nodes associated with the interface definition according to the interface definition;

[0091] According to the changed portion of the interface definition, determining the changed leaf node from the leaf nodes corresponding to the nodes associated with the interface definition;

[0092] Generate code based on the changed part, and convert the generated code based on the changed part into syntax tree child nodes;

[0093] Replaces a change leaf node with a syntax tree leaf node.

[0094] Among them, the associated nodes are specifically nodes with strong associations. The strongly associated nodes refer to nodes that directly determine the interface call behavior and data processing method, such as HTTP request path, parameter passing structure, and return data processing logic.

[0095] Specifically, the matching degree of the modified node is low, which means that the developer has added some customized business logic based on the code automatically generated by the system, such as error handling, log output, specific algorithm implementation, etc. Among these customized business logics, not all logics depend on the details of the interface definition, but these customized business logics are intended to meet specific business needs and should not be simply overwritten. If the modified node is directly replaced, the business logic added by the developer will be destroyed, resulting in code errors. Therefore, this embodiment only identifies nodes that are strongly related to the interface definition.

[0096] Then, the changed part of the interface definition is determined based on the original interface definition and the current interface definition, and the leaf nodes involved in the changed part are determined from the leaf nodes corresponding to the nodes that are strongly associated with the interface definition, as the changed leaf nodes, where the leaf nodes refer to nodes that no longer contain other child nodes.

[0097] Finally, the corresponding code is generated according to the changed part, and the code is converted into syntax tree child nodes. The syntax tree child nodes are used to replace the changed leaf nodes, reducing the impact on the developer's customized content and thus avoiding the introduction of new errors.

[0098] Furthermore, after updating the modified node, it is necessary to determine the associated scope variables based on the changed leaf nodes, and perform type deduction and compatibility verification on the associated scope variables.

[0099] Among them, scope variables refer to variables with specific scopes in the program. The scope is the area where variables are defined in the program, which determines the visibility and life cycle of the variables; associated scope variables refer to scope variables affected when leaf nodes are replaced. Associated scope variables can be determined based on the impact of leaf node replacement on code logic and data flow.

[0100] Specifically, first check whether the leaf node being changed directly uses or operates on certain variables. For example, if the leaf node is a variable access node (such as data in data.name), when replacing this leaf node, the interface returns a change in data structure, such as a change in data's type or attributes. In this case, the data variable is the affected scope variable. If the leaf node represents a parameter of a function call (such as param in sendRequest(param)), replacing this leaf node will also modify the logic related to param. In this case, the variables within the scope of param are the associated scope variables.

[0101] Then, starting from the changed leaf node, trace along the data flow in the code. If the replacement of the leaf node will cause a change in the generation, transmission or processing of data, then the variables involved in this data flow path are all affected scope variables. For example, after the leaf node corresponding to the processing logic of the interface return data is replaced, the returned data is assigned to a variable after a series of processing. This variable and other variables that subsequently depend on this variable are all associated scope variables. Suppose the data returned by the interface originally only contains the id and name fields, and an email field is added after the leaf node is replaced. The code that processes the returned data assigns the new email field to the userEmail variable. Later, other logic uses the userEmail variable for operations. In this case, the userEmail variable and the variables that depend on it are all affected scope variables.

[0102] In addition, the scope of the changed leaf node can also be determined, including function scope, block scope, etc. Within this scope, as well as in the external scopes that this scope can access (such as closures), variables related to the changed leaf node are all associated scope variables. For example, when a leaf node inside a function is replaced, the variables defined inside the function and the external scope variables that the function can access are all associated scope variables. If a function uses a variable in an external scope to construct an interface request parameter, when the leaf node related to the interface request parameter is replaced, this external scope variable is also an associated scope variable.

[0103] Specifically, type inference refers to the automatic inference of the data type of a variable, expression, or function return value by a programming language or related tool based on contextual information in the code. Compatibility checking involves verifying that different data types, interfaces, and functions can be used together and whether they will cause runtime errors or semantic conflicts. Type inference and compatibility checking are designed to ensure that the code correctly handles data type issues when faced with interface changes, thereby ensuring code stability and correctness.

[0104] To further illustrate the specific steps of this embodiment, a specific example is provided below. Assume that in the front-end development of an e-commerce platform, there are multiple product-related interfaces, such as a product list interface, a product details interface, and a product classification interface. The definitions of these interfaces are stored in Yapi. As the business develops, the interfaces may change, such as the addition or removal of request parameters or changes in the return data structure. In this case, a mechanism is needed to ensure that the front-end service code can promptly and accurately reflect changes in the interface documents while retaining the business logic manually added by the developer.

[0105] Taking the product category interface as an example, find the product category interface in Yapi's interface documentation, obtain the interface's catid and projectid, and use them as key identifiers. Then, use a bit shift encryption algorithm to convert the catid and projectid into a zero-width character token sequence, \u200C\u200D\u200B. When generating the getProductCategories service code to retrieve the product category list, append the zero-width character token sequence to the end of the method name, forming getProductCategories\u200C\u200D\u200B. Furthermore, in the hidden field of the JSDoc comment for getProductCategories, use the @generated-id tag to record the ciphertext of the original interface ID.

[0106] As business needs evolved, the request path for the product category API changed from / api / categories to / api / v2 / categories, and a new "total" field was added to the returned data structure to represent the total number of categories. When code updates were needed, the AST parsing engine was used to scan the code files. When the getProductCategories\u200C\u200D\u200B method name was encountered, it was identified as containing a zero-width character marker, indicating that the method was system-generated code. The zero-width character marker sequence, \u200C\u200D\u200B, was then reverse-parsed to recover the original catid and projectid. This was then compared with the information for the product category API in the current Yapi API to confirm the source of the corresponding interface.

[0107] The current interface definition is obtained according to the interface source, and semantic matching is performed based on the current interface definition. If most of the logic in the interface definition meets the semantic fingerprint matching standard of the corresponding AST node, for example, the basic calling logic of the method and the parameter passing method have not changed, but the request path and return data structure have changed, then these AST nodes are regarded as unmodified nodes and directly replaced with the newly generated code structure.

[0108] If the semantic fingerprint doesn't match the required level, for example, if the developer added error handling logic to the original getProductCategories method, the code will be updated in precise replacement mode, updating only the parts related to the interface change—the request path and return data processing logic—while retaining the developer's added error handling logic. Type inference and compatibility checks are then performed on the affected scope variables. For example, since a new "total" field has been added to the return data structure, it's important to ensure that subsequent uses of the method's return value correctly handle this new field. If type incompatibilities are discovered, adjustments must be made promptly to avoid syntax errors.

[0109] The embodiment of the present application provides a method for differential generation and update of front-end service codes based on AST, which embeds specially encoded zero-width character markers in the interface method as implicit markers of the developer's modification status, establishes a traceable relationship between the code and the interface document, and reduces maintenance costs. Moreover, the marker can accurately identify and distinguish between unmodified and modified code when regenerating the code, avoiding the performance loss caused by full comparison. Afterwards, AST parsing means are used to achieve differential comparison of code logic updates through node-level fine comparison, determine modified nodes and unmodified nodes, and then accurately replace the leaf nodes of the modified nodes. By detecting the zero-width character marker after the method name and comparing the subsequent AST nodes, a unique dual matching mechanism is formed, which can not only lock the modification status globally, but also ensure that only the modified part is replaced at a local fine-grained level, realizing differential comparison and fully meeting the needs of complex front-end service code generation.

[0110] Furthermore, the embodiments of the present application ensure that the developer's newly added business logic (such as exception handling and log printing) is fully preserved through AST leaf node level difference comparison, eliminating the problem of accidentally overwriting the developer's modified code when repeatedly generating code in traditional methods. At the same time, by replacing the corresponding modified leaf node of each interface, code generation and replacement at the individual interface level is achieved, avoiding redundant changes caused by batch operations and breaking the limitation that the same file cannot be used to generate different interface groups in batches.

[0111] Furthermore, the embodiment of the present application provides a front-end service code differentiation generation and update system based on AST, including:

[0112] The conversion module is used to convert the service code into an abstract syntax tree and traverse each node in the abstract syntax tree to determine the method name;

[0113] A determination module, configured to determine a first node and a second node according to a method name, wherein the first node is a node corresponding to a system-generated code and the second node is a node corresponding to a custom code;

[0114] The updating module is used to perform semantic matching detection on the first node and update the first node according to the detection result.

[0115] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0116] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0117] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0118] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. The front-end service code differential generation and update method based on AST is characterized by: include: Convert the service code into an abstract syntax tree, and traverse each node in the abstract syntax tree to determine the method name; Determine a first node and a second node according to the method name, wherein the first node is a node corresponding to the system-generated code, and the second node is a node corresponding to the custom code; Perform a semantic matching check on the first node, and update the first node according to the check result.

2. The AST-based front-end service code differential generation and update method according to claim 1 is characterized in that: The determining the first node and the second node according to the method name includes: Determine whether there is a zero-width character mark in the method name, where the zero-width character mark is generated according to the interface document metadata; If the zero-width character mark exists, the node corresponding to the method name is the first node; If the zero-width character mark does not exist, the node corresponding to the method name is the second node.

3. The AST-based front-end service code differential generation and update method according to claim 2 is characterized in that: The zero-width character mark is generated according to the interface document metadata, including: Extracting key identifiers from the interface document metadata, the key identifiers including interface categories and interface items; The zero-width character mark is generated according to the key identifier and the shift encryption algorithm, and the zero-width character mark is appended to the end of the method name.

4. The AST-based front-end service code differential generation and update method according to claim 2 is characterized in that: The performing semantic matching detection on the first node and updating the first node according to the detection result includes: Reversely parse the zero-width character mark corresponding to the first node to obtain the original interface identifier; Determining an interface corresponding to the first node according to the original interface identifier and the current interface document; Perform a semantic matching check on the first node according to the interface, and update the first node according to the check result.

5. The AST-based front-end service code differential generation and update method according to claim 4 is characterized in that: The performing semantic matching detection on the first node according to the interface, and updating the first node according to the detection result, includes: Performing semantic matching detection on the first node according to the interface definition; According to the detection result and a preset standard, the first node is divided into an unmodified node and a modified node; The unmodified node and the modified node are updated respectively.

6. The AST-based front-end service code differential generation and update method according to claim 5 is characterized in that: Updating the unmodified node includes: Generate code according to the interface definition, and convert the code generated according to the interface definition into a syntax tree node; The unmodified node is replaced with the syntax tree node.

7. The AST-based front-end service code differential generation and update method according to claim 6 is characterized in that: Updating the modified node, including: Determining, from the modified nodes according to the interface definition, a node associated with the interface definition; Determining a changed leaf node from leaf nodes corresponding to the nodes associated with the interface definition according to the changed portion of the interface definition; Generate code according to the changed portion, and convert the code generated according to the changed portion into syntax tree child nodes; The changed leaf node is replaced with the syntax tree leaf node.

8. The AST-based front-end service code differential generation and update method according to claim 1 is characterized in that ,The front-end service code differentiated generation and update method also includes retaining custom business logic when updating the first node.

9. The AST-based front-end service code differential generation and update method according to claim 7 is characterized in that ,The front-end service code differentiated generation and update method also includes: Determining an associated scope variable according to the changed leaf node; Type deduction and compatibility checking are performed on the associated scope variables.

10. A front-end service code differential generation and update system based on AST, used to implement the front-end service code differential generation and update method based on AST according to any one of claims 1 to 9, characterized in that: include: A conversion module, configured to convert the service code into an abstract syntax tree, and traverse each node in the abstract syntax tree to determine the method name; a determination module, configured to determine a first node and a second node according to the method name, wherein the first node is a node corresponding to the system-generated code, and the second node is a node corresponding to the custom code; An updating module is used to perform a semantic matching detection on the first node and update the first node according to the detection result.

Images