CN113918239A - 代码实现方法及系统 - Google Patents

Abstract

本申请公开了一种代码实现方法，该方法包括：针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件；将所述工作空间中配置的所述插件安装到本地；当所述工作空间执行所述任务需要使用所述插件时，加载所述插件；使用所述工作空间的所述环境参数，运行所述插件，并得到运行结果。本申请还公开了一种代码实现系统、电子装置和计算机可读存储介质。由此，能够在同一套代码的服务架构下，横向扩展针对不同业务场景的独立功能，以此满足不同的市场需求。

Description

代码实现方法及系统

技术领域

本申请涉及代码维护技术领域，尤其涉及一种代码实现方法、系统、电子装置及计算机可读存储介质。

背景技术

伴随市场需求不断扩大，业务场景愈加复杂，为了适应不同市场的不同业务场景，会有多个应用服务提供基础的技术支持，不同服务之间既有差异也有共同点。通常的做法是：维护一份源码，根据差异性，编译出多个不同的代码包；建立多个独立分支，或者多个版本，进行单独维护；不同业务团队去维护不同市场的业务，各业务相互独立。但是，在一个应用服务中想要满足多个市场与业务场景的覆盖，需要同时维护针对不同业务的不同代码，增加了维护成本与资源占用率，降低了扩展性。

发明内容

本申请的主要目的在于提出一种代码实现方法、系统、电子装置及计算机可读存储介质，旨在解决如何让同一套代码同时满足不同业务场景的问题。

为实现上述目的，本申请实施例提供了一种代码实现方法，所述方法包括：

针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件；

将所述工作空间中配置的所述插件安装到本地；

当所述工作空间执行所述任务需要使用所述插件时，加载所述插件；

使用所述工作空间的所述环境参数，运行所述插件，并得到运行结果。

可选地，所述方法还包括：

当所述插件不再使用或需要更新时，卸载本地的所述插件。

可选地，所述针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件包括：

根据需要执行的任务创建对应的工作空间；

配置所述工作空间的环境参数；

配置所述工作空间中需要使用的一个或多个插件以及每个插件的固定参数。

可选地，每个所述插件为独立的代码包，代码的入口文件对外暴露两个接口，其中第一接口用于管理所述插件的固定参数，提供所述插件在不同业务场景的可选配置；第二接口用于获取上游插件的处理结果数据，并在对所述数据做对应的业务处理后传递给下游插件。

可选地，每个所述插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖信息。

可选地，所述将所述工作空间中配置的所述插件安装到本地包括：

安装指定版本的所述插件到插件缓存目录；

在所述插件安装完成后，读取所述插件的所述信息文件获取所述插件依赖信息，并根据所述插件依赖信息安装所述插件的所有依赖包。

可选地，所述加载所述插件包括：

根据所述插件的所述信息文件，将所述插件注册到对应的扩展点；

加载所述插件对应的入口文件，将所述插件引入到所述工作空间。

可选地，每个所述插件单独实现一个业务功能，提供用户交互界面，处理与用户之间的交互操作。

此外，为实现上述目的，本申请实施例还提供一种代码实现系统，所述系统包括：

配置模块，用于针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件；

安装模块，用于将所述工作空间中配置的所述插件安装到本地；

加载模块，用于当所述工作空间执行所述任务需要使用所述插件时，加载所述插件；

运行模块，用于使用所述工作空间的所述环境参数，运行所述插件，并得到运行结果。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代码实现程序，所述代码实现程序被所述处理器执行时实现如上述的代码实现方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有代码实现程序，所述代码实现程序被处理器执行时实现如上述的代码实现方法。

本申请实施例提出的代码实现方法、系统、电子装置及计算机可读存储介质，能够将不同的业务功能代码开发为独立的插件，在主服务系统运行时通过先创建工作空间，然后配置对应的环境参数和使用的插件，在指定的工作空间中执行任务时读取所述环境参数，运行相应插件的逻辑，生成运行结果。由此，相同任务流程可以通过不同的插件来实现逻辑的差异，同一个插件也能根据运行的工作环境(工作空间)，生成不同的运行结果，实现了在同一套代码的服务架构下，横向扩展针对不同业务场景的独立功能，以此满足不同的市场需求。

