Code review method and device based on knowledge base assistance, equipment and medium

Abstract

The invention relates to the technical field of infrastructure operation and maintenance, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a code review method, device and equipment based on knowledge base assistance and a medium. Constructing a domain knowledge base based on domain proper nouns and code entity naming specifications; constructing an architecture knowledge base based on the code framework specification; obtaining a to-be-reviewed code change; component calling, naming specifications and structure specifications in the to-be-examined code change are examined, and corresponding examination results are generated; and generating a code review report according to the check result. By constructing the component knowledge base, the field knowledge base and the architecture knowledge base, multi-dimensional joint inspection of code changes from component calling and naming specifications to architecture specifications is achieved, the automation level of code inspection can be improved, manual dependence is reduced, and code quality and normalization are enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of infrastructure operation and maintenance, and particularly relates to a code review method and device based on knowledge base assistance, equipment and storage medium. BACKGROUND

[0002] In the prior art, there are many deficiencies in code quality management during large system development, especially in the inspection of enterprise self-defined technical specifications, naming specifications and system architecture specifications. There is generally a lack of efficient and automated auxiliary means. Specifically, existing general code scanning tools usually focus on general vulnerability detection and are difficult to identify enterprise-specific security component configurations. They cannot combine the specification system accumulated by the enterprise's historical projects to conduct comprehensive and accurate inspection of new codes. At the same time, important quality standards such as code naming specifications and system structure specifications depend on the subjective understanding and manual review of developers, which is low in efficiency and poor in accuracy, and is likely to result in inadequate specification execution, affecting the overall maintainability and security of the system.

[0003] In the field of financial technology business, the development process of a project is usually accompanied by complex system architecture and strict security compliance requirements. In order to meet the risk control requirements and data security standards, enterprises generally configure security components such as XSS injection interceptors, SQL injection interceptors and authority verification. However, existing technical means are difficult to automatically identify and verify whether the newly added code correctly integrates these enterprise-defined security components, resulting in a risk of missing security configurations in the system. At the same time, financial technology projects have high requirements for code structure and naming specifications. However, since the naming specification inspection mainly relies on manual execution, it is easy to deviate from the business meaning of non-standard variable names, class names and method names, which seriously affects the readability, maintainability and long-term stability of the system code.

[0004] In the field of medical and health business, system development also faces strict specification requirements and quality standards. Medical information systems involve a large amount of patient data and sensitive information, and the development process needs to ensure that the system architecture is clear and the module division is reasonable, so as to prevent the decline of system stability due to chaotic structure or incorrect dependency relationship. However, due to the limitations of existing technical means, the execution of system architecture specifications by developers mainly relies on personal experience and lacks an automated structure compliance checking mechanism, which is prone to problems such as unreasonable hierarchical division and chaotic module dependency relationship. In addition, there are many professional terms in the medical and health business, and if the code naming does not conform to the industry conventions or the internal specifications of the institution, it is easy to cause ambiguity of functions, affecting the system maintenance efficiency and business logic accuracy. SUMMARY

[0005] The main purpose of the present application is to provide a knowledge base assisted code review method, device, equipment and storage medium, aiming at solving the technical problems that the prior art cannot automatically review the specification compliance of enterprise specific components, domain terminology and architecture framework, resulting in limited review range, low efficiency and easy to miss customized specifications.

[0006] To achieve the above purpose, the present application provides a knowledge base assisted code review method, comprising:

[0007] Extracting the use specification of the project preset component from the project historical code to construct a component knowledge base;

[0008] Based on the preset domain proper noun and code entity naming specification, a domain knowledge base is constructed;

[0009] Based on the preset code framework specification, an architecture knowledge base is constructed;

[0010] Obtaining the code change to be reviewed;

[0011] Based on the component knowledge base, check whether the call to the project preset component in the code change to be reviewed conforms to the use specification, and generate a first check result;

[0012] Based on the domain knowledge base, check whether the code entity naming in the code change to be reviewed conforms to the code entity naming specification, and generate a second check result;

[0013] Based on the architecture knowledge base, check whether the code structure of the code change to be reviewed conforms to the code framework specification, and generate a third check result;

[0014] Based on the first check result, the second check result and the third check result, a code review report is generated.

[0015] Further, to achieve the above purpose, the present application provides a knowledge base assisted code review device, comprising:

[0016] The component knowledge base construction module is used for extracting the use specification of the project preset component from the project historical code to construct a component knowledge base;

[0017] The domain knowledge base construction module is used for constructing a domain knowledge base based on the preset domain proper noun and code entity naming specification;

[0018] The architecture knowledge base construction module is used for constructing an architecture knowledge base based on the preset code framework specification;

[0019] The code change obtaining module is used for obtaining the code change to be reviewed;

[0020] The component calling checking module is configured to check, based on the component knowledge base, whether the calling of the preset component in the to-be-checked code change conforms to the usage specification, and generate a first checking result;

[0021] The naming specification checking module is configured to check, based on the field knowledge base, whether the naming of the code entity in the to-be-checked code change conforms to the code entity naming specification, and generate a second checking result;

[0022] The architecture specification checking module is configured to check, based on the architecture knowledge base, whether the code structure of the to-be-checked code change conforms to the code framework specification, and generate a third checking result;

[0023] The review report generating module is configured to generate a code review report based on the first checking result, the second checking result and the third checking result.

[0024] Further, to achieve the above object, the present application further provides a computer device, which comprises a memory, a processor and a knowledge base assisted code review program stored in the memory and executable on the processor, and the knowledge base assisted code review program is used to implement the steps of the knowledge base assisted code review method as described above when executed by the processor.

[0025] Further, to achieve the above object, the present application further provides a computer readable storage medium, which stores a knowledge base assisted code review program, and the knowledge base assisted code review program is used to implement the steps of the knowledge base assisted code review method as described above when executed by a processor.

[0026] Beneficial effects: The application relates to the technical field of infrastructure operation and maintenance, can be applied to business scenarios such as financial technology and medical health, and discloses a code review method, device, equipment and medium based on knowledge base assistance, which comprises the following steps: extracting usage specifications of project preset components from project historical codes, and constructing a component knowledge base; constructing a domain knowledge base based on preset domain-specific terms and code entity naming specifications; constructing an architecture knowledge base based on a preset code framework specification; obtaining code changes to be reviewed; checking whether the calling of the project preset components in the code changes to be reviewed conforms to the usage specifications based on the component knowledge base, and generating a first checking result; checking whether the code entity naming in the code changes to be reviewed conforms to the code entity naming specifications based on the domain knowledge base, and generating a second checking result; checking whether the code structure of the code changes to be reviewed conforms to the code framework specification based on the architecture knowledge base, and generating a third checking result; and generating a code review report based on the first checking result, the second checking result and the third checking result. The component knowledge base, the domain knowledge base and the architecture knowledge base are constructed, multi-dimensional joint checking of code changes from component calling, naming specifications to architecture specifications is realized, the automation level of code review can be improved, manual dependence can be reduced, and code quality and standardization can be enhanced. BRIEF DESCRIPTION OF DRAWINGS

[0027] The application will be further described below in combination with the drawings and embodiments, and the drawings show:

[0028] Figure 1 An application environment diagram of the code review method based on knowledge base assistance in an embodiment of the application;

[0029] Figure 2 A flowchart of the code review method based on knowledge base assistance in an embodiment of the application;

[0030] Figure 3 A function module diagram of the code review device based on knowledge base assistance in a preferred embodiment of the application;

[0031] Figure 4 A structure diagram of a computer device in an embodiment of the application;

[0032] Figure 5 Another structure diagram of a computer device in an embodiment of the application. DETAILED DESCRIPTION

[0033] It should be understood that the specific embodiments described herein are merely intended to explain the application, and are not intended to limit the application.

[0034] The code review method based on knowledge base assistance provided by the embodiments of the application can be applied to business scenarios such as Figure 1In an application environment of the present application, the user end communicates with the service end through a network. The service end can extract the usage specification of the project preset component from the project history code through the user end, construct a component knowledge base, construct a domain knowledge base based on the preset domain-specific term and code entity naming specification, construct an architecture knowledge base based on the preset code framework specification, obtain the code change to be reviewed, check whether the call to the project preset component in the code change to be reviewed conforms to the usage specification based on the component knowledge base, generate a first checking result, check whether the code entity naming in the code change to be reviewed conforms to the code entity naming specification based on the domain knowledge base, generate a second checking result, check whether the code structure of the code change to be reviewed conforms to the code framework specification based on the architecture knowledge base, generate a third checking result, and generate a code review report based on the first checking result, the second checking result and the third checking result. The present application realizes multi-dimensional joint checking of the code change from the component call, the naming specification to the architecture specification by constructing the component knowledge base, the domain knowledge base and the architecture knowledge base, can improve the automation level of the code review, reduce the manual dependence, and enhance the code quality and the standardization. The user end can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices. The service end can be realized by an independent server or a server cluster composed of multiple servers. The present application will be described in detail through specific embodiments.

[0035] Please refer to Figure 2 , Figure 2 The flowchart of an embodiment of the code review method assisted by the knowledge base provided by the present application is shown. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0036] As Figure 2 shown, the code review method assisted by the knowledge base provided by the present application includes the following steps:

[0037] S10, extracting the usage specification of the project preset component from the project history code, and constructing a component knowledge base;

[0038] In this embodiment, the project history code refers to all source code, configuration files, script files and associated resources accumulated in the development, online or long-term maintenance process of the information system or software project, covering all code achievements produced by different developers or different versions in different periods. These code files are usually stored in code repositories, version control systems or local development environments, with complete module division, function implementation and dependency structure. In the process of extracting the usage specification of the project preset component, the specific scope of the project preset component needs to be determined first. The project preset component refers to a set of components that are repeatedly reused, have independent functions or standard interface definitions, and have been included in a unified management directory during the entire system development process. Project preset components can include but are not limited to data encryption modules, input parameter verification modules, unified exception handling modules, access permission control modules, log collection modules, business process interceptors, external service interface encapsulation modules, etc. These components usually exist in the form of classes, interfaces, functions, script fragments, configuration templates, etc. in the project history code, with stable interface parameter structure and clear functional responsibilities.

[0039] In order to efficiently and comprehensively extract the usage specification of the project preset component, first, the code analysis tool is used to scan the project history code file set. This scanning operation is based on static syntax tree construction and path analysis algorithm, which can automatically locate the declaration position, definition content and calling relationship of the project preset component. The declaration position includes class file path, function definition position, module registration position, configuration file reference path, etc. The definition content includes component input parameters, output parameters, return value type, default configuration item, extension parameter, etc. The calling relationship includes direct or indirect reference, calling level, calling context and other information of other modules to the project preset component. For the parameter part of the calling statement, regular expression matching, keyword positioning and structured parsing are combined to accurately extract component configuration parameters, including parameter name, parameter type, parameter value range, default value setting, whether it is required, parameter validation rules, etc.

[0040] Combined with the context environment information where the component is called, the usage specification of the project preset component is further supplemented. The context environment information refers to the module type, function path, business logic node, system deployment environment, version control information, calling trigger condition, dependent external services, data flow path, etc. These information can be obtained through calling stack tracking, module structure analysis, dependency relationship reasoning, log information restoration, interface calling chain extraction, etc. By structuring and integrating the component parameter configuration information and the context environment information, a unified format usage specification entry is generated, including component identification, function description, parameter list, configuration requirement, usage limitation, applicable scenario, upstream and downstream dependency, historical version information, known risk prompt, etc.

