作者：京东零售 李春丽

作为一个技术架构师，不仅仅要紧跟行业技术趋势，还要结合研发团队现状及痛点，探索新的交付方案。在日常中，你是否遇到如下问题 “ 业务需求排期长研发是瓶颈；非研发角色感受不到研发技改提效的变化；引入ISV 团队又担心质量和安全，培训周期长“等等，基于此我们探索了一种新的技术体系及交付方案来解决如上问题。

(资料图片)

嗨，大家都知道软件研发需要许多角色共同协作，包括客户、产品经理、研发工程师、测试人员、实施运营团队等等。在这众多角色中，研发工程师的人数占比最高，但是研发资源毕竟有限，随着需求量不断增加，在项目中还会听到如下吐槽：

1、研发团队排期瓶颈，非研发角色感受不到研发技改提效的变化。

2、引入ISV 团队又担心质量和安全问题，而且培训成本高、周期长，在核心复杂系统中，不敢也无法短时间大规模引入。

不过，如果有一种方法能够实现生态化交付和全民开发的愿景，那就可以解决上述问题了！这种方法可以让所有角色，无论是技术还是非技术的，以安全、更简单的方式参与进来。

这样一来，就可以在不增加团队人数的情况下，提高团队的吞吐量，实现更高效的需求交付，是不是很奇妙呢？

为了达到生态化交付和全民开发的愿景，我们需要解决如下几个问题？

1、如何让非技术角色实现研发的交付？

2、如何让全民开发者完整实现一个需求闭环，而非仅仅实现其中一部分需求？

3、如何解决交付中核心系统安全问题？

我们带这几个问题看下解决方案。在讲技术方案之前，我们先站在客户角度，从整体看一下，一个系统的需求都来自哪里？而我们都知道比起从0-1新做一个系统，二次扩展类需求更加复杂，我们今天就以二次扩展类需求入手和大家一起分享下，在京东智能供应链Y做的一些实践。

如上图就是任意一个系统中二次扩展类需求分类的最大集合，主要有8类：API类、参数类、模版类，界面类、流程类、规则类及数据库类。

1、API类：主要是新增API和在原有API的扩展，例如，原有API上新增一些属性。

2、模版类：主要是新增一个模版。例如，制作一类新的合同模版或问卷调研，各部门填报填写。

3、参数类：主要是新增KV类的参数。例如，新增“是否包括自营商品“参数，并让这些参数在某些逻辑中起到作用。

4、UI类：主要是新增菜单、按钮、布局、图表、校验规则等。例如新增一个外呼按钮，并调用外呼系统 接口。

5、流程类：在原有流程节点中新增新的节点。

6、规则类：在原有的规则前、后等，新增新的规则。

7、数据库类：在原有表中增加新的属性，或者新增一个子表。

8、最后还有一类其他：无法划分为某一类，需要复杂的逻辑处理实现。例如 数据重新聚合与逻辑运算

我们就基于这些研发的需求类型，设计一套技术体系，实现生态化交付和全民开发的愿景。

我们把软件系统分成三层，建立完整的全链路扩展技术体系，在把这些能力通过零低代码手段把他们进行打通、包装和开放，就可以实现屏蔽源代码的情况下，对系统进行安全、简单、闭环的二次增强，进而达到全民开发的目标。具体包括：

1、界面层：该层扩展主要手段就是零低代码技术。

2、接口层：该层扩展主要手段就是依靠不同模型之前的映射来解决，而模型的扩展就可以依靠对象扩展来解决。

3、服务层：该层扩展主要依靠流程、规则引擎来实现，这个业界有很多开源工具，例如activity和drools等。另外还有很多场景是复杂的逻辑变更，这个可以依靠插件、事件驱动模式来实现。

4、模型层：该层扩展主要手段就是依靠元数据驱动，通过依赖元数据对象，而非底层物理数据库。

以上能力，在通过最后零代码技术的加持和封装，实现可视化配置，形成一个工作空间，在对工作空间进行分角色授权，让不同角色以熟悉的语言进行操作，这样就可以实现生态化交付和全民开发的愿景。

所以说扩展的技术体系不是一个单一的解决方案，它需要零低代码、插件、业务事件、元数据驱动、流程规则引擎等技术共同协作才可以。而难点是这几个技术需要互相搭配好，实现扩展的互认，例如我们在对象模型扩展中增加了一个属性，这个属性需要在界面展示、需要在接口中透传、需要在规则中校验，这就需要做好顶层架构设计。

我们通过几个案例来描述，它需要和可以实现哪些能力？

需求描述：基于业务变化，一个核心系统，需新增 “渠道类型” 这个属性，改动涉及：

1、数据模型变化（技术上：数据库字段变化）

2、后端服务及规则变化（技术上：接口变化、对象变化、判断规则变化等）、

3、展现界面变化（技术上：UI 界面增加带数据权限的查询条件、表格新列及图表增加等），

也就是需要软件不同层次的进行变化。通常，这些特别技术的需求变更，只能技术排期做，但是通过这种新方式。产品经理/客户就可以在无需等待，7 分钟内，全程零代码的模式下完成。

1、在对象扩展中，增加新的属性。

2、在规则引擎中，基于新的属性，编排增加新的校验。

3、在界面扩展中，把在对象扩展中的新列拖拽出来，展示为查询条件，并制作一个新的饼状图展示到界面。

通过这个案例，也就是说我们可以把黑盒的研发工作，安全、高效的交付给其非研发角色自助完成，提升交付效率，减低沟通成本。另外还有一点值得一提，这种方式也让非技术人员，可以直观的感受到技术提效的变化。

需求描述：基于业务变化，一个核心系统，需要与客服系统集成，实现对某类特殊业务的客服外呼，改动涉及：

1、新增一个外呼按钮

2、新增前端规则校验，只有履约数据滞留2天的才需要进行客服介入。

3、调用外呼接口，组装数据增加复杂逻辑并传递。

4、发送邮件通知相关角色。

同样，这些也是特别技术的需求变更，原来只能原厂技术开发来排期做，但是通过这种新方式。客户IT或ISV，就可以在不触及代码的情况下，通过统一平台一站式完成需求的变更。

1、在界面层中，通过零低代码手段完成按钮新增。

2、在界面层中，通过零低代码手段完成规则校验的新增。

3、在服务层中，通过插件方式，实现代码逻辑处理，并调用外呼接口。

4、在服务层中，通过事件订阅方式，监听外呼状态，配置邮件模版，实现邮件自动发送。

通过这个案例，我们可以看出来，业务需求具有多变性，不能仅仅依靠一种手段完成扩展，需要多种方式进行搭配，才能实现大幅度提效。

其实零低代码、插件、业务事件、元数据驱动、流程规则引擎等技术在行业中并不是一个新事物，而这些技术可以互相搭配，实现完美集成和互认，让用户在一个平台针对不同业务的场景使用合适的技术，完成需求的自助化，是个难点。它不仅仅需要平台技术，还需要对业务系统需要合理的抽象、抽取。

最后，我们在回过头看看最开始的技术挑战。是不是都解决了呢？

1、如何让非技术角色实现研发的交付？答：通过零低代码模式进行封装和开放。

2、如何让全民开发者完整实现一个需求闭环，而非仅仅实现其中一部分需求？答：需要全链路开放和打通，并不仅局限一种技术手段。

3、如何解决交付中核心系统安全问题？答：屏蔽源代码的完整扩展体系。