附图说明

图1为实现本申请各个实施例的一种应用环境架构图；

图2为本申请第一实施例提出的一种代码实现方法的流程图；

图3为本申请实施例中不同任务调用不同插件的示意图；

图4为本申请第二实施例提出的一种代码实现方法的流程图；

图5为本申请第三实施例提出的一种电子装置的硬件架构示意图；

图6为本申请第四实施例提出的一种代码实现系统的模块示意图；

图7为本申请第五实施例提出的一种代码实现系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

请参阅图1，图1为实现本申请各个实施例的一种应用环境架构图。本申请可应用于包括，但不仅限于插件开发端2、插件发布端4、工作端6的应用环境中。

其中，所述插件开发端2用于开发工作端6所需的各种代码，并将不同业务功能的代码生成插件。在本申请实施例中，所述代码主要是指Node.js代码。

每个插件作为独立的Node.js代码包存在，可用于单独的代码运行与功能调试。代码的主入口对外暴露两个接口，一个接口用于管理插件的配置参数，提供插件在不同业务场景的可选配置；另外一个接口用于获取上游插件处理结果数据，并对传递过来的数据做对应的业务处理，然后传递给下游插件。

并且，每个插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖等信息。其中，插件名作为插件的唯一标识；插件版本提供插件的升级更新；插件扩展点记录插件的具体功能，例如可视化系统中的编辑、打包、发布、文件上传等；插件依赖用于指明当前插件依赖哪些代码包，保证安装的时候能够一起下载。

所述插件发布端4用于通过Node.js自带的NPM(Node Package Manager，Node.js包管理器)工具，将每个插件的代码打包发布到包管理平台，所述包管理平台可以是registry.npmjs.org或者国内的镜像站，也可以是私有的包管理平台。

所述工作端6用于运行主服务系统的任务，配置该任务对应的工作空间的环境参数和需要使用的插件，并在该任务流程中调用相应的插件。所述插件可以预先从所述插件发布端4下载到本地。

实施例一

如图2所示，为本申请第一实施例提出的一种代码实现方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述工作端6作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件。

主服务系统可以运行多种任务，每个任务对应不同的工作空间(工作环境)，实现不同的业务功能。在本实施例中，这些不同的业务功能可以通过不同的插件实现。每个所述工作空间中可以通过多个插件串联不同的业务功能，以完成整个任务。首先，根据需要执行的任务创建工作环境(工作空间)，然后配置对应工作空间的环境参数。另外还需配置指定工作空间中使用哪些插件(可能一个或多个，一般是多个插件串联多个业务功能)以及每个插件的固定参数。

所述固定参数根据每个插件所对应的业务功能而各不相同。例如，云存储插件的参数有bucket(一种容器，用于指定传输到那个bucket，业务上用于区分不同的发行地区，会将文件上传到对应国家或地区的云存储)、密钥(用于不同bucket的上传身份验证)等。发布插件的参数有服务器名、服务器密钥(不同的业务数据会发布到不同的服务器上)，是否通知(发布后是否用邮件通知用户)等。构建插件的参数包含不同业务的各种区分参数(这样在构建代码产物的时候能够加入不同业务所需要的内容)，例如采用什么样式的页面模板、模板构建处理的静态资源标识等。

S202，将所述工作空间中配置的所述插件安装到本地。

根据上述对插件的配置，可以通过所述插件发布端(NPM平台)将相应的插件代码下载到本地进行安装。

在所述插件发布端，每个插件作为独立的Node.js代码包存在，可用于单独的代码运行与功能调试。代码的主入口(入口文件)对外暴露两个接口，一个接口(第一接口)用于管理插件的配置参数(所述固定参数)，提供插件在不同业务场景的可选配置；另外一个接口(第二接口)用于获取上游插件处理结果数据，并对传递过来的数据做对应的业务处理，然后传递给下游插件。

并且，每个插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖等信息。其中，插件名作为插件的唯一标识；插件版本提供插件的升级更新；插件扩展点记录插件的具体功能，例如可视化系统中的编辑、打包、发布、文件上传等；插件依赖用于指明当前插件依赖哪些代码包，保证安装的时候能够一起下载。