[0041] All usage specification items are written into the component knowledge base in a structured storage manner. The component knowledge base is built based on a database management system. The database structure includes a component information table, a parameter configuration table, a usage scenario table, a dependency relationship table, a specification version table, a risk record table, and the like. The data tables support efficient retrieval, quick positioning, batch updating, and dynamic expansion through mechanisms such as foreign key association, joint indexing, full-text retrieval, and classification identification, to ensure the integrity, accuracy, and real-time availability of the component usage specification information. After the component knowledge base is formed, it can provide data support for subsequent code review, quality inspection, system maintenance, and function expansion.

[0042] Different data parsing frameworks can be used to adapt to project historical code extraction operations in different language environments. For example, for Java language projects, a static code analysis tool combined with an AST syntax tree generator is used to automatically identify the class file structure, method definition, annotation mark, and configuration file reference relationship of the project preset components. For Python language projects, component structure information and usage parameter information are obtained through a code abstract syntax parsing module, a function call tracking module, and a module dependency analysis tool. For systems involving mixed development of multiple languages, a cross-language static analysis platform is used to uniformly manage component definition and call specification information in different languages.

[0043] The performance and scalability of the component knowledge base can be optimized by adjusting the data storage structure. For example, a relational database combined with a JSON field storage mode is used to flexibly record the parameter configurations and context environment differences of different components. A document-type database can also be used to directly store the complete usage specification item structure, facilitating support for complex nesting and dynamic expansion scenarios.

[0044] The granularity and range of information extraction can be adjusted according to different scales and security requirements. For small systems, the focus is on extracting parameter information and basic context environment information of commonly used project preset components. For large systems or systems with high security requirements, more complex dependency relationships, external interface call chains, data flow paths, dynamic configuration logic, and historical version compatibility information are further extracted to improve the accuracy and completeness of component usage specifications.

[0045] Example: In the medical health business field, projects such as electronic medical record systems, medical image systems, and data desensitization platforms are involved. Project preset components include data desensitization processing modules, sensitive information encryption modules, and medical data verification modules. The system can automatically scan the historical code of the medical information system to extract parameter configuration requirements and business scenario information of the above-mentioned project preset components, and uniformly build a component knowledge base to ensure the security and compliance of medical data and reduce the risk of information leakage caused by human errors.

[0046] In the financial field, especially in the payment system, risk control system, account system, the project preset component includes identity authentication interceptor, transaction limit verification module, anti-fraud detection module, log tracking module, etc. The system automatically extracts the interface parameters, calling restrictions, and business dependency information of these project preset components by analyzing the historical code of the financial system, forms structured usage specification data, improves the safety review efficiency of the system, and reduces the account security vulnerabilities and financial risks caused by improper component configuration.

[0047] The embodiment automatically extracts parameter configuration information and context environment information of the project preset component by comprehensively scanning the project historical code, constructs a unified component knowledge base, avoids information dispersion, large manual sorting errors, data omission, and other problems, significantly improves the efficiency and accuracy of component usage specification extraction, ensures that the subsequent code checking provides accurate data basis for the automatic verification of component specifications, effectively reduces the functional defects and system risks caused by improper use of components, and improves the overall safety and maintainability of the system.

[0048] S20, based on the preset field-specific terms and code entity naming specification, a field knowledge base is constructed;

[0049] In the embodiment, the field-specific terms refer to a set of terms that are widely used in a specific business context, have clear meanings, and can accurately describe business objects, business processes, or technical modules. These specific terms usually come from industry standards, project experience accumulation, system design documents, historical code comments, data dictionaries, or business requirement specifications. Field-specific terms cover various business concepts, organizational structures, functional modules, data indicators, and operation behaviors involved in the system, and have universality, consistency, and scalability. By organizing the set of field-specific terms, the naming expression within the system can be unified, ambiguity and understanding deviation can be reduced, and code readability and system maintenance efficiency can be improved.

[0050] The code entity naming specification refers to a set of standards for the naming structure, composition rules, word selection, semantic expression, and naming restrictions of various code entities involved in the system development process. Code entities include but are not limited to class names, interface names, method names, variable names, constant names, configuration item names, database field names, and script fragment identifiers. Code entity naming specification is usually developed based on development language characteristics, system architecture design, industry standards, team collaboration requirements, and project business requirements. The content includes prefix and suffix requirements, word splicing methods, case rules, semantic expression range, prohibited word list, length limit, and business meaning mapping relationship, etc., to ensure that all code entities in the system have a unified, clear, easy-to-understand, and easy-to-maintain naming style.

[0051] In the process of constructing the domain knowledge base, first, the domain-specific noun set and the code entity naming specification need to be loaded. The loading operation extracts information from structured data sources, text documents, configuration files, databases, or external interfaces to establish a complete term set and specification entry, ensuring that the information source is authoritative, the content is complete, the structure is clear, and the format is unified. The domain-specific noun set is stored in the form of glossary, keyword list, term grouping, meaning explanation, hierarchical level, semantic association, etc. The code entity naming specification is stored in the form of specification entry, rule explanation, example structure, prohibited usage, standard reference, historical version information, etc.

[0052] In the process of parsing the code entity naming specification, regular expression matching, lexical analysis, semantic reasoning, and structure mapping techniques are used to extract specific naming rule entries, including naming structure templates, keyword restrictions, word order, semantic expression range, special symbol usage restrictions, case rules, root and affix combination methods, industry term application specifications, and exclusive rules for different types of code entities, ensuring that each type of code entity has clear, specific, and operable naming standards.

[0053] An association is established between the domain-specific noun set and the naming rule entry to form a naming mapping relationship. The naming mapping relationship ensures the correct, standardized, and unified use of domain-specific nouns in code entity naming through mechanisms such as bidirectional association, classification mapping, upstream and downstream dependencies, and business semantic linking, avoiding problems such as misuse of vocabulary, ambiguous expression, and business misunderstanding, and improving the maintainability of code and the consistency of the system.

[0054] Finally, the naming mapping relationship is structured and stored in the domain knowledge base. The domain knowledge base is implemented based on a relational database, a document database, a knowledge graph, a metadata management platform, or a configuration management system. The data structure includes a vocabulary information table, a naming specification table, a mapping relationship table, a business meaning table, a historical version table, a usage example table, a violation vocabulary table, and an extension configuration table. Through structured storage, index optimization, semantic retrieval, dynamic updating, version management, and other functions, the integrity, accuracy, real-time performance, and high availability of the domain knowledge base information are ensured. The domain knowledge base can provide standardized, structured, and extensible basic data support for system development, code review, naming check, quality control, and business training scenarios.

[0055] The domain-specific noun set and the code entity naming specification can be imported in batches by customizing a script to parse the configuration file. For example, the domain-specific nouns can be organized into CSV, JSON, or XML format files, and the naming specification can be organized into rule expressions and example explanations. The system automatically reads, verifies, and stores the information through the script to quickly construct the domain knowledge base.

[0056] It can also be combined with the existing data dictionary, business vocabulary library, knowledge management system, through interface call, data synchronization, file import, etc., to obtain the latest domain-specific term set, and ensure the consistency and timeliness of the domain knowledge base content and the actual business.

[0057] In large systems or complex projects, natural language processing techniques and machine learning algorithms can be combined to automatically analyze project history code, design documents, interface documents, log information, and database structures, and intelligently extract potential domain-specific terms and non-standard code entity naming to assist in improving the content of the domain knowledge base and improving system automation management.

[0058] For different sizes and business needs, the storage structure and implementation technology of the domain knowledge base can be flexibly selected. For small and medium-sized systems, a relational database combined with structured storage can meet the needs of efficient query and information management; for large-scale, cross-system, cross-team collaborative projects, graph databases, knowledge graphs, and metadata management platforms can be used to manage complex relationships, semantic reasoning, and dynamic expansion, and improve the overall management efficiency and maintainability of the system.

[0059] Example: In the medical health business field, for electronic medical record systems, health record systems, disease monitoring platforms, and other projects, domain-specific terms include patient information, disease coding, diagnosis and treatment items, examination indicators, medical order information, and drug catalogs. By combining medical industry standards and internal specifications, a unified code entity naming specification is developed, and the system ensures the accuracy and consistency of related code entity naming in various modules, interfaces, and databases, ensuring the readability, maintainability, and data interaction security of the medical information system.

[0060] In the financial field, especially in payment systems, account systems, and risk control systems, domain-specific terms include transaction records, account information, risk levels, identity authentication, fund transfers, and abnormal alarms. By loading standardized business terminology and naming specifications, the system builds a domain knowledge base to ensure naming specifications in code development, interface design, and database structure, improving the overall maintainability and security of the system and reducing the functional defects and information risks caused by naming confusion.

[0061] By loading domain-specific terms and code entity naming specifications, analyzing naming rule entries, establishing naming mapping relationships, and structuring storage in the domain knowledge base, this embodiment can achieve consistency, standardization, and controllability of system internal code entity naming, avoid business ambiguity, functional logic confusion, code maintenance difficulties, and low team collaboration efficiency caused by non-standard naming, and improve system code quality, business logic clarity, and operation and maintenance efficiency, reducing system risks and maintenance costs caused by non-standard naming.

[0062] S30, construct an architecture knowledge base based on the preset code framework specification;

[0063] In the embodiment, the code framework specification refers to a set of standards for the overall system architecture design requirements, combined with specific development languages, technology stacks, design patterns, project management standards, and clear code level division, module dependency relationship, function partition, package structure naming, directory organization form, component interaction mode, etc. The code framework specification usually comes from architecture design documents, project specification manuals, development team agreements, industry best practices or large system evolution experience. The specification has the characteristics of mandatory, consistency and scalability, and the purpose is to ensure that the system structure is clear, hierarchical, reasonable, and the function division is clear, reducing the complexity and maintenance difficulty of the system.

[0064] During the construction of the architecture knowledge base based on the preset code framework specification, the code framework specification needs to be loaded first. The loading process extracts the specification content from structured configuration files, architecture design documents, system configuration platforms or external interfaces to ensure that the information source is authoritative, the content is complete, and the format is unified. The content of the code framework specification includes but is not limited to the hierarchical division scheme of each functional module of the system, the definition of module dependency relationship, component boundary restriction, cross-layer calling rule, directory structure design, interface division standard, technology stack agreement, module responsibility explanation, dependency relationship control strategy, etc.

[0065] During the parsing of the code framework specification, combined with syntax rule analysis, structure mapping, relationship reasoning, and text analysis, the hierarchical division rule and module dependency relationship are extracted. The hierarchical division rule is used to define the hierarchical relationship of each functional module of the system. Common hierarchical division includes presentation layer, business layer, data layer, tool layer, public module layer, etc. The boundary between different levels is clear, the responsibility is clear, and the function is independent, avoiding module mixing and function overlap. The module dependency relationship is used to limit the calling path and dependency direction between modules in the system, ensuring that the module dependency is one-way, the structure is clear, and the coupling degree is low, preventing system structure confusion and function failure caused by module circular dependency and illegal calling.

[0066] Based on the parsed hierarchical division rule and module dependency relationship, the architecture rule entry is generated, which includes the module belonging to the level, the list of accessible modules, the rule of prohibiting cross-layer calling, the dependency direction restriction, the boundary control strategy, the function module mapping relationship, the directory structure mapping scheme, and the exception structure alarm rule, etc. to ensure the controllability, standardization and stability of the overall system structure.

