CN116048498A

CN116048498A - 一种基于多版本的组件库架构

Info

Publication number: CN116048498A
Application number: CN202310338229.5A
Authority: CN
Inventors: 汪忠田; 张啸; 朱明宇
Original assignee: Suzhou Ruiyun Intelligent Service Information Technology Co ltd
Current assignee: Suzhou Ruiyun Intelligent Service Information Technology Co ltd
Priority date: 2023-03-31
Filing date: 2023-03-31
Publication date: 2023-05-02
Anticipated expiration: 2043-03-31
Also published as: CN116048498B

Abstract

本发明属于软件管理技术和软件管理系统技术领域，具体为一种基于多版本的组件库架构，该基于多版本的组件库架构包括核心模块、插件模块和补丁模块；组件库核心模块文件体积大小维持合理范围，不会因功能不断增加而无限膨胀，避免影响产品线或项目的加载性能；组件库版本发布周期维持合理范围，避免发布频率过高导致维护版本数量过多的问题，减少不必要的版本号浪费和维护成本，组件库维护版本只进行bug修复，保证同一版本内升级的稳定性；维护版本允许通过补丁模块注入新功能，保证紧急需求的可接入性；补丁模块仅提供给需求使用者使用，降低因注入新功能而造成的bug风险影响范围。

Description

一种基于多版本的组件库架构

技术领域

本发明涉及软件管理技术和软件管理系统技术领域，具体为一种基于多版本的组件库架构。

背景技术

随着公司业务的不断增长，为了提高项目的开发效率，通常会将web前端组件封装成底层的组件库，并提供给各个产品线和项目组使用。在组件库的开发和迭代过程中，常常会碰到这样的问题：组件库中存在一些逻辑较复杂、代码量较多、且耦合性不高的功能，只有少部分使用者会使用，在大多数项目中没有使用场景，但却会打包到组件库代码或项目代码中，使得文件体积过大，造成页面加载的性能损耗；已发布并处于维护状态的组件库版本（以下简称维护版本）数量过多，会带来大量的维护成本。例如，在某一维护版本上修复bug之后，需要按版本发布时间先后顺序依次向后合并代码，直到合入开发版本；产品线或项目组为了保证代码质量，降低测试成本，通常会认为组件库升级的优先级不高，在没有新功能需求的情况下不会选择升级组件库版本，这样就会使得组件库已发布版本没有使用者，造成版本号浪费；产品线或项目组可能存在客户紧急需求，需要在某一维护版本中添加新功能，如果直接在该维护版本上进行开发，一定会提升这个版本的不稳定性，从而使得其他开发者不敢轻易升级到同一版本的最新hotfix版本。

基于以上问题，现提出一种新的基于多版本的组件库架构设计模式，能够满足上述各种使用场景，本发明主要目的是组件库代码拆分，减少项目开发过程中因为加载非必须功能而造成的性能损耗；降低版本发布频率，减少因产品线或项目组没有使用而造成的版本号浪费，降低已发布版本的维护成本；提升维护版本稳定性，紧急需求采用功能注入的方式，降低新功能带来的bug风险影响范围。

发明内容

本发明的目的在于提供一种基于多版本的组件库架构，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：一种基于多版本的组件库架构，该基于多版本的组件库架构包括核心模块、插件模块和补丁模块；

所述核心模块为组件库的基础功能模块，包含组件库的基本功能，如基础组件定义、公共处理函数、三方库引入、插件接入接口、补丁接入接口、兼容性处理、样式定义；所述基础组件定义、公共处理函数、三方库引入均用于在插件模块和补丁模块加载的过程中，可以间接引用到核心模块中的所有基本功能，便于插件模块和补丁模块对核心模块的逻辑代码进行使用和覆写操作；所述兼容性处理是对核心模块的逻辑代码相互兼容进行处理；所述样式定义是对逻辑代码的样式种类进行定义；

所述插件模块用于对组件库的功能进行解耦，将代码进行分离；

所述补丁模块用于维护版本中进行功能注入。

优选的，该基于多版本的组件库架构具体实现方案包括：整体构架、模块加载、功能新增和bug修复，所述整体构架是根据需求场景对组件库进行拆分，并定义不同的模块策略；所述模块加载是项目启动阶段，需要定义不同模块的引入和加载流程；所述功能新增是在组件库多版本状态下，存在新功能时不同模块的处理方案；所述bug修复是在组件库多版本状态下，存在bug时不同模块的处理方案。