具体而言，通过npm install命令安装指定版本的插件到插件缓存目录。插件安装完成后，读取插件的所述信息文件获取插件依赖等信息，并根据所述插件依赖信息安装插件的所有依赖包。

S204，当所述工作空间执行任务需要使用所述插件时，加载所述插件。

根据插件的所述信息文件，可以将所述插件注册到对应的扩展点。在对应工作空间内执行任务需要使用插件时，主服务系统加载对应的入口文件(暴露出所述插件的两个接口)，将指定的所述插件引入到工作空间，准备下一步的插件运行。

S206，使用所述工作空间的所述环境参数，运行加载好的所述插件，并得到运行结果。

当主服务系统运行到指定扩展功能的时候，调用指定插件的处理接口(第二接口)，将需要处理的数据(上游数据)传递给所述指定插件。并在所述指定插件处理完数据之后，通过所述第二接口获取所述指定插件返回的数据，并传递给下一个流程需要的插件(通过下游插件的第二接口传递)。每个插件之间相互独立，互不干扰，当其中一个插件运行出错的时候不会影响到其他插件的功能，并且每个插件可以单独修改或升级。

如图3所示，为本申请实施例中主服务系统执行不同任务时调用不同插件的示意图。在图3中，主服务系统执行任务A和任务B，且任务A和任务B均包含流程A、B、C。其中，针对任务A创建对应的工作空间A并配置相应的环境参数和使用的插件，在工作空间A中，流程A调用插件A，流程B调用插件C，流程C调用插件D。而针对任务B创建对应的工作空间B(未示出)并配置相应的环境参数和使用的插件，在工作空间B中，流程A调用插件B，流程B调用插件C，流程C调用插件E。

任务A和任务B虽然都包含流程A、B、C，但调用的插件不同，因此可以通过不同插件的逻辑差异，实现不同的业务功能。而插件C虽然被任务A和任务B都有调用，但由于工作空间A和工作空间B的环境参数不同，也可以生成不同的运行结果。

本实施例提出的代码实现方法，将不同的业务功能代码开发为独立的插件，在主服务系统运行时通过先针对不同任务分别创建工作空间，然后配置对应的环境参数和使用的插件，在指定的工作空间中执行任务时读取所述环境参数，运行相应插件的逻辑，生成运行结果。由此，相同任务流程可以通过不同的插件来实现逻辑的差异，同一个插件也能根据运行的工作环境(工作空间)，生成不同的运行结果，实现了在同一套代码的服务架构下，横向扩展针对不同业务场景的独立功能，以此满足不同的市场需求。

为了更详尽的对该方法的上述各步骤进行解释说明，以下以特定的具体实施例(可视化平台运行一个任务)为例进行说明。本领域技术人员当知，下述具体实施例的内容并不用于限制本发明的发明思想，本领域技术人员可以轻易依据下述实施例具体描述内容进行适当的内容发散和扩展。

假设任务A对应工作空间A，在任务A中，用户先后对数据进行创建、编辑、发布的操作，而工作空间A则分别调用插件A、插件B、插件C来实现所述创建、编辑、发布的功能，以完成任务A。

(1)用户打开平台首页，进行第一创建操作，点击创建按钮。当接收到用户的创建需求后，在对应的工作空间A中查找到创建功能所管理的插件A，运行插件A，运行时可获取到工作空间A的环境参数。运行结束后，如果创建成功，即将结果返回给用户。

倘若用户是在任务B中进行第二创建操作，而任务B对应工作空间B，如果工作空间B关联的还是插件A，此时插件A在工作空间B的环境下运行，使用的是工作空间B的环境参数。

(2)用户选择之前创建的数据，点击编辑。此时需要实现用户通过不同的交互形式对数据的细致修改，这部分比较复杂，而且变动性较高。如果每次编辑都是主服务系统与用户交互，然后将用户的需求调用插件B运行，返回结果，则当用户与系统之间的交互形式发生改变时，就需要修改系统的操作界面。