[0067] The architecture rule entry is finally stored in a structured manner in an architecture knowledge base, the architecture knowledge base is implemented based on a relational database, a graph database, a document database, a configuration management system or an architecture management platform, the data structure includes a module information table, a hierarchical structure table, a dependency relationship table, a rule entry table, a boundary limit table, a historical version table, a violation structure alarm table and the like, and through functions such as structured storage, index optimization, relationship tracing, structure retrieval, dynamic updating and version management, the accuracy, integrity, real-time performance and high availability of the information in the architecture knowledge base are ensured, and the architecture knowledge base provides standardized, structured and extensible basic data support for scenarios such as system development, architecture review, structure optimization, quality control and team collaboration.

[0068] The code framework specification can be imported in batches through a configuration analysis tool, for example, the specification content is arranged into a standard format file such as YAML, JSON, XML or Markdown, and the system automatically reads, analyzes, verifies and stores the information through the tool to quickly build the architecture knowledge base.

[0069] The architecture knowledge base content can also be dynamically updated by extracting the structure information and dependency configuration of each functional module of the system through the existing architecture design platform, configuration management system and version management tool of the system, and through interface calling, data synchronization and file parsing to obtain the latest and complete code framework specification.

[0070] For large systems or complex projects, static code analysis, structure diagram generation and dependency relationship detection can be combined to automatically analyze the system directory structure, module boundary and calling path to assist in perfecting the architecture knowledge base and improving the system structure management and automation control capability.

[0071] For systems with different sizes and technical architectures, the storage structure and implementation mode of the architecture knowledge base can be flexibly selected. For small and medium-sized systems with clear structure and distinct hierarchical structure, a relational database and a structured table design are adopted to meet the efficient query and information management requirements. For large systems with complex hierarchical structure, numerous modules and complex dependency relationships, a graph database, an architecture management platform and a structure visualization tool are adopted to enhance the system structure relationship management, dependency tracing, structure optimization and dynamic expansion capability, and improve the maintainability and stability of the overall system.

[0072] Example: In the medical health business field, for electronic medical record systems, health record platforms and intelligent diagnosis and treatment systems, the code framework specification usually includes strict hierarchical division and module dependency control to ensure that functional modules such as data collection, diagnosis and treatment logic, data storage and information display are strictly isolated. The system builds an architecture knowledge base to realize controllable structure, clear dependency and clear module boundary, and ensures the stability, data security and business compliance of the medical information system.

[0073] In the financial field, especially in account management system, payment clearing system, risk control system, code framework specification involves complex module dependency control and multi-level structure design. The system loads standardized architecture design specification and dependency control strategy, builds architecture knowledge base, ensures reasonable system structure, efficient module cooperation and clear dependency relationship, reduces function risk and system vulnerability caused by structural chaos, and improves the stability, scalability and business continuity of the system as a whole.

[0074] By loading the code framework specification, parsing the hierarchical division rules and module dependency relationship, generating architecture rule entries, and structuring storage to the architecture knowledge base, the system can achieve the standardization of the overall structure, clear hierarchy, clear module boundary and controllable dependency relationship, reduce system maintenance difficulties, function defects and security risks caused by structural chaos, cross-layer calls, illegal dependencies, and improve the stability, scalability and development collaboration efficiency of the system architecture, and ensure the long-term health and stable evolution of the system structure.

[0075] S40, obtaining a code change to be reviewed;

[0076] In this embodiment, the code change to be reviewed refers to the specific code segment, structure, file or module content added, modified or deleted by the developer in the code library compared to the historical version, which usually exists in the form of submission records, change files, difference content, etc. During the process of obtaining the code change to be reviewed, the change information submitted by the developer needs to be identified first. The change information can be obtained through submission requests, change identifiers, branch merging operations, change record logs, etc. in the code version management tool, to ensure the uniqueness, accuracy and integrity of the change data source.

[0077] The change identifier is a unique number to distinguish different code change contents, which is usually derived from the submission ID, change serial number, branch name or label information in the version control system. The system locates the specific change record through the change identifier to ensure targeted extraction of change data. Based on the change identifier, the change file set is extracted from the code version library, which includes all source files, configuration files, script files, document files, etc. involved in this code change. The file set form includes file path, file name, file version, change type (add, modify, delete) and other information, to ensure clear change range and complete file information.

[0078] When parsing the change file set, in combination with file structure analysis, difference comparison, syntax analysis and other technologies, the specific change content is located, and the code change fragment is generated. The code change fragment includes newly added functions, classes, variables, methods, modules, configuration content, modified logic structure, parameters, return value, call relationship, deleted redundant code, repeated definition, invalid logic, etc. The change fragment information covers code location, change type, context structure, dependency relationship, call path and other content, ensuring the integrity of the change content, context association and structural clarity.

[0079] Finally, the code change fragment is stored to form the code to be reviewed, and the storage process is realized based on structured data table, change tracking system, review platform, difference analysis tool and other technologies. The data structure includes change fragment ID, belonging file, change type, code location, structure information, context dependency, call relationship, change content, etc., ensuring the structural clarity, efficient retrieval, convenient tracking and comprehensive review of change data, forming a standardized, structured and extensible data basis for review.

[0080] The change identifier and change file set can be obtained by integrating the code version management system (such as Git, SVN, Mercurial, etc.). The system listens to change events and automatically captures commit requests, change IDs, branch information and merge operations to extract the corresponding change content in real time, ensuring data synchronization and real-time performance.

[0081] The difference comparison tool (such as diff, patch, difference analysis engine) can also be used to compare the contents of different version files to generate code change fragments. In combination with syntax analysis, structure analysis and dependency tracking technology, complete change content, structure information and context data are extracted to improve the accuracy and structural integrity of change data.

[0082] For large projects or multi-module systems, in combination with multi-branch management, version labels and change record systems, module-based, function-based and hierarchical change extraction and data management can be realized to support large-scale project change data acquisition and structured review requirements, improving the applicability and management ability of the system in complex development environments.

[0083] For different development environments and system sizes, the storage form and structure of change data can be flexibly adjusted. For small and medium-sized projects, lightweight databases, JSON files and change log management are used to meet basic data tracking and review requirements. For large systems, in combination with structured databases, relationship mapping management and version tracking platform, the structural integrity, review efficiency and expansion ability of data are enhanced.

[0084] Example: In the medical health business field, for intelligent diagnosis and treatment systems, electronic medical record platforms, and health information systems, obtain the code changes to be reviewed to ensure that the newly added or modified diagnosis and treatment logic, data structure, and interaction process change content is clear, and to assist the doctor support system and health management platform to achieve system structure stability, accurate data, and business compliance.

[0085] In the financial field, for payment systems, account systems, and risk control systems, obtain the code changes to be reviewed to ensure that the newly added payment logic, account operation, and risk control strategy change content is structured, comprehensive, and dependent, and to ensure the system stability, security, and functional compliance of the financial system during business upgrade, strategy adjustment, and function optimization.

[0086] This embodiment can accurately capture the code changes in the development process by identifying change information, extracting change file sets, parsing change segments, and structuring change data to form code changes to be reviewed. It ensures that the change range is clear, the structure information is complete, and the context association is clear, reduces the review deviation caused by information loss, structure chaos, and change omission, improves the comprehensiveness, accuracy, and review efficiency of code review, and ensures the controllability, standardization, and quality stability of the system change process.

[0087] S50, based on the component knowledge base, checking whether the call to the project preset component in the code change to be reviewed conforms to the usage specification, and generating a first inspection result;

[0088] In this embodiment, the component knowledge base is a structured information set formed based on existing functional components, tool modules, and security plugins in historical projects. It mainly includes the function description, usage specification, configuration parameter, calling method, applicable scenario, and dependency restriction of the component, and has completeness, queryability, and extensibility. The code change to be reviewed refers to the specific code changes such as addition, modification, and deletion made by the developer to the system function, structure, and performance during the development of the new version, which usually exists in the form of difference file, change segment, and submission record.

[0089] Checking whether the call to the project preset component in the code change to be reviewed conforms to the usage specification first requires parsing the code change to be reviewed and locating the call point involving the project preset component. The call point refers to the specific location in the code where the component call, interface reference, and function integration are actually initiated, including function call, module import, dependency configuration, and parameter passing. Through static code analysis, structure parsing, and dependency tracking, all call locations involving the project preset component are identified to ensure the comprehensiveness and accuracy of the call information.

[0090] Based on the component knowledge base, the usage specification of the corresponding project preset component is retrieved. The usage specification includes the functional description, calling method, parameter requirement, configuration limit, applicable environment, dependency requirement, version adaptation, etc. of the component. The retrieval process combines the component identifier, naming rule, function tag, etc. to ensure accurate matching of the corresponding preset component and the specification content.

[0091] For each call point, the call is verified for compliance with the usage specification in combination with the calling syntax structure, parameter configuration, and context environment. The verification content includes whether the parameter quantity and type are matched, whether the mandatory parameters are configured, whether the default parameters are overridden, whether the dependencies are complete, whether the calling position is reasonable, whether the function scenario is adapted, etc. to ensure that the calling process meets the established safety, functionality, and maintainability requirements.

[0092] For call points that do not comply with the usage specification, the call point position and parameter difference information are recorded. The call point position includes file path, code line number, structure level, module information, and parameter difference includes missing parameters, type mismatch, configuration error, function abuse, scenario mismatch, etc. to ensure accurate problem positioning, clear reason description, and complete risk information.

[0093] Finally, based on all the call point positions and parameter differences that do not comply with the specification, a first inspection result is generated. The first inspection result is a structured review output containing problem position, difference content, impact range, risk level, suggested measures, etc. It has completeness, systematicness, and practicality, making it easy for developers to understand the nature of the problem, locate the repair position, and adjust the calling method, thereby improving the system's standardization, stability, and security.

[0094] The automatic code analysis and call point positioning can be achieved by integrating static code analysis tools, syntax parsing engines, and structure scanning modules, thereby improving the automation and accuracy of the inspection process.

[0095] The usage specification of the corresponding project preset component can also be quickly obtained based on efficient retrieval algorithms, indexing mechanisms, and keyword matching in combination with a structured component knowledge base, thereby improving the efficiency and accuracy of specification retrieval.

[0096] In the verification process, context semantic analysis, parameter type inference, and dependency link checking can be introduced to enhance the adaptation capability for complex call relationships, multi-layer dependency structures, and dynamic parameter configurations, thereby improving the completeness and applicability of the inspection process.

[0097] In generating the first inspection result, clear, comprehensive, and systematic problem information can be output through structured data storage, review result reporting, and problem classification management, thereby supporting multi-dimensional display, quick positioning, and efficient rectification, and adapting to different development processes, system sizes, and project requirements.

[0098] Example: In the field of medical health services, intelligent diagnosis and treatment systems, electronic prescription platforms, and health information systems widely integrate drug information modules, data exchange interfaces, and security verification components. By checking the changes in the code under review for the invocation of these pre-set components, issues such as missing parameter configurations, improper interface calls, and missing security functions can be identified in a timely manner, ensuring accurate system data, information security, and business specifications, and reducing the operational risks and data leakage risks of medical systems.

[0099] In the financial field, payment systems, account systems, and transaction platforms integrate transaction encryption modules, risk control verification tools, and data encryption components. By checking the component invocation in the code under review, issues such as missing security verification, incompatible encryption parameter configurations, and non-standard interface calls can be identified in a timely manner, ensuring payment business security, account information confidentiality, and transaction process compliance, enhancing the security, stability, and compliance of financial systems, and meeting the needs of high-intensity supervision and complex business environments.

[0100] This embodiment can accurately identify non-standard component invocation issues in the code change process by analyzing the code under review, locating the invocation points of pre-set components, searching for component usage specifications, verifying compliance, recording non-compliant information, and generating a first inspection result. This can avoid system instability, security risks, and functional abnormalities caused by parameter configuration errors, improper invocation methods, missing dependencies, and functional misuse, improve system reliability, security, and standardization, reduce operational costs and development risks, and ensure the stability and high-quality delivery of system upgrades and functional expansions.