优选的，所述核心模块、插件模块、补丁模块在项目启动过程中的加载流程具体如下：（1）项目启动后，开始加载组件库相关代码；（2）首先加载组件库核心模块代码及相关功能；（3）调用核心模块中导出的插件接入接口，加载项目中指定添加的插件模块；（4）运行插件模块代码，在组件库中注册插件模块的相关功能；（5）调用核心模块中导出的补丁接入接口，加载项目中指定添加的补丁模块；（6）判断指定添加的补丁模块中所绑定的组件库版本号，是否与当前组件库版本号匹配；（7）如版本号匹配，则在组件库中注册补丁模块的相关功能；（8）如版本号不匹配，则直接跳过补丁模块的注册步骤；（9）继续执行组件库的后续加载步骤。

优选的，该组件库架构功能新增流程步骤如下：（1）当需要添加新功能时，首先判断需要增加的组件库版本；（2）如果是维护版本添加新功能，则需要开发补丁模块；（3）创建补丁包，例如patch-3.0-taskId，进行代码开发，完成补丁功能编写；（4）在npm服务器上发布补丁包；（5）如果是开发版本需要添加新功能，则继续判断功能大小及耦合程度；（6）如果功能较大且可独立，则可以开发插件模块；（7）创建插件包，例如plugin-taskId，进行代码开发，完成插件功能编写；（8）在npm服务器上发布插件包，在cdn服务器上发布插件文件；（9）如果功能不大，或者耦合性较强，则开发核心模块；（10）创建开发分支，进行代码开发，完成新功能编写；（11）在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（12）如果新功能在开发版本完成开发后，同时也需要在维护版本上添加相关功能，则在维护版本上继续开发补丁模块，重新执行（2）。

优选的，该组件库架构bug修复具体流程如下：（1）当需要修复bug时，首先判断需要修复的组件库版本；（2）如果是维护版本需要修复相关问题，则继续判断bug类别；（3）如果是补丁问题，则修改补丁相关代码后，重新在npm服务器上发布新版本补丁包；（4）如果是组件库相关问题，则修改组件库相关代码后，重新在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（5）如果是插件相关问题，则修改插件相关代码后，重新在npm服务器上发布新版本插件包，在cdn服务器上发布新版本插件文件；（6）如果是开发版本需要修复相关问题，则继续判断bug类别；（7）如果是组件库相关问题，则修改组件库相关代码后，等待新版本发布（包括npm服务器和cdn服务器）；（8）如果是插件相关问题，则修改插件相关代码后，等待新版本发布（包括npm服务器和cdn服务器）。

与现有技术相比，本发明的有益效果是：

本发明中组件库代码根据需求场景拆分为核心模块、插件模块、补丁模块三大部分；核心模块提供插件模块和补丁模块的接入接口，并在接口参数中提供核心模块内的所有基本功能，用于插件模块和补丁模块使用或覆写核心模块功能；插件模块和补丁模块在打包发布过程中，需要排除核心模块的所有引用代码，保证插件模块和补丁模块代码独立性；插件模块可以作为核心模块中大型功能的代码解耦部分，需要与核心模块同步发布，版本信息保持一致；补丁模块需要指定核心模块的版本号，核心模块的补丁接入接口仅允许版本号一致的补丁模块完成功能注入，组件库核心模块文件体积大小维持合理范围，不会因功能不断增加而无限膨胀，避免影响产品线或项目的加载性能；组件库版本发布周期维持合理范围，避免发布频率过高导致维护版本数量过多的问题，减少不必要的版本号浪费和维护成本，组件库维护版本只进行bug修复，保证同一版本内升级的稳定性；维护版本允许通过补丁模块注入新功能，保证紧急需求的可接入性；补丁模块仅提供给需求使用者使用，降低因注入新功能而造成的bug风险影响范围。

附图说明

图1为模块架构设计图；

图2为模块加载活动图；

图3为功能新增活动图；

图4为bug修复活动图；

图5为插件模块的单元组成图；

图6为补丁模块的单元组成图。

实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要理解的是，术语“上”、“下”、“前”、“后”、“左”、“右”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

实施例