本实施例的解决方式是，用户通过主服务系统进入编辑时，系统调用插件B，插件B返回一个http服务。从而，由该http服务与用户的客户端之间交互，由插件B的该http服务提供用户交互界面，用户在客户端的操作都是直接与插件B的http服务进行的。这样让用户直接跟插件进行交互，则在交互变动的时候，只需要修改插件B即可，不需要修改主服务系统。因此，可以最大限度地提高插件的灵活度，实现更多的自定义功能，且不牵扯到系统的调整。

(3)用户针对编辑后的数据点击发布。当接收到用户的发布需求后，主服务系统调用插件C，插件C依旧运行在工作空间A中，使用工作空间A的环境参数，运行插件C，发布数据，并返回运行结果。

实施例二

如图4所示，为本申请第二实施例提出的一种代码实现方法的流程图。在第二实施例中，所述代码实现方法在上述第一实施例的基础上，还包括步骤S308。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S300，针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件。

主服务系统可以运行多种任务，每个任务对应不同的工作空间(工作环境)，实现不同的业务功能。在本实施例中，这些不同的业务功能可以通过不同的插件实现。每个所述工作空间中可以通过多个插件串联不同的业务功能，以完成整个任务。首先，根据需要执行的任务创建工作环境(工作空间)，然后配置对应工作空间的环境参数。另外还需配置指定工作空间中使用哪些插件(可能一个或多个，一般是多个插件串联多个业务功能)以及每个插件的固定参数。

所述固定参数根据每个插件所对应的业务功能而各不相同。例如，云存储插件的参数有bucket、密钥等。发布插件的参数有服务器名、服务器密钥、是否通知等。构建插件的参数包含不同业务的各种区分参数，例如采用什么样式的页面模板、模板构建处理的静态资源标识等。

S302，将所述工作空间中配置的所述插件安装到本地。

根据上述对插件的配置，可以通过所述插件发布端(NPM平台)将相应的插件代码下载到本地进行安装。

在所述插件发布端，每个插件作为独立的Node.js代码包存在，可用于单独的代码运行与功能调试。代码的主入口(入口文件)对外暴露两个接口，一个接口(第一接口)用于管理插件的配置参数(所述固定参数)，提供插件在不同业务场景的可选配置；另外一个接口(第二接口)用于获取上游插件处理结果数据，并对传递过来的数据做对应的业务处理，然后传递给下游插件。

并且，每个插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖等信息。其中，插件名作为插件的唯一标识；插件版本提供插件的升级更新；插件扩展点记录插件的具体功能，例如可视化系统中的编辑、打包、发布、文件上传等；插件依赖用于指明当前插件依赖哪些代码包，保证安装的时候能够一起下载。

具体而言，通过npm install命令安装指定版本的插件到插件缓存目录。插件安装完成后，读取插件的所述信息文件获取插件依赖等信息，并根据所述插件依赖信息安装插件的所有依赖包。

S304，当所述工作空间执行任务需要使用所述插件时，加载所述插件。

根据插件的所述信息文件，可以将所述插件注册到对应的扩展点。在对应工作空间内执行任务需要使用插件时，主服务系统加载对应的入口文件(暴露出所述插件的两个接口)，将指定的所述插件引入到工作空间，准备下一步的插件运行。

S306，使用所述工作空间的所述环境参数，运行加载好的所述插件，并得到运行结果。

当主服务系统运行到指定扩展功能的时候，调用指定插件的处理接口(第二接口)，将需要处理的数据(上游数据)传递给所述指定插件。并在所述指定插件处理完数据之后，通过所述第二接口获取所述指定插件返回的数据，并传递给下一个流程需要的插件(通过下游插件的第二接口传递)。每个插件之间相互独立，互不干扰，当其中一个插件运行出错的时候不会影响到其他插件的功能，并且每个插件可以单独修改或升级。

例如，主服务系统执行任务A和任务B，且任务A和任务B均包含流程A、B、C。其中，针对任务A创建对应的工作空间A并配置相应的环境参数和使用的插件，在工作空间A中，流程A调用插件A，流程B调用插件C，流程C调用插件D。而针对任务B创建对应的工作空间B并配置相应的环境参数和使用的插件，在工作空间B中，流程A调用插件B，流程B调用插件C，流程C调用插件E。

任务A和任务B虽然都包含流程A、B、C，但调用的插件不同，因此可以通过不同插件的逻辑差异，实现不同的业务功能。而插件C虽然被任务A和任务B都有调用，但由于工作空间A和工作空间B的环境参数不同，也可以生成不同的运行结果。