[0101] S60, based on the domain knowledge base, checks whether the code entity naming in the code under review complies with the code entity naming specification, and generates a second inspection result;

[0102] In this embodiment, the domain knowledge base is a structured information collection based on domain-specific terminology and code entity naming specifications for specific projects, industries, or business backgrounds, covering domain terminology, naming rules, word combinations, semantic associations, entity classification, and other content, with standardization, systematization, and scalability. Code entity naming refers to the standardized, structured, and semantically clear naming method for various code entities in the system, including class names, method names, variable names, constant names, interface names, module names, and package paths, ensuring clear system structure, accurate function expression, and code maintainability.

[0103] To check whether the code entity naming in the code change under review conforms to the code entity naming specification, first, all code entity identifiers in the code change under review need to be extracted. Code entity identifiers refer to various types of identification information actually declared, defined, and referenced in the code, including but not limited to variable names, method names, class names, package paths, module names, etc. The extraction process can combine static syntax analysis, structure parsing, symbol table construction, etc. to ensure the completeness and accuracy of the information obtained.

[0104] Based on the domain knowledge base, the code entity naming specification is queried, including vocabulary combination rules, semantic limitations, spelling formats, case requirements, naming structure levels, business semantic mappings, etc. to ensure the comprehensiveness and standardization of the search information.

[0105] Parse the vocabulary composition of each code entity identifier, identify the vocabulary fragments, semantic units, and structure levels that make up the identifier, and combine domain-specific terms and business terminology to determine whether the vocabulary combination is clear, structured, and semantically accurate, avoiding ambiguous, ambiguous, redundant, or non-compliant expressions in the domain.

[0106] Compare the vocabulary composition with the code entity naming specification to verify the compliance of the naming method. The content includes whether the vocabulary selection is standard, whether the semantic expression is accurate, whether the structure level is clear, whether the format and spelling are correct, and whether it matches the domain terminology, etc. to ensure that the code entity naming has high readability, maintainability, and business expression consistency.

[0107] Record the code entity identifiers that do not conform to the naming specification and the deviation types. The code entity identifiers include their specific location, name, and structure information, and the deviation types include term errors, semantic confusion, unclear structure, spelling errors, naming ambiguity, etc. to ensure that the problem information is clearly expressed, accurately positioned, and specifically caused.

[0108] Based on the code entity identifiers that do not conform to the naming specification and the deviation types, generate the second inspection result. The second inspection result is structured, systematic, and traceable inspection information, containing problem location, deviation type, risk impact, optimization suggestions, etc. to facilitate developers to quickly understand, locate, and rectify, and improve the overall code specification level and maintainability of the system.

[0109] Based on static code analysis tools, syntax parsing engines, and structure scanning modules, all code entity identifiers in the code change under review can be automatically extracted to ensure the comprehensiveness and accuracy of information extraction.

[0110] In addition, by combining the domain knowledge base and using keyword matching, regular expressions, semantic analysis, and business dictionary mapping, the corresponding code entity naming specification can be quickly retrieved to improve the efficiency and applicability of specification acquisition.

[0111] In the vocabulary parsing process, based on semantic segmentation, named hierarchy, structure recognition technology, the vocabulary composition and semantic structure of the identifier can be accurately restored, and the adaptation ability to complex naming, cross-layer structure, and domain term fusion can be enhanced.

[0112] In the comparison verification process, fuzzy matching, semantic reasoning, context analysis and other methods can be introduced to improve the identification ability of non-standard naming, potential ambiguity and structural confusion, and enhance the comprehensiveness and accuracy of the checking process.

[0113] The second checking result can be in the form of structured data format, visual report, problem grading management, etc., to output clear, systematic and operable problem information, support fast positioning, intelligent recommendation and batch rectification, and adapt to different development scenarios, project sizes and business needs.

[0114] Example: In the medical health business field, there are a large number of code entities related to medical terms, disease names, diagnosis and treatment standards, and data information in electronic medical record systems, diagnosis and treatment auxiliary platforms, and health data platforms. Checking the naming of code entities in the code change under review can timely identify problems such as ambiguous variable naming, ambiguous method names, and inconsistent class names and functions, ensuring accurate expression of medical information, clear system structure, and consistent business meaning, reducing understanding bias and maintenance costs of the medical system, and improving the stability and business reliability of the system.

[0115] In the financial field, there are a large number of code entities related to financial terms, business processes, account structures, and transaction parameters in payment systems, account systems, and transaction systems. Checking the naming of code entities in the code change under review can timely identify problems such as non-standard naming, improper use of terminology, and chaotic structure expression, ensuring accurate expression of account information, clear transaction process, and reasonable system structure, enhancing the maintainability, business expression clarity, and safety and stability of the financial system, and meeting the needs of high compliance, strong security, and complex business scenarios.

[0116] This embodiment can comprehensively, accurately and systematically identify non-standard naming problems in the code change process by extracting all code entity identifiers in the code change under review, querying the naming specification based on the domain knowledge base, parsing the vocabulary composition, comparing the specification compliance, recording the deviation information, and generating the second checking result. This can avoid system function disorder, maintenance difficulty and business understanding bias caused by terminology errors, semantic confusion, unclear structure and ambiguous naming, improve the overall code specification, structure clarity and semantic accuracy of the system, enhance the maintainability, business expression ability and development efficiency of the system, and reduce technical debt and management costs.

[0117] S70, based on the architecture knowledge base, checking whether the code structure of the to-be-inspected code change conforms to the code framework specification, and generating a third inspection result;

[0118] In the embodiment, the architecture knowledge base is a structured information set formed by organizing, extracting and summarizing system architecture structure and design specifications, covering code framework specifications, hierarchical division standards, module dependency relationships, structural design principles and the like, and having completeness, systematicness and business adaptation capability. The code structure refers to a physical structure and logical organization form of source code formed in a specific system, including file hierarchy, module division, dependency path, function boundary, interaction relationship and the like. The code framework specification is a structural organization standard formulated according to design concepts and system requirements, which clearly defines the hierarchical principle of code, module dependency restriction, path organization structure and function boundary division, and ensures the clarity, stability and scalability of the overall architecture of the system.

[0119] To check whether the code structure of the to-be-inspected code change conforms to the code framework specification, it is necessary to first analyze the content of the to-be-inspected code change, extract information related to the structure, and combine syntax analysis, directory scanning, dependency analysis and structure mapping to generate a code structure model. The code structure model fully reflects the physical hierarchy, logical structure and module dependency relationship of the to-be-inspected code change, ensuring the completeness and accuracy of the structure information.

[0120] The code framework specification is obtained from the architecture knowledge base. The specification information includes system hierarchical structure, module boundary division, dependency path design, function module relationship, directory organization structure, naming rules and dependency constraints, etc., ensuring that the specification information is consistent with the actual project structure and business requirements, and having completeness, accuracy and applicability.

[0121] Based on the code structure model and the code framework specification, the structure elements of the two are matched, including modules, classes, interfaces, files, directories, package paths, function units and the like. Through structure mapping, dependency analysis and hierarchical comparison, the element correspondence is generated, the positions, levels and dependency paths of each structure element in the to-be-inspected code change in the overall architecture of the system are clearly defined, and the structure information expression is accurate and the matching relationship is clear.

[0122] Based on the element correspondence, it is verified whether the hierarchical division in the code structure model conforms to the hierarchical specification in the code framework specification, it is checked whether the hierarchical structure is clear, the hierarchical boundary is clear, and the modules are in the correct hierarchical level, avoiding problems such as hierarchical confusion, structure flattening and module boundary crossing, and improving the structural clarity and maintainability of the overall system.

[0123] Based on the element correspondence relationship, it is verified whether the module dependency in the code structure model conforms to the dependency specification in the code framework specification, and it is checked whether the calling relationship, dependency path, and data interaction between modules conform to the system design requirements, so as to avoid unreasonable dependency, circular calling, cross-layer access, and other problems between modules, and to ensure the stability of the system architecture, the independence of the modules, and the clarity of the functional boundaries.

[0124] The hierarchical division position and hierarchical deviation type that do not conform to the hierarchical specification in the code framework specification are recorded. The position information includes the specific position of the structural element in the code, the file path, and the module level. The deviation type includes hierarchical confusion, module boundary crossing, structural redundancy, and unclear layering, etc. It ensures that the problem information is clearly expressed, accurately positioned, and specifically caused.

[0125] The module dependency position and dependency deviation type that do not conform to the dependency specification in the code framework specification are recorded. The position information includes the dependency path, module relationship, and interaction position. The deviation type includes dependency path error, cross-layer calling, high module coupling, and illegal dependency, etc. It ensures that the dependency problem is expressed specifically, positioned clearly, and the impact is clear.

[0126] Based on the hierarchical division position, hierarchical deviation type, module dependency position, and dependency deviation type, a third check result is generated. The third check result is structured, systematic, and traceable check information, including problem position, deviation type, risk impact, and optimization suggestion, supporting problem positioning, rectification suggestion, and structure optimization, and improving the overall architecture specification, stability, and maintainability of the system.

[0127] Static structure scanning, directory parsing, and module dependency graph construction technologies can be combined to automatically generate a code structure model, ensuring that the structure information is comprehensive and accurate.

[0128] Based on the architecture knowledge base, standardized templates, structure specification documents, and dependency rule databases can be used to efficiently obtain the code framework specification, ensuring the completeness and applicability of the specification information.

[0129] In the structure element matching process, semantic analysis, path mapping, and hierarchical restoration techniques can be combined to accurately generate element correspondence relationships, adapting to complex structures, cross-layer designs, and multi-module dependency scenarios.

[0130] In hierarchical division verification, structure rule engines, hierarchical constraint verification, and hierarchical strategy matching methods can be combined to comprehensively check the specification and accuracy of hierarchical division, improving the clarity of the system structure.

[0131] In the module dependency verification process, dependency graph analysis, calling relationship tracing, and path legality verification methods can be combined to accurately identify unreasonable dependencies and illegal cross-layer calls, ensuring the independence of the system modules and the stability of the architecture.

[0132] The third inspection result can be output in the form of structured data, graphical display, visual report, etc., facilitating problem positioning, structure optimization and system rectification, and adapting to different system scales, structure complexities and business scenario requirements.

[0133] Example: In the medical health business field, in the hospital management system, electronic medical record system and diagnosis and treatment auxiliary platform, the system structure is complex, the modules are numerous, and the function interaction is frequent. The inspection of the code structure can ensure the clarity of the medical system structure, the independence of the modules and the rationality of the dependencies, improve the stability, scalability and business adaptation ability of the system, and reduce the difficulty and risk of system maintenance.

[0134] In the financial field, in the payment system, account system and risk control system, the system structure needs to have high reliability, strong security and clear hierarchical structure. The inspection of the code structure can ensure the clarity of the system hierarchy, the independence of the modules and the rationality of the dependencies, improve the stability, maintainability and business security of the financial system, and meet the complex business requirements and high compliance requirements.

[0135] The embodiment can systematically, accurately and comprehensively find the structure non-standard problems in the code change process, avoid hierarchy confusion, module boundary crossing and illegal dependencies, improve the standardization, clarity and maintainability of the overall structure of the system, enhance the stability, scalability and business adaptation ability of the system architecture, and reduce the system maintenance cost and technical risk.

[0136] S80, generating a code review report based on the first inspection result, the second inspection result and the third inspection result.