请参阅图1-6，本发明提供一种技术方案：

一种基于多版本的组件库架构，该基于多版本的组件库架构包括核心模块、插件模块和补丁模块；

所述核心模块为组件库的基础功能模块，包含组件库的基本功能，如基础组件定义、公共处理函数、三方库引入、插件接入接口、补丁接入接口、兼容性处理、样式定义；

所述基础组件定义、公共处理函数、三方库引入均用于在插件模块和补丁模块加载的过程中，可以间接引用到核心模块中的所有基本功能，便于插件模块和补丁模块对核心模块的逻辑代码进行使用和覆写操作；所述兼容性处理是对核心模块的逻辑代码相互兼容进行处理；所述样式定义是对逻辑代码的样式种类进行定义；

使用者单独引用核心模块即可以正常实现组件库的基本需求，其中，插件接入接口和补丁接入接口的参数中，还需要提供核心模块内的所有基本功能，核心模块在版本迭代完成进入发布阶段后，同时发布npm服务器的组件库包以及cdn服务器的组件库文件，已发布的核心模块进入维护状态，只进行bug修复，禁止在维护版本中添加新功能代码，新功能只允许在开发版本中进行添加；

所述插件模块用于对组件库的功能进行解耦，将代码进行分离，针对部分代码文件体积较大、耦合度较低的功能，或者只有部分项目存在需求而没有必要给所有项目统一加载的功能，可以将其纳入插件模块，作为组件库的一个插件，通过核心模块提供的插件接入接口完成相关功能的加载和使用，通过核心模块提供的插件接入接口，插件模块可以间接引用到核心模块中的所有基本功能，可用于对核心模块的逻辑代码进行使用和覆写操作，插件模块在webpack打包编译的过程中，需要设置externals属性移除对核心模块的引用依赖，避免将核心模块代码打入到插件模块代码中，插件模块与核心模块一样，在版本迭代完成进入发布阶段后，同时发布npm服务器的插件包和cdn服务器的插件文件，已发布的插件模块进入维护状态，只进行bug修复，禁止在维护版本中添加新功能代码，新功能只允许在开发版本中进行添加；

所述插件模块包括插件框架单元、插件契约单元、插件组件单元和插件核心系统，所述插件框架单元用于组织和管理系统插件的下载、装载、组合、实例化以及销毁,并提供整套完整的与后台服务通信的操作接口；所述插件契约单元用于以服务接口的形式存在,系统的所有插件全部通过实现系统框架统一的接口规范,偏于有效的组织、管理插件对象；所述插件组件单元用于为具体的插件程序,实现了插件契约服务的一个独立的程序；插件核心系统在高层级上，它定义了核心系统如何操作和基本的业务逻辑，举例：通用工作流，像是数据如何在应用内部流动是定义好的，但是，工作流中包含的步骤取决于插件。因此，所有的插件会遵循这个提供它们自定义实现的通用流程，再深入一点儿，它仍然处理特殊案例，应用特殊规则和复杂条件处理，不管扩展插件是什么，这些都是需要强制执行的，此外，它仍然包含公共的代码来被多个插件去使用，来避免代码重复或者模板代码。如果两个插件都记录事务和失败日志，核心系统应该提供一个日志功能作为它的一部分。更不用说像安全、版本、UI 组件、数据库访问、缓存。

所述补丁模块用于维护版本中进行功能注入，针对维护版本，通常只会针对出现的代码逻辑bug进行修复，然后发布hotfix版本，而不允许将新功能直接添加到该版本中，但实际开发过程中，常常会出现客户紧急需求，需要在指定维护版本的组件库中，添加部分新功能，此时，可以将其纳入补丁模块，作为一个组件库的补丁，与核心模块代码相互分离，通过核心模块提供的补丁接入接口完成新功能在已发布版本上的注入，通过核心模块提供的补丁接入接口，补丁模块可以间接引用到核心模块中的所有基本功能，可用于对核心模块的逻辑代码进行使用和覆写操作，补丁模块在webpack打包编译的过程中，需要设置externals属性移除对核心模块的引用依赖，避免将核心模块代码打入到补丁模块代码中，补丁模块需要指定关联的组件库版本，只针对相应的版本生效，补丁模块开发结束后，只发布npm服务器的补丁包，已发布的补丁模块进入维护状态，只进行bug修复，不添加新功能。