S308，当所述插件不再使用或需要更新时，卸载本地的所述插件。

当有某个插件不再使用或者需要更新的时候，所述工作端删除在所述插件发布端下载到本地的所述插件的代码包。如果是插件更新，需要再从所述插件发布端重新下载和安装所述插件新版本的代码包。

实施例三

如图5所示，为本申请第三实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图5仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述工作端6。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如代码实现系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述代码实现系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例四

如图6所示，为本申请第四实施例提出一种代码实现系统60的模块示意图。所述代码实现系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述代码实现系统60包括：

配置模块600，用于针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件。

主服务系统可以运行多种任务，每个任务对应不同的工作空间(工作环境)，实现不同的业务功能。在本实施例中，这些不同的业务功能可以通过不同的插件实现。每个所述工作空间中可以通过多个插件串联不同的业务功能，以完成整个任务。首先，根据需要执行的任务创建工作环境(工作空间)，然后配置对应工作空间的环境参数。另外还需配置指定工作空间中使用哪些插件(可能一个或多个，一般是多个插件串联多个业务功能)以及每个插件的固定参数。

所述固定参数根据每个插件所对应的业务功能而各不相同。例如，云存储插件的参数有bucket、密钥等。发布插件的参数有服务器名、服务器密钥、是否通知等。构建插件的参数包含不同业务的各种区分参数，例如采用什么样式的页面模板、模板构建处理的静态资源标识等。

安装模块602，用于将所述工作空间中配置的所述插件安装到本地。

根据上述对插件的配置，可以通过所述插件发布端(NPM平台)将相应的插件代码下载到本地进行安装。

在所述插件发布端，每个插件作为独立的Node.js代码包存在，可用于单独的代码运行与功能调试。代码的主入口(入口文件)对外暴露两个接口，一个接口(第一接口)用于管理插件的配置参数(所述固定参数)，提供插件在不同业务场景的可选配置；另外一个接口(第二接口)用于获取上游插件处理结果数据，并对传递过来的数据做对应的业务处理，然后传递给下游插件。

并且，每个插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖等信息。其中，插件名作为插件的唯一标识；插件版本提供插件的升级更新；插件扩展点记录插件的具体功能，例如可视化系统中的编辑、打包、发布、文件上传等；插件依赖用于指明当前插件依赖哪些代码包，保证安装的时候能够一起下载。

具体而言，通过npm install命令安装指定版本的插件到插件缓存目录。插件安装完成后，读取插件的所述信息文件获取插件依赖等信息，并根据所述插件依赖信息安装插件的所有依赖包。

加载模块604，用于当所述工作空间执行任务需要使用所述插件时，加载所述插件。

根据插件的所述信息文件，可以将所述插件注册到对应的扩展点。在对应工作空间内执行任务需要使用插件时，主服务系统加载对应的入口文件(暴露出所述插件的两个接口)，将指定的所述插件引入到工作空间，准备下一步的插件运行。

运行模块606，用于使用所述工作空间的所述环境参数，运行加载好的所述插件，并得到运行结果。

当主服务系统运行到指定扩展功能的时候，调用指定插件的处理接口(第二接口)，将需要处理的数据(上游数据)传递给所述指定插件。并在所述指定插件处理完数据之后，通过所述第二接口获取所述指定插件返回的数据，并传递给下一个流程需要的插件(通过下游插件的第二接口传递)。每个插件之间相互独立，互不干扰，当其中一个插件运行出错的时候不会影响到其他插件的功能，并且每个插件可以单独修改或升级。

例如，主服务系统执行任务A和任务B，且任务A和任务B均包含流程A、B、C。其中，针对任务A创建对应的工作空间A并配置相应的环境参数和使用的插件，在工作空间A中，流程A调用插件A，流程B调用插件C，流程C调用插件D。而针对任务B创建对应的工作空间B并配置相应的环境参数和使用的插件，在工作空间B中，流程A调用插件B，流程B调用插件C，流程C调用插件E。