[0137] In this embodiment, the first check result is based on the component knowledge base, analyzes whether the project preset component call involved in the code change under review conforms to the usage specification, and generates structured result information, which usually includes the call point position that does not conform to the usage specification, parameter difference, risk type, and suggested optimization measures. The second check result is based on the domain knowledge base, analyzes whether the code entity naming in the code change under review conforms to the code entity naming specification, and forms structured check information, which usually includes the code entity identifier that does not conform to the naming specification, vocabulary composition difference, naming deviation type, and corresponding optimization suggestions. The third check result is based on the architecture knowledge base, analyzes whether the code structure of the code change under review conforms to the code framework specification, and outputs structured structure check information, which usually includes the hierarchical division position, hierarchical deviation type, module dependency position, dependency deviation type, and structure optimization suggestions.

[0138] Generating a code review report requires comprehensive use of the first check result, the second check result, and the third check result to comprehensively and systematically reflect the structural problems, naming problems, and component call problems in the code change under review, ensuring that the report content is complete, logical, and accurate in problem positioning.

[0139] In the specific generation process, the first check result, the second check result, and the third check result are first integrated, and through data merging, structure mapping, problem classification, and content supplementation, comprehensive review results are formed. The comprehensive review results have the characteristics of structure, traceability, clear classification, and comprehensive content.

[0140] According to the comprehensive review results, the problems are classified in detail according to the problem categories. Usually, the problem items are divided into component specification problems, naming specification problems, and architecture specification problems. The component specification problems involve project preset component call irregularities, parameter configuration errors, and function omissions. The naming specification problems involve code entity identifier naming ambiguity, non-standard vocabulary, and deviation from domain-specific terminology standards. The architecture specification problems involve hierarchical division confusion, unreasonable module dependency, illegal cross-layer calls, and structural design deviations.

[0141] The problem items are associated with repair suggestions, which come from the component knowledge base, the domain knowledge base, the architecture knowledge base, and the preset experience rule base. The content includes parameter configuration optimization, naming adjustment suggestions, structure reconstruction schemes, and dependency optimization paths, ensuring that each problem item is associated with clear, specific, and operable rectification measures.

[0142] Finally, the generated code review report is output in document form, with structured content, clear hierarchy, and comprehensive information. It usually includes problem classification summary, specific problem list, location positioning information, deviation type, risk analysis, and corresponding repair suggestions, supporting text and image combination, structure display, problem traceability, and optimization guidance. This facilitates the efficient grasp of existing problems in code changes by development teams, architecture teams, and management personnel, and promotes the continuous optimization of system standardization, stability, and maintainability.

[0143] The code review report document can be automatically generated by combining structured data storage, document template generation, and graphical visualization techniques, ensuring that the report content is standardized, the structure is clear, and the information is comprehensive.

[0144] Based on the association mechanism of problem items and repair suggestions, the content of repair suggestions can be dynamically adjusted by updating the knowledge base and supplementing the rule base, adapting to different project requirements, system architecture, and development environments, and improving the applicability and pertinence of the report.

[0145] During the report generation process, natural language processing techniques can be used to optimize document expression forms, improve report readability and information transmission efficiency, and adapt to the usage needs of different teams and technical backgrounds.

[0146] For large systems, complex structures, and multi-module dependent scenarios, the report content can be organized in a modular, hierarchical, and problem category manner to ensure clear information expression, accurate problem positioning, and clear optimization path.

[0147] Example: In the medical health business field, medical systems usually contain complex functional modules and strict structural specifications. By generating a code review report, component invocation problems, naming irregularities, and structural design deviations in the system can be clearly reflected, facilitating the rapid positioning of problems by medical information system development teams, optimizing system structure, and ensuring the system has good stability, scalability, and business adaptation ability, meeting the technical requirements of high reliability, high security, and high maintainability of medical systems.

[0148] In the financial field, payment systems, risk control systems, and account management systems have high requirements for system structure stability, functional boundary clarity, and security standardization. The generated code review report can accurately reflect structural problems, naming deviations, and component invocation irregularities in the system, providing specific and actionable rectification paths to help development teams optimize system architecture, improve system standardization, reduce security risks, and improve system stability, scalability, and business compliance ability, meeting the complex business requirements and high reliability requirements of financial systems.

[0149] The embodiment generates a code review report which is structured, systematic, clear in problem classification and comprehensive in information by comprehensively combining the first check result, the second check result and the third check result, can comprehensively reflect the component calling normativity, naming normativity and structure design rationality in the code to be reviewed, timely find and locate various normativity problems, provide targeted and operable rectification suggestions, improve code quality, structure normativity and system maintainability, reduce technical risks, and guarantee long-term stable operation and business demand adaptation capability of the system.

[0150] The application relates to the technical field of infrastructure operation and maintenance, and can be applied to business scenes such as financial technology and medical health, and discloses a code review method and device based on knowledge base assistance, equipment and a medium, which comprises the following steps: extracting usage specifications of preset components from project historical codes to construct a component knowledge base; constructing a domain knowledge base based on preset domain-specific terms and code entity naming specifications; constructing an architecture knowledge base based on preset code framework specifications; obtaining code changes to be reviewed; checking whether the calling of the preset components in the code changes to be reviewed conforms to the usage specifications based on the component knowledge base to generate a first check result; checking whether code entity naming in the code changes to be reviewed conforms to the code entity naming specifications based on the domain knowledge base to generate a second check result; checking whether the code structure of the code changes to be reviewed conforms to the code framework specifications based on the architecture knowledge base to generate a third check result; and generating a code review report based on the first check result, the second check result and the third check result. The application realizes multi-dimensional joint checking of code changes from component calling, naming specifications to architecture specifications by constructing the component knowledge base, the domain knowledge base and the architecture knowledge base, can improve the automation level of code review, reduce manual dependence, and enhance code quality and normativity.

[0151] In one embodiment, the above step S10 comprises:

[0152] S101, scanning a project historical code file set to identify a declaration position of a preset component;

[0153] S102, parsing a calling statement of the preset component, and extracting component configuration parameters from the calling statement;

[0154] S103, determining a context usage scenario of the preset component;

[0155] S104, generating a usage specification entry of the preset component based on the component configuration parameters and the context usage scenario;

[0156] S105, storing the usage specification entry into a database table structure to generate a component knowledge base.

[0157] In this embodiment, the scanning project history code file set refers to loading, parsing and analyzing all historical code files accumulated by the project in different periods and different modules through pre-defined file path range, file type filtering rules and code version snapshots in the version control system. The file set can include source code files, configuration files, script files, etc. Common file types can include Java files, Python files, XML configuration files, YAML configuration files, etc. Through a unified scanning strategy, the historical code range of the project as a whole is ensured to be covered.

[0158] The declaration position of the preset component is identified, specifically referring to locating and extracting the component declaration code segment defined in the project in the scanned historical code file set based on component naming specifications, keyword rules, annotation identifiers or specific structure patterns. Component declaration usually includes class declaration, interface declaration, module definition, function registration, dependency injection configuration, etc. The declaration position can explicitly define the definition range, action boundary and basic structure information of the component in the system, which facilitates the subsequent association of call relationship and functional characteristics.

[0159] The calling statement of the preset component is parsed, and the component configuration parameters are extracted from the calling statement. Usually, through means such as static code analysis, syntax tree parsing and call path tracing, statements involving component instantiation, method calling and function configuration are parsed one by one to obtain information such as call point position, calling method, input parameter and configuration content. Component configuration parameters include but are not limited to function switch, permission control parameter, interceptor configuration, security check rule and concurrency control parameter. The extraction process needs to be combined with code context, parameter meaning and business logic to ensure the accuracy and integrity of the configuration parameter information.

[0160] The context usage scenario of the preset component is determined, which refers to analyzing the actual usage method and applicable range of the component in different business scenarios, functional modules or system levels in combination with the module structure, functional boundary, business process and system level of the calling statement. Usage scenario information includes module name, belonging level, call link, dependency relationship, functional role, etc., which can fully depict the business background and functional positioning of the component.

[0161] Based on the component configuration parameters and the context usage scenario, the usage specification items of the preset component are generated. Usually, structured rule templates, configuration rule sets and functional adaptation strategies are used to integrate and standardize the expression of the extracted configuration parameter information and usage scenario information to form specification items. Specification item content includes component name, call position, parameter configuration requirement, function use restriction, dependency relationship constraint and security specification, etc., which can be used as an important basis for determining the specification of the component call in the subsequent review process.

[0162] The use specification item is stored into a database table structure, a component knowledge base is generated, and the generated use specification item is stored into a preset database table structure according to component classification, function type, parameter configuration, use scene and other dimensions by using a structured storage mechanism. The database table structure can adopt a relational database, a document type database or a knowledge graph form, so that the component knowledge base has efficient query capability, flexible structure expansion and stable data maintenance capability, and is convenient for subsequent rapid retrieval and calling of specification checking.

[0163] The embodiment comprehensively identifies the declaration position of the preset component by systematically scanning the project history code file set, accurately restores the function configuration mode and calling context information of the component by combining the calling statement analysis and configuration parameter extraction, generates a standardized and structured use specification item, further stores the use specification item into a database table structure, forms a queryable, extensible and maintainable component knowledge base, and can provide accurate, complete and reliable component specification basis for subsequent code review, improve the code calling specification, system security and structure stability, reduce the risk of function defects and security vulnerabilities, and enhance the specification management capability and maintenance efficiency of the system.

[0164] In one embodiment, the above step S20 includes:

[0165] S201, loading a preset domain-specific term set and a preset code entity naming specification;

[0166] S202, analyzing the code entity naming specification to generate a naming specification item;

[0167] S203, associating the domain-specific term set with the naming specification item to generate a naming mapping relationship;

[0168] S204, storing the naming mapping relationship into a database structure to generate a domain knowledge base.

[0169] In the embodiment, loading a preset domain-specific term set and a preset code entity naming specification means that the data source to be loaded is parsed and imported based on a domain terminology library related to business and a code naming standard that are arranged in advance. The domain-specific term set is usually derived from business vocabulary, system terminology, function module name, data field terminology and the like of a specific industry, has clear business meaning and standard expression mode, and common data carriers can include configuration files, glossary tables, database tables, dictionary files or centralized terminology management systems. The code entity naming specification mainly includes naming standards and conventions for class, interface, method, variable, constant and package path and the like code structure elements, and the content covers capitalization rules, prefix and suffix use specifications, semantic combination requirements, length limits, abbreviation rules and the like. By uniformly loading the above two types of information, the naming specification has completeness and adaptability.

[0170] The code entity naming specification is parsed to generate a naming specification entry, which specifically includes parsing and splitting the loaded naming specification content based on techniques such as structured templates, regular expression matching, rule decomposition, or semantic analysis, to extract specific naming rule elements and application scenario information. The naming specification entry usually includes naming object types (such as classes, methods, variables), corresponding semantic requirements, lexical structures, format rules, naming examples, and applicable scope. The entry is expressed in a structured data form, facilitating subsequent association and retrieval, and ensuring that different types of code entities have clear, consistent, and checkable naming standards.

[0171] Associating the domain-specific term set with the naming specification entry to generate a naming mapping relationship means that the domain-specific term is taken as a basic vocabulary library, combined with the semantic requirements and lexical structure in the naming specification entry, to establish a mapping relationship between the domain terminology and the code naming. The mapping relationship can be stored in the form of key-value pair, association table, mapping rule set, or knowledge graph, and the content includes domain terminology, acceptable naming variants, naming position requirements, combination constraints, and example expressions. The mapping process needs to consider the consistency of word meaning, context applicability, and naming diversity, to ensure that the naming rules can accurately reflect the business meaning and avoid semantic deviation and naming ambiguity.