所述补丁模块包括热补丁单元、冷补丁单元、增量型补丁单元和非增量型补丁单元；所述热补丁单元是补丁生效不中断业务，不影响业务运行，同时可以降低设备升级成本，避免升级风险；所述冷补丁单元是要使补丁生效需要重启设备，影响业务的运行；所述增量型补丁单元是指对在其前面的补丁有依赖性的补丁，一个新的补丁文件必须包含前一个补丁文件中的所有补丁信息。用户可以在不卸载原补丁文件的情况下直接安装新的补丁文件；非增量型补丁单元是只允许当前系统安装一个补丁文件。如果用户安装完补丁之后希望重新安装另一个补丁文件，则需要先卸载当前的补丁文件，然后再重新安装并运行新的补丁文件。

该基于多版本的组件库架构具体实现方案包括：整体构架、模块加载、功能新增和bug修复，所述整体构架是根据需求场景对组件库进行拆分，并定义不同的模块策略；所述模块加载是项目启动阶段，需要定义不同模块的引入和加载流程；所述功能新增是在组件库多版本状态下，存在新功能时不同模块的处理方案；所述bug修复是在组件库多版本状态下，存在bug时不同模块的处理方案。

所述核心模块、插件模块、补丁模块在项目启动过程中的加载流程具体如下：（1）项目启动后，开始加载组件库相关代码；（2）首先加载组件库核心模块代码及相关功能；（3）调用核心模块中导出的插件接入接口，加载项目中指定添加的插件模块；（4）运行插件模块代码，在组件库中注册插件模块的相关功能；（5）调用核心模块中导出的补丁接入接口，加载项目中指定添加的补丁模块；（6）判断指定添加的补丁模块中所绑定的组件库版本号，是否与当前组件库版本号匹配；（7）如版本号匹配，则在组件库中注册补丁模块的相关功能；（8）如版本号不匹配，则直接跳过补丁模块的注册步骤；（9）继续执行组件库的后续加载步骤。

该组件库架构功能新增流程步骤如下：（1）当需要添加新功能时，首先判断需要增加的组件库版本；（2）如果是维护版本添加新功能，则需要开发补丁模块；（3）创建补丁包，例如patch-3.0-taskId，进行代码开发，完成补丁功能编写；（4）在npm服务器上发布补丁包；（5）如果是开发版本需要添加新功能，则继续判断功能大小及耦合程度；（6）如果功能较大且可独立，则可以开发插件模块；（7）创建插件包，例如plugin-taskId，进行代码开发，完成插件功能编写；（8）在npm服务器上发布插件包，在cdn服务器上发布插件文件；（9）如果功能不大，或者耦合性较强，则开发核心模块；（10）创建开发分支，进行代码开发，完成新功能编写；（11）在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（12）如果新功能在开发版本完成开发后，同时也需要在维护版本上添加相关功能，则在维护版本上继续开发补丁模块，重新执行（2）。

该组件库架构bug修复具体流程如下：（1）当需要修复bug时，首先判断需要修复的组件库版本；（2）如果是维护版本需要修复相关问题，则继续判断bug类别；（3）如果是补丁问题，则修改补丁相关代码后，重新在npm服务器上发布新版本补丁包；（4）如果是组件库相关问题，则修改组件库相关代码后，重新在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（5）如果是插件相关问题，则修改插件相关代码后，重新在npm服务器上发布新版本插件包，在cdn服务器上发布新版本插件文件；（6）如果是开发版本需要修复相关问题，则继续判断bug类别；（7）如果是组件库相关问题，则修改组件库相关代码后，等待新版本发布（包括npm服务器和cdn服务器）；（8）如果是插件相关问题，则修改插件相关代码后，等待新版本发布（包括npm服务器和cdn服务器）。

与本发明相关的现有技术：

专利号为201910854862.3的《包含插件的应用程序的构建方法、装置、介质及电子设备》，平安普惠企业管理有限公司，在项目中提供插件接口，允许将一部分功能以插件化的方式进行开发，最后将插件安装包加载到整个项目中，但是本现有技术存在的技术缺陷是能够实现代码的拆分，将一部分使用场景较少的功能从核心代码中移至插件中，防止核心代码文件体积过大。但是在多版本的组件库场景下，仍然会存在已发布版本维护成本高的问题。