任务A和任务B虽然都包含流程A、B、C，但调用的插件不同，因此可以通过不同插件的逻辑差异，实现不同的业务功能。而插件C虽然被任务A和任务B都有调用，但由于工作空间A和工作空间B的环境参数不同，也可以生成不同的运行结果。

本实施例提出的代码实现系统，将不同的业务功能代码开发为独立的插件，在主服务系统运行时通过先针对不同任务分别创建工作空间，然后配置对应的环境参数和使用的插件，在指定的工作空间中执行任务时读取所述环境参数，运行相应插件的逻辑，生成运行结果。由此，相同任务流程可以通过不同的插件来实现逻辑的差异，同一个插件也能根据运行的工作环境(工作空间)，生成不同的运行结果，实现了在同一套代码的服务架构下，横向扩展针对不同业务场景的独立功能，以此满足不同的市场需求。

实施例五

如图7所示，为本申请第五实施例提出一种代码实现系统60的模块示意图。在本实施例中，所述代码实现系统60除了包括第四实施例中的所述配置模块600、安装模块602、加载模块604、运行模块606之外，还包括卸载模块608。

所述卸载模块608，用于当所述插件不再使用或需要更新时，卸载本地的所述插件。

当有某个插件不再使用或者需要更新的时候，所述工作端删除在所述插件发布端下载到本地的所述插件的代码包。如果是插件更新，需要再从所述插件发布端重新下载和安装所述插件新版本的代码包。

实施例六

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有代码实现程序，所述代码实现程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的代码实现方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (11)

1.一种代码实现方法，其特征在于，所述方法包括：

针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件；

将所述工作空间中配置的所述插件安装到本地；

当所述工作空间执行所述任务需要使用所述插件时，加载所述插件；

使用所述工作空间的所述环境参数，运行所述插件，并得到运行结果。

2.根据权利要求1所述的代码实现方法，其特征在于，所述方法还包括：

当所述插件不再使用或需要更新时，卸载本地的所述插件。

3.根据权利要求1或2所述的代码实现方法，其特征在于，所述针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件包括：

根据需要执行的任务创建对应的工作空间；

配置所述工作空间的环境参数；

配置所述工作空间中需要使用的一个或多个插件以及每个插件的固定参数。

4.根据权利要求1至3任一项所述的代码实现方法，其特征在于，每个所述插件为独立的代码包，代码的入口文件对外暴露两个接口，其中第一接口用于管理所述插件的固定参数，提供所述插件在不同业务场景的可选配置；第二接口用于获取上游插件的处理结果数据，并在对所述数据做对应的业务处理后传递给下游插件。

5.根据权利要求1至4任一项所述的代码实现方法，其特征在于，每个所述插件附带一个信息文件，包含插件名、插件作者、插件文档地址、插件版本、插件扩展点、插件依赖信息。

6.根据权利要求5所述的代码实现方法，其特征在于，所述将所述工作空间中配置的所述插件安装到本地包括：

安装指定版本的所述插件到插件缓存目录；

在所述插件安装完成后，读取所述插件的所述信息文件获取所述插件依赖信息，并根据所述插件依赖信息安装所述插件的所有依赖包。

7.根据权利要求5所述的代码实现方法，其特征在于，所述加载所述插件包括：

根据所述插件的所述信息文件，将所述插件注册到对应的扩展点；

加载所述插件对应的入口文件，将所述插件引入到所述工作空间。

8.根据权利要求1至7任一项所述的代码实现方法，其特征在于，每个所述插件单独实现一个业务功能，提供用户交互界面，处理与用户之间的交互操作。

9.一种代码实现系统，其特征在于，所述系统包括：

配置模块，用于针对不同任务分别配置指定工作空间的环境参数和所述工作空间中使用的插件；

安装模块，用于将所述工作空间中配置的所述插件安装到本地；

加载模块，用于当所述工作空间执行所述任务需要使用所述插件时，加载所述插件；

运行模块，用于使用所述工作空间的所述环境参数，运行所述插件，并得到运行结果。

10.一种电子装置，其特征在于，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代码实现程序，所述代码实现程序被所述处理器执行时实现如权利要求1至8中任一项所述的代码实现方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有代码实现程序，所述代码实现程序被处理器执行时实现如权利要求1至8中任一项所述的代码实现方法。

Images