[0172] Storing the naming mapping relationship into a database structure to generate a domain knowledge base means that the established naming mapping relationship is stored in a relational database, document database, or other data management system according to a standardized and structured data organization method. The database structure design includes naming mapping table, lexical relationship table, rule index table, etc., with flexible query ability, good scalability, and efficient data maintenance characteristics. The domain knowledge base, as a centralized naming rule management carrier, supports multi-dimensional retrieval, dynamic updating, and cross-module sharing, ensuring that the code entity naming is consistent, standardized, and business-accurate in actual development and review processes.

[0173] This embodiment loads the domain-specific term set and the code entity naming specification, systematically analyzes and generates standardized naming specification entries, establishes clear naming mapping relationships combined with domain terminology, and further stores them into a database structure to form a complete, queryable, and extensible domain knowledge base. This can effectively standardize the code entity naming method in the project, improve the readability, maintainability, and business expression accuracy of the code, reduce code confusion, logical deviation, and maintenance difficulty caused by non-standard naming, and enhance the consistency, reliability, and development efficiency of the system.

[0174] In one embodiment, the above step S30 includes:

[0175] S301, loading a preset code framework specification;

[0176] S302, parse the code framework specification to generate a hierarchical division strategy;

[0177] S303, determine module dependency relationships and generate architecture rule entries based on the hierarchical division strategy and module dependency relationships;

[0178] S304, store the architecture rule entries to a database structure to generate an architecture knowledge base.

[0179] In this embodiment, loading a preset code framework specification means importing a standard file, structure specification, design document or configuration data previously arranged and defined for the overall system architecture design requirements into a data processing module for subsequent parsing and structuring. The code framework specification is usually derived from design constraints and structure specifications formulated by a project team, a technical management team or a standardization organization for dimensions such as layered architecture, functional module division, directory structure, dependency path, interface design, distributed deployment, etc. Common data carriers can include document formats, configuration files, database configuration items or structure specification documents in version management systems. The loading process needs to ensure data integrity, version consistency and clear structure to ensure that the specification information fully reflects the architecture design intent of the system.

[0180] Parsing the code framework specification to generate a hierarchical division strategy specifically includes gradually disassembling the loaded code framework specification content through structured data processing, rule matching, text analysis or template parsing, etc., to extract the hierarchical structure requirements of the system functional modules, the file directory organization form, the code layering rules and the boundary restrictions between them. The hierarchical division strategy usually involves technical specifications of different levels such as presentation control layer, business layer, data layer, public component layer, directory path naming rules, cross-layer call constraints, inter-level interface specifications and function responsibility allocation. The generated hierarchical division strategy has the characteristics of clear structure, clear boundaries and specific application scope, facilitating subsequent dependency relationship analysis and rule management.

[0181] Determining module dependency relationships means, based on the structure constraints and function positioning information of the hierarchical division strategy, combining the actual module design, component distribution and system deployment scheme of the project, and combing the reference relationships, call paths, data transmission directions and coupling constraints between various functional modules, service components, basic libraries and third-party dependencies to form complete module dependency relationship information. The module dependency relationship content covers various forms such as direct call between modules, interface dependency, data sharing, configuration transmission, event subscription, etc. The dependency relationship needs to clearly specify the dependency source, dependency target, dependency type and call constraint to ensure that the overall system architecture conforms to the design principles of high cohesion, low coupling, single responsibility and clear dependency.

[0182] Based on the hierarchical division strategy and module dependency relationship, the architecture rule entry is generated, which refers to the structured arrangement and standardized expression of the extracted hierarchical structure information and module dependency information, forming a rule entry set oriented to the actual system architecture management and review needs. The architecture rule entry includes hierarchical boundary rules, cross-layer call restrictions, module dependency specifications, interface design constraints, directory structure requirements, and naming rules. The entry exists in the form of structured data, logical rule set or templated expression, supports automatic parsing, fast matching and flexible expansion, and ensures that the system architecture rules have the ability of being landed, executable and sustainable maintenance.

[0183] The architecture rule entry is stored in the database structure, and the architecture knowledge base is generated, which refers to storing the generated architecture rule entry into the relational database, document database, graph database or knowledge graph platform according to the standardized data organization method and structure design, forming a centralized knowledge resource base oriented to architecture management, code review and system evolution. The database structure usually includes hierarchical rule table, dependency relationship table, rule index table, version control information and structure mapping relationship, has the ability of efficient query, fast retrieval, dynamic update and cross-system sharing, and the architecture knowledge base supports the continuous guarantee of architecture design compliance, dependency rationality and structure clarity in the process of system development, maintenance and evolution.

[0184] The embodiment can effectively solidify the system architecture design specification, clearly present the module hierarchical relationship and dependency path, improve the stability, scalability and maintainability of the system architecture, avoid the problems of system security risks, maintenance difficulties and low development efficiency caused by architecture confusion, unclear hierarchy or non-standard dependency, and enhance the clarity, standardization and engineering quality of the overall system structure.

[0185] In one embodiment, the above step S50 includes:

[0186] S501, analyzing the to-be-reviewed code change and locating the calling point of the project preset component;

[0187] S502, retrieving the usage specification of the corresponding project preset component from the component knowledge base;

[0188] S503, verifying whether the parameter configuration of the calling point conforms to the usage specification, and marking the calling point position and parameter difference that do not conform to the usage specification;

[0189] S504, generating a first check result based on the calling point position and parameter difference.

[0190] In the present embodiment, parsing the code change under review and locating the calling point of the project preset component refers to performing systematic analysis on the source code content of the code change under review through syntax analysis, structure analysis, code static scanning or processing based on abstract syntax tree, extracting various types of function calls, object instantiations, method references and configuration operations involved therein, and identifying the specific positions thereof having direct or indirect calling relationship with the project preset component. The calling point usually refers to the code segment, function call statement or configuration instruction in the source code that specifically triggers the function of the preset component, including the calling file path, line number range, calling expression content and associated context information. The locating process needs to ensure accurate identification of all calling points related to the project preset component, support cross-file, cross-module and multi-layer nested calling link tracking, and avoid missing potential dependency relationships or calling risks.

[0191] Retrieving the usage specification of the corresponding project preset component from the component knowledge base refers to performing index matching, keyword association or structure mapping operations based on the component name, function category, module identifier or configuration parameter in the located calling point information, and quickly retrieving the usage specification data of the project preset component corresponding to the calling point from the constructed component knowledge base. The usage specification usually comes from historical project accumulation, technical management requirements or security policy files, and the content includes component function description, calling method requirement, parameter configuration standard, dependency constraint relationship and application scenario limitation. The retrieval process needs to ensure the consistency, accuracy and version compatibility of the information, ensure that the subsequent inspection is based on authoritative and complete specification data, and improve the reliability and effectiveness of the specification checking.

[0192] Verifying whether the parameter configuration of the calling point conforms to the usage specification and marking the calling point position and parameter differences that do not conform to the usage specification refers to comparing the calling point information with the component usage specification, checking whether the various types of parameter names, parameter values, parameter types and configuration structures involved in the calling point strictly conform to the specification requirements, identifying problems such as parameter missing, type mismatch, value range overrun, configuration error or security policy missing, and marking the specific position of the problem in the source code, the file where the calling point is located, the line number range and the parameter difference type. The parameter difference specifically includes parameter name deviation, illegal parameter value, parameter structure not conforming to the template specification, lack of necessary security control configuration, etc. The marking result is expressed in the form of structured data, problem record list or graphical annotation, supporting subsequent problem positioning, repair suggestion generation and compliance tracking.

[0193] The first inspection result generated based on the call point position and parameter difference refers to integrating the call point position and parameter difference information marked in the foregoing steps into a structured inspection result for code review and compliance verification, including call point index information, parameter difference details, non-compliance type and security risk prompt. The first inspection result can be output as a structured data file, a graphical display interface or a review report segment for use by developers, testers or review systems, improving code review efficiency and accuracy, timely discovering and locating component call problems that violate usage specifications, and reducing system security risks and abnormal operation probability.

[0194] The embodiment can accurately locate the call point related to the preset component of the project by analyzing the code to be reviewed, compare the compliance of the parameter configuration one by one in combination with the complete usage specification stored in the component knowledge base, mark the call position and problem type with differences, and finally form a structured first inspection result. The embodiment can effectively realize the automatic inspection of the component call specification in the code change, avoid missing security configuration, parameter error or non-standard dependency problem, improve the security, stability and code quality of the system, reduce the manual review cost, and ensure the stable and reliable operation of the system function.

[0195] In one embodiment, the above step S60 includes:

[0196] S601, extracting the code entity identifier in the code to be reviewed, and parsing the lexical composition of the code entity identifier;

[0197] S602, querying the code entity naming specification from the domain knowledge base;

[0198] S603, verifying whether the lexical composition conforms to the code entity naming specification, and recording the code entity identifier and deviation type that do not conform to the code entity naming specification;

[0199] S604, generating a second inspection result based on the code entity identifier and deviation type that do not conform to the code entity naming specification.

[0200] In this embodiment, the code entity identifier in the code change to be reviewed is extracted, and the lexical composition of the code entity identifier is parsed, which means that the system extracts various types of code entity identifiers involved in the code by means of lexical analysis, syntax parsing or abstract syntax tree (AST) processing technology, with respect to the source code content of the part of the code change to be reviewed. The code entity identifier includes class name, interface name, method name, function name, variable name, constant name, parameter name and module name and other types of structural identification information with naming attribute. The extracted identifier needs to include the identifier body, position index, belonging scope and semantic context information. Parsing the lexical composition means that the identifier is divided into independent semantic units or lexical fragments based on naming specification conventions or language habits. Common processing methods include splitting based on camel case naming, underscore separation, hyphen or capital letter, extracting the basic lexical set constituting the identifier, which is used for subsequent comparison and analysis with the naming specification standard.

[0201] Querying the code entity naming specification from the domain knowledge base means that based on the constructed domain knowledge base, the corresponding naming specification item is retrieved according to the extracted code entity identifier category, semantic feature or module information. The code entity naming specification usually comes from industry standards, team management specifications or historical project accumulation, and contains naming rules, lexical conventions, semantic expressions, format structures and context restrictions that various entities should follow. The specification content supports multi-level, multi-type and multi-language differentiated management. The query process needs to ensure that the matched specification item has accuracy, integrity and real-time, supports flexible adaptation in different projects, different fields or different development language environments, and guarantees the standard uniformity and technical applicability of the naming specification verification.

[0202] Verifying whether the lexical composition conforms to the code entity naming specification and recording the code entity identifier and deviation type that do not conform to the code entity naming specification means that based on the extracted lexical composition and the queried naming specification content, the lexical structure, semantic expression, format style and context use of each identifier are compared one by one to see whether they conform to the specification requirements, and problems such as lexical use error, unclear semantic expression, inconsistent format style or inconsistency with context are identified. The deviation type includes that the lexical is not in the domain proper noun set, there is semantic ambiguity, the lexical use does not match the entity function, the naming structure does not conform to the format requirement, it violates the case convention or does not conform to the module belonging rule, etc. The recording process needs to mark the specific position, deviation type and difference details of the problem identifier, form structured naming specification violation information, and provide subsequent positioning, optimization and specification rectification.