应用场景举例

例如，客户需要增加一个富文本编辑器的功能，对于组件库而言，富文本编辑器是一个相对独立的功能组件，并非所有的项目都需要使用这个功能，如果将其放入核心模块中，会造成项目打包后的文件体积过大的问题，影响网页的加载和渲染速度，因此在开发版本中可以将其纳入插件模块，等到功能开发完毕后发布npm服务器的插件包和cdn服务器的插件文件，但是在维护版本中，为了保障版本的稳定性，不能直接将富文本编辑器的功能添加到维护版本的代码中，此时可以将该功能纳入维护版本的补丁模块，通过维护版本的补丁接入接口注入富文本编辑器的相关功能，功能开发完毕后发布npm服务器的补丁包。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点,对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明；因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内，不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims

1.一种基于多版本的组件库架构，其特征在于，该基于多版本的组件库架构包括核心模块、插件模块和补丁模块；

所述补丁模块用于维护版本中进行功能注入。

2.根据权利要求1所述的一种基于多版本的组件库架构，其特征在于：该基于多版本的组件库架构具体实现方案包括：整体构架、模块加载、功能新增和bug修复，所述整体构架是根据需求场景对组件库进行拆分，并定义不同的模块策略；所述模块加载是项目启动阶段，需要定义不同模块的引入和加载流程；所述功能新增是在组件库多版本状态下，存在新功能时不同模块的处理方案；所述bug修复是在组件库多版本状态下，存在bug时不同模块的处理方案。

3.根据权利要求1所述的一种基于多版本的组件库架构，其特征在于：所述核心模块、插件模块、补丁模块在项目启动过程中的加载流程具体如下：（1）项目启动后，开始加载组件库相关代码；（2）首先加载组件库核心模块代码及相关功能；（3）调用核心模块中导出的插件接入接口，加载项目中指定添加的插件模块；（4）运行插件模块代码，在组件库中注册插件模块的相关功能；（5）调用核心模块中导出的补丁接入接口，加载项目中指定添加的补丁模块；（6）判断指定添加的补丁模块中所绑定的组件库版本号，是否与当前组件库版本号匹配；（7）如版本号匹配，则在组件库中注册补丁模块的相关功能；（8）如版本号不匹配，则直接跳过补丁模块的注册步骤；（9）继续执行组件库的后续加载步骤。

4.根据权利要求1所述的一种基于多版本的组件库架构，其特征在于：该组件库架构功能新增流程步骤如下：（1）当需要添加新功能时，首先判断需要增加的组件库版本；（2）如果是维护版本添加新功能，则需要开发补丁模块；（3）创建补丁包，例如patch-3.0-taskId，进行代码开发，完成补丁功能编写；（4）在npm服务器上发布补丁包；（5）如果是开发版本需要添加新功能，则继续判断功能大小及耦合程度；（6）如果功能较大且可独立，则可以开发插件模块；（7）创建插件包，例如plugin-taskId，进行代码开发，完成插件功能编写；（8）在npm服务器上发布插件包，在cdn服务器上发布插件文件；（9）如果功能不大，或者耦合性较强，则开发核心模块；（10）创建开发分支，进行代码开发，完成新功能编写；（11）在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（12）如果新功能在开发版本完成开发后，同时也需要在维护版本上添加相关功能，则在维护版本上继续开发补丁模块，重新执行（2）。

5.根据权利要求1所述的一种基于多版本的组件库架构，其特征在于：该组件库架构bug修复具体流程如下：（1）当需要修复bug时，首先判断需要修复的组件库版本；（2）如果是维护版本需要修复相关问题，则继续判断bug类别；（3）如果是补丁问题，则修改补丁相关代码后，重新在npm服务器上发布新版本补丁包；（4）如果是组件库相关问题，则修改组件库相关代码后，重新在npm服务器上发布新版本组件库包，在cdn服务器上发布新版本组件库文件；（5）如果是插件相关问题，则修改插件相关代码后，重新在npm服务器上发布新版本插件包，在cdn服务器上发布新版本插件文件；（6）如果是开发版本需要修复相关问题，则继续判断bug类别；（7）如果是组件库相关问题，则修改组件库相关代码后，等待新版本发布；（8）如果是插件相关问题，则修改插件相关代码后，等待新版本发布。