[0203] The second inspection result is generated based on the code entity identifier that does not conform to the code entity naming specification and the deviation type, and refers to integrating the foregoing recorded violation identifier information and the deviation type into a structured inspection result for code review, specification management and quality control. The second inspection result supports output in a data file, a graphical interface or a report segment for use by a developer, a quality management personnel or an automated tool, thereby improving the automation level and accuracy of the naming specification inspection and reducing the code understanding difficulty, system maintenance risk and function positioning cost caused by the non-standard naming.

[0204] The embodiment can effectively find the naming non-standard problem in the code change, reduce the poor code readability, maintenance difficulty and function ambiguity risk caused by the naming confusion, and improve the maintainability, development efficiency and team collaboration consistency of the system.

[0205] In one embodiment, the step S70 includes:

[0206] S701, parsing the to-be-inspected code change to generate a code structure model;

[0207] S702, obtaining a code framework specification from the architecture knowledge base;

[0208] S703, matching the code structure model and the structural elements of the code framework specification to generate an element correspondence relationship;

[0209] S704, verifying whether the hierarchical division in the code structure model conforms to the hierarchical specification in the code framework specification based on the element correspondence relationship, and marking the hierarchical division position and the hierarchical deviation type that do not conform to the hierarchical specification in the code framework specification;

[0210] S705, verifying whether the module dependency in the code structure model conforms to the dependency specification in the code framework specification based on the element correspondence relationship, and marking the module dependency position and the dependency deviation type that do not conform to the dependency specification in the code framework specification;

[0211] S706, generating a third inspection result based on the hierarchical division position, the hierarchical deviation type, the module dependency position and the dependency deviation type.

[0212] In this embodiment, the code changes to be reviewed usually come from the version control system or the submission records in the development process. For these changes, a structural model is constructed through syntax analysis, abstract syntax tree generation, dependency extraction or other static analysis methods. This structural model not only contains module division, file attribution, class and interface hierarchy, but also includes method call relationship, package path organization, component boundary division and other information, forming a data expression available for comparison and verification.

[0213] The structural standard stored in the architecture knowledge base is derived from the overall design specification set in the project initiation phase or the structural convention accumulated in the long-term project, which usually covers hierarchical structure, dependency path, module boundary, function distribution rule and other contents, supports loading through database structure, configuration file or metadata form, ensures synchronization update with the actual project, and avoids specification lag or version mismatch problem.

[0214] The matching process of structural elements is based on string parsing, path mapping, semantic analysis, structural relationship comparison and other methods, which establishes the corresponding relationship between each actual structure in the model and the position, function, attribution in the standard specification layer by layer, and outputs complete element mapping information. This corresponding information can reflect the deviation of the actual structure from the standard design, providing a basis for subsequent verification.

[0215] The verification of hierarchical division identifies situations such as hierarchical confusion, position error, cross-layer reference, hierarchical omission or hierarchical depth not meeting the specification by checking the physical path, logical position, parent-child relationship, function attribution and other information of each structural unit. Position information includes specific directory, module path, code file location, etc., and deviation type reflects specific problem categories in hierarchical division, facilitating problem classification and positioning.

[0216] The verification of module dependency focuses on whether the call relationship, reference path, dependency configuration between different modules, functional units, components meet the design specification, and emphasizes the discovery of illegal dependencies, undeclared dependencies, cross-layer calls, dependency omissions or circular dependencies. Dependency position includes actual call in code, dependency declaration in configuration file, interface reference path, etc., and deviation type refers to specific dependency violation categories, which is beneficial for quick troubleshooting.

[0217] Finally, various structural problems are integrated and output in the form of clear structure, clear position and specific problem, forming a complete and structured inspection result. This inspection result can be presented in the form of text report, structural data, graphical display or interactive interface, supporting review process automation, problem visualization, accurate positioning and repair suggestion generation.

[0218] Example description: Before going online, the medical health information system extracts the preset component information closely related to the functions of electronic health record management, clinical data interaction, and remote medical service based on the existing historical code resources through system automatic analysis, including data desensitization module, interface flow limiting module, permission control module, and log tracking module. The system analyzes the declaration position, calling statement, and parameter configuration of these components in the historical code, combines the data protection requirements and access control standards of the medical business scene, automatically generates corresponding usage specification items, and stores them into the database to form a component knowledge base for data security and function compliance management of medical health systems.

[0219] Based on the internal data structure and functional design requirements of the medical health field, the system loads a set of medical-specific terms, including diagnosis and treatment department codes, patient information fields, medical test index names, and medical advice record fields. It also loads the defined data entity naming specification, which involves the unified naming rules for database fields, interface parameters, object class names, and method names. The system parses the naming specification content, generates standardized naming specification items, automatically establishes a mapping relationship with the set of specific terms, forms a structured storage domain knowledge base, and realizes unified term management and standard naming constraints in data structure and business logic.

[0220] The system further loads the code framework specification applicable to medical information systems, which involves business layer architecture, module dependency constraints, cross-module interface calling rules, and data access path restrictions. By parsing the framework specification, it automatically generates hierarchical division strategies and module dependency rules and stores them into the database to form an architecture knowledge base, which supports system structure review and module relationship verification, ensuring clear function division and stable module collaboration.

[0221] During the code update process, the system obtains the code change content to be reviewed based on structured comparison technology, and automatically extracts the newly added or modified code related to data security, business function, and system architecture adjustment.

[0222] The system calls the component knowledge base to perform automatic checking on the project preset component calling behavior involved in the code change to be reviewed, locates all calling points, retrieves the corresponding usage specification, verifies the consistency and standardization of parameter configuration, identifies the calling situation that does not conform to the standard configuration or has parameter differences, outputs the first checking result, and clearly indicates the location and specific difference information of the abnormal calling.

[0223] Based on the domain knowledge base, the system automatically extracts and semantically analyzes all code entity names in the code change to be reviewed, checks their compliance with the naming specification, identifies the field, parameter, or class method naming that does not accurately express the terminology, has chaotic naming structure, or does not conform to the medical field standard, outputs the second checking result, and details the naming content and corresponding deviation type of the existing problems.

[0224] The system relies on the architecture knowledge base to build a structural model corresponding to the code change to be reviewed, matches the structural elements of the framework specification, generates a corresponding relationship, automatically analyzes the hierarchical division and module dependency, verifies the rationality and compliance of the structural model, identifies problems such as cross-layer calling, module dependency disorder, or structural design deviation, outputs the third inspection result, and clearly specifies the specific location, type, and impact range of the structural problems.

[0225] The system integrates the first, second, and third inspection results, classifies and organizes component specification problems, naming specification problems, and architecture specification problems, automatically associates and matches corresponding repair suggestions based on specification standards and historical repair cases, generates a structured code review report, covers detailed information, specific locations, and optimization suggestions for various problems, and is used to ensure data security, code specification, and system structure rationality in medical and health information systems, and to improve system stability, functional consistency, and post-maintenance efficiency.

[0226] Similarly, in the process of version upgrade or function adjustment of financial technology systems, the system automatically identifies preset component information in business scenarios such as account management, transaction clearing and settlement, risk control strategy execution, and data encryption transmission in historical business systems, including but not limited to unified identity authentication modules, payment risk control interception modules, sensitive data desensitization modules, and high-frequency transaction flow control modules. Based on historical calling conditions, the system automatically extracts the declaration location, calling parameters, and upstream and downstream logical relationships of each component, generates standardized component usage rules based on technical requirements in different business scenarios, and forms a component knowledge base for financial technology business through structured storage.

[0227] The system loads a set of special terms in the financial field, including account types, fund identifiers, transaction states, risk control indicators, compliance labels, and message fields, and loads uniformly defined code entity naming specifications, covering standardized expression rules for database fields, interface parameters, object class names, and method names. The system automatically parses the naming specification items and establishes a mapping relationship with the special term set to form a domain knowledge base, ensuring that the data structure and business semantics are accurate and consistent during the development and maintenance of financial technology systems.

[0228] The system further loads the code framework specification applicable to financial technology systems, including hierarchical architecture design, module dependency management, microservice calling specification, and data isolation mechanism. The system generates clear hierarchical division standards and module dependency constraints by parsing the framework specification, stores the architecture knowledge base for standard verification of financial business system structure design and automatic checking of module coordination relationships.

[0229] The system automatically obtains the code change content to be reviewed based on version management information, extracts the added or modified part related to business logic, system structure and functional components, forms a data source to be reviewed, and enters the automatic review process.

[0230] For the code change to be reviewed, the system calls the component knowledge base, automatically parses the preset component call information, retrieves standardized usage specification items, checks the compliance of parameter configuration, call mode and usage location, locates the non-compliant call behavior and configuration difference, and outputs the first check result to clearly indicate the specific location of the problem component and the parameter abnormal type.

[0231] The system extracts and structurally analyzes all code entity naming in the code change to be reviewed based on the domain knowledge base, checks its compliance with the naming specification, identifies the naming expression that does not comply with the financial technology data structure or business semantic standard, including ambiguous field name, chaotic method naming or inaccurate category expression, outputs the second check result, and details the entity information and deviation category of the existing problems.

[0232] The system uses the architecture knowledge base to construct the structure model of the code change to be reviewed, automatically matches the structure elements and framework specification items, generates the element correspondence relationship, checks the hierarchical division and module dependency of the structure model based on the correspondence relationship, verifies the standard compliance of the design structure, identifies the problems such as module call out-of-bound, chaotic dependency relationship or unreasonable hierarchical design, outputs the third check result, and clearly indicates the location and deviation type of the existing structure design defects.

[0233] The system integrates the first check result, the second check result and the third check result, automatically classifies and arranges the component specification problems, the naming specification problems and the architecture specification problems, automatically matches the associated targeted repair suggestions combined with industry standards, compliance requirements and historical optimization experience, generates a structured code review report, fully reflects the specification problems, design defects and optimization paths existing in the system, ensures that the functional components of the financial technology system are compliant in the upgrading and iteration process, the naming expression is standardized, and the system structure design is reasonable, reduces the system risk, and improves the system stability, code maintainability and financial business continuity and compliance.

[0234] This embodiment combines the structure model and the framework specification, systematically finds the non-standard hierarchical division and module dependency problems in the structure design through structure mapping and strict verification, accurately marks the specific location and deviation type, improves the code structure consistency, architecture design compliance and system maintainability, and effectively reduces the stability risk and maintenance cost caused by structure confusion or dependency error.

[0235] In an embodiment, a knowledge base assisted code review device is provided, which corresponds to the knowledge base assisted code review method in the above embodiment. Referring to Figure 3 , Figure 3 A function module diagram of a preferred embodiment of the knowledge base assisted code review device of the present application is shown. The components include a component knowledge base construction module 10, a domain knowledge base construction module 20, an architecture knowledge base construction module 30, a code change acquisition module 40, a component call checking module 50, a naming specification checking module 60, an architecture specification checking module 70, and a review report generation module 80. The detailed descriptions of the function modules are as follows:

[0236] The component knowledge base construction module 10 is configured to extract the usage specification of the preset component of the project from the project historical code, and construct a component knowledge base.

[0237] The domain knowledge base construction module 20 is configured to construct a domain knowledge base based on the preset domain-specific terms and code entity naming specification.

[0238] The architecture knowledge base construction module 30 is configured to construct an architecture knowledge base based on the preset code framework specification.

[0239] The code change acquisition module 40 is configured to acquire the code change to be reviewed.

[0240] The component call checking module 50 is configured to check whether the call to the preset component of the project in the code change to be reviewed conforms to the usage specification based on the component knowledge base, and generate a first checking result.

[0241] The naming specification checking module 60 is configured to check whether the code entity naming in the code change to be reviewed conforms to the code entity naming specification based on the domain knowledge base, and generate a second checking result.

[0242] The architecture specification checking module 70 is configured to check whether the code structure of the code change to be reviewed conforms to the code framework specification based on the architecture knowledge base, and generate a third checking result.

[0243] The review report generation module 80 is configured to generate a code review report based on the first checking result, the second checking result, and the third checking result.

[0244] In an embodiment, the component knowledge base construction module 10 is specifically configured to:

[0245] scan the set of project historical code files to identify the declaration position of the preset component;

[0246] parse the call statement of the preset component, and extract the component configuration parameter from the call statement;

[0247] determining a context usage scenario of the preset component;

[0248] generating a usage specification entry of the preset component based on the component configuration parameter and the context usage scenario;

[0249] storing the usage specification entry into a database structure to generate a component knowledge base.

[0250] In an embodiment, the domain knowledge base construction module 20 is specifically configured to:

[0251] loading a preset domain-specific noun set and a preset code entity naming specification;

[0252] parsing the code entity naming specification to generate a naming specification entry;

[0253] associating the domain-specific noun set with the naming specification entry to generate a naming mapping relationship;

[0254] storing the naming mapping relationship into a database structure to generate a domain knowledge base.

[0255] In an embodiment, the architecture knowledge base construction module 30 is specifically configured to:

[0256] loading a preset code framework specification;

[0257] parsing the code framework specification to generate a hierarchical division strategy;

[0258] determining a module dependency relationship, and generating an architecture rule entry based on the hierarchical division strategy and the module dependency relationship;

[0259] storing the architecture rule entry into a database structure to generate an architecture knowledge base.

[0260] In an embodiment, the component call checking module 50 is specifically configured to:

[0261] parsing the code change to be reviewed to locate a calling point of a project preset component;

[0262] retrieving a usage specification of the corresponding project preset component from the component knowledge base;

[0263] verifying whether a parameter configuration of the calling point conforms to the usage specification, and marking a calling point position and a parameter difference that do not conform to the usage specification;

[0264] generating a first checking result based on the calling point position and the parameter difference.

[0265] In an embodiment, the naming specification checking module 60 is specifically configured to:

[0266] extracting a code entity identifier in the code change to be examined, and parsing a lexical composition of the code entity identifier;

[0267] querying a code entity naming specification from the domain knowledge base;

[0268] verifying whether the lexical composition conforms to the code entity naming specification, and recording a code entity identifier and a deviation type that do not conform to the code entity naming specification;

[0269] generating a second inspection result based on the code entity identifier and the deviation type that do not conform to the code entity naming specification.

[0270] In an embodiment, the architecture specification inspection module 70 is specifically configured to:

[0271] parsing the code change to be examined to generate a code structure model;

[0272] obtaining a code framework specification from the architecture knowledge base;

[0273] matching the code structure model with a structural element of the code framework specification to generate an element correspondence relationship;

[0274] verifying, based on the element correspondence relationship, whether a hierarchical division in the code structure model conforms to a hierarchical specification in the code framework specification, and marking a hierarchical division position and a hierarchical deviation type that do not conform to the hierarchical specification in the code framework specification;

[0275] verifying, based on the element correspondence relationship, whether a module dependency in the code structure model conforms to a dependency specification in the code framework specification, and marking a module dependency position and a dependency deviation type that do not conform to the dependency specification in the code framework specification;

[0276] generating a third inspection result based on the hierarchical division position, the hierarchical deviation type, the module dependency position, and the dependency deviation type.

[0277] In an embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in Figure 4As shown in the figure. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide determination and control capability. The memory of the computer device includes non-volatile and / or volatile storage medium, internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external user terminal through the network connection. The computer program is executed by the processor to realize the functions or steps of the knowledge base assisted code review method server side.

[0278] In one embodiment, a computer device is provided, which can be a user terminal, and its internal structure diagram can be as shown in the figure. Figure 5 As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide determination and control capability. The memory of the computer device includes non-volatile storage medium, internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external server through the network connection. The computer program is executed by the processor to realize the functions or steps of the knowledge base assisted code review method user terminal side

[0279] In one embodiment, a computer device is provided, including a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor executes the computer program to realize the following steps:

[0280] Extracting the usage specification of the project preset component from the project history code, constructing a component knowledge base;

[0281] Based on the preset field-specific name and code entity naming specification, a field knowledge base is constructed;

[0282] Based on the preset code framework specification, an architecture knowledge base is constructed;

[0283] Obtaining a code to be reviewed;

[0284] Based on the component knowledge base, it is checked whether the call to the project preset component in the code to be reviewed conforms to the usage specification, and a first checking result is generated;

[0285] Based on the field knowledge base, it is checked whether the code entity naming in the code to be reviewed conforms to the code entity naming specification, and a second checking result is generated;

[0286] checking whether the code structure of the to-be-reviewed code change conforms to the code framework specification based on the architecture knowledge base, and generating a third checking result;

[0287] generating a code review report based on the first checking result, the second checking result, and the third checking result.

[0288] In one embodiment, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. When the computer program is executed by a processor, the following steps are implemented:

[0289] extracting a usage specification of a project preset component from project historical code, and constructing a component knowledge base;

[0290] constructing a domain knowledge base based on a preset domain-specific term and code entity naming specification;

[0291] constructing an architecture knowledge base based on a preset code framework specification;

[0292] obtaining a to-be-reviewed code change;

[0293] checking whether a call to the project preset component in the to-be-reviewed code change conforms to the usage specification based on the component knowledge base, and generating a first checking result;

[0294] checking whether code entity naming in the to-be-reviewed code change conforms to the code entity naming specification based on the domain knowledge base, and generating a second checking result;

[0295] checking whether the code structure of the to-be-reviewed code change conforms to the code framework specification based on the architecture knowledge base, and generating a third checking result;

[0296] generating a code review report based on the first checking result, the second checking result, and the third checking result.

[0297] It should be noted that the functions or steps that the computer readable storage medium or the computer device can implement correspond to the related descriptions of the server side and the user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0298] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0299] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0300] It should be noted that if non-company software tools or components appear in the embodiments of the present application, they are only used for example introduction and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A knowledge base assisted code review method, characterized by, The method comprises the following steps: extracting usage specifications of project preset components from project history code to build a component knowledge base; constructing a domain knowledge base based on preset domain-specific terms and code entity naming specifications; constructing an architecture knowledge base based on preset code framework specifications; obtaining a code change to be reviewed; checking, based on the component knowledge base, whether the calling of the project preset component in the code change to be reviewed conforms to the usage specifications, and generating a first checking result; checking, based on the domain knowledge base, whether the code entity naming in the code change to be reviewed conforms to the code entity naming specifications, and generating a second checking result; checking, based on the architecture knowledge base, whether the code structure of the code change to be reviewed conforms to the code framework specifications, and generating a third checking result; generating a code review report based on the first checking result, the second checking result and the third checking result.

2. The knowledge base assistant-based code review method of claim 1, wherein, The method for extracting usage specifications of project preset components from project history code to build a component knowledge base comprises the following steps: scanning a project history code file set to identify the declaration position of a preset component; parsing the calling statement of the preset component and extracting component configuration parameters from the calling statement; determining the context usage scenario of the preset component; generating usage specification entries of the preset component based on the component configuration parameters and the context usage scenario; storing the usage specification entries in a database table structure to generate a component knowledge base.

3. The knowledge base assistant-based code review method of claim 1, wherein, The method for constructing a domain knowledge base based on preset domain-specific terms and code entity naming specifications comprises the following steps: loading a preset domain-specific term set and a preset code entity naming specification; parsing the code entity naming specification to generate naming specification entries; associating the domain-specific term set with the naming specification entries to generate a naming mapping relationship; storing the naming mapping relationship in a database structure to generate a domain knowledge base.

4. The knowledge base assistant-based code review method of claim 1, wherein, The method for constructing an architecture knowledge base based on preset code framework specifications comprises the following steps: loading a preset code framework specification; parsing the code framework specification to generate a hierarchical division strategy; determining a module dependency relationship and generating architecture rule entries based on the hierarchical division strategy and the module dependency relationship; storing the architecture rule entries in a database structure to generate an architecture knowledge base.

5. The knowledge base assistant-based code review method of claim 1, wherein, The method for checking, based on the component knowledge base, whether the calling of the project preset component in the code change to be reviewed conforms to the usage specifications, and generating a first checking result comprises the following steps: parsing the code change to be reviewed to locate the calling point of the project preset component; retrieving the usage specifications of the corresponding project preset component from the component knowledge base; verifying whether the parameter configuration of the calling point conforms to the usage specifications, and marking the calling point position and parameter differences that do not conform to the usage specifications; generating a first checking result based on the calling point position and the parameter differences.

6. The knowledge base assistant-based code review method of claim 1, wherein, The method for checking, based on the domain knowledge base, whether the code entity naming in the code change to be reviewed conforms to the code entity naming specifications, and generating a second checking result comprises the following steps: extracting a code entity identifier in the code change to be reviewed and parsing the lexical composition of the code entity identifier; querying the code entity naming specification from the domain knowledge base; verify whether the vocabulary composition conforms to the code entity naming specification, and record code entity identifiers and deviation types that do not conform to the code entity naming specification; generate a second checking result based on the code entity identifiers and the deviation types that do not conform to the code entity naming specification.

7. The knowledge base assistant-based code review method of claim 1, wherein, Based on the architecture knowledge base, check whether the code structure of the code to be reviewed conforms to the code framework specification, and generate a third checking result, including: parsing the code to be reviewed to generate a code structure model; obtaining code framework specifications from the architecture knowledge base; matching the code structure model with the structural elements of the code framework specification to generate an element correspondence relationship; based on the element correspondence relationship, verifying whether the hierarchical division in the code structure model conforms to the hierarchical specification in the code framework specification, and marking the hierarchical division position and the hierarchical deviation type that do not conform to the hierarchical specification in the code framework specification; based on the element correspondence relationship, verifying whether the module dependency in the code structure model conforms to the dependency specification in the code framework specification, and marking the module dependency position and the dependency deviation type that do not conform to the dependency specification in the code framework specification; based on the hierarchical division position, the hierarchical deviation type, the module dependency position, and the dependency deviation type, generate a third checking result.

8. A knowledge base assistance based code review apparatus, comprising: The code review device assisted by the knowledge base includes: a component knowledge base construction module configured to extract usage specifications of project preset components from historical project code to construct a component knowledge base; a domain knowledge base construction module configured to construct a domain knowledge base based on preset domain-specific terms and code entity naming specifications; an architecture knowledge base construction module configured to construct an architecture knowledge base based on preset code framework specifications; a code change acquisition module configured to acquire code to be reviewed; a component calling checking module configured to check, based on the component knowledge base, whether the calling of the project preset components in the code to be reviewed conforms to the usage specifications, and generate a first checking result; a naming specification checking module configured to check, based on the domain knowledge base, whether the code entity naming in the code to be reviewed conforms to the code entity naming specifications, and generate a second checking result; an architecture specification checking module configured to check, based on the architecture knowledge base, whether the code structure of the code to be reviewed conforms to the code framework specification, and generate a third checking result; a review report generation module configured to generate a code review report based on the first checking result, the second checking result, and the third checking result.

9. A computer device, comprising: The computer device includes a memory, a processor, and a code review program assisted by a knowledge base stored on the memory and executable on the processor, and the code review program assisted by the knowledge base, when executed by the processor, implements the steps of the code review method assisted by the knowledge base according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a code review program assisted by a knowledge base, and the code review program assisted by the knowledge base, when executed by the processor, implements the steps of the code review method assisted by the knowledge base according to any one of claims 1-7.

Images