最近 1-2 年来低代码（LowCode）应用越来越多，从一些长尾的宜搭应用，到后台的管理系统，再到一些复杂的业务系统都开始使用低代码，低代码显著的降低了部分应用研发的门槛，但是依然存在一部分应用一直拒绝低代码，分析原因主要是组件复杂、页面逻辑多、定制化强等等。但在降本提效、分层用工、对外服务的大趋势下，一些通用的能力如框架、布局、页面集成、配置化、扩展开发使用低代码的效率会有显著的提升，当然部分能力 ProCode 依然需要，因此 ProCode 和 低代码的混合研发是大势所趋。

链路篇

混合研发的现状

当前大多数应用 ProCode 和 LowCode 是完全不同的研发模式，项目初始化、研发和发布都是两套并行的方案，最多可以做到 ProCode 的组件可以通过VC 组件（中后台低代码组件，符合《低代码引擎物料协议规范》，可以在低代码页面中使用的组件）的形式发布到低代码平台上。LowCode 的主要研发流程如下：

《低代码引擎物料协议规范》链接https://lowcode-engine.cn/material。

存在几个问题：

1.所有的VC组件和 LowCode 组件都是一个个的包，需要进行复杂的包管理，繁琐而容易出错

2.缺少多分支能力，VC 组件独立在项目外不受管理，页面和 LowCode 组件并行开发时没有好的方案

3.ProCode 组件和 LowCode 组件无法互相引用（一般能做到 LowCode 组件引用 ProCode 组件，但是版本管理带来新的问题）

当然可以做一些优化，例如将所有的 VC 组件写在一起，作为一个大的包管理，LowCode 组件仅做一些简单的组装，更多的集成在页面上做。但是 VC 组件本身的成本比较高，同时 VC 包同应用不具备关联，有并发需求更是雪上加霜。

理想的混合研发链路

理想的混合研发链路，需要解决上面面临的几个问题：

• 支持多分支，同时管理 ProCode 分支和 LowCode 分支
• 一个应用的页面、模块和组件无论是 ProCode 还是 LowCode 可以统一的管理和集成
• 一体化的打包构建和发布

一个理想的研发链路应该如下：

一些说明：

• 此处混合研发应用是一种混合应用，无所谓 LowCode 应用还是 ProCode 应用
• 应用同 gitLab 仓库绑定，具备创建迭代的能力，同时创建 ProCode 分支和 LowCode 分支
• 研发过程中无论页面还是组件都可以相互引用
• ProCode 的分支通过 gitLabe 合并，LowCode 的分支通过平台合并
• 最终统一打包发布

这个方案需要解决的问题比较多，短期内我们需要一种比较轻量的混合研发模式。

一种轻量的混合研发链路

低代码平台的优势在于可以快速复用一些不需要反复写代码的工作，比如框架、菜单配置和布局布局等通过平台上配置就可以完成的工作，也就是说应用集成和页面集成在低代码平台上完成：

• 应用集成，包括框架的引入和改造、菜单权限的配置和一些通用能力（水印、数据防丢失、监控等等）的引入
• 页面集成，包括页面的布局、模块的组装和一些胶水代码（组件的交互、状态的管理等等）
• 组件的统一管理，ProCode 组件和 LowCode 组件都按照统一的项目内组件管理

对上面理想的混合研发链路进行简化可以得出一种轻量的混合研发链路：

比起理想的混合研发链路，这里主要在两方面进行了简化：

• 不考虑 ProCode 页面的研发
• 不考虑 ProCode 页面和组件引用 LowCode 组件
• 分支的合并能力可以不在平台上进行，不影响构建物的打包和发布
  图中的 ProCode 项目组件在发布前需要手工 merge，LowCode 的组件和页面需要在平台上进行 Merge

混合研发链路的节奏

当前阿里巴巴企业智能事业部内，已有多个比较复杂的应用已经在采用 VC 组件包 + 低代码平台集成的方案，低代码平台多分支能力和项目内组件也都在研发，但是整个流程全部完成还需要至少一年的时间，具体的节奏如下：

页面研发篇

在前面主要关注的链路的问题，主要工作在平台和研发链路的治理，但是日常研发中我们前端更多的在页面、模块和组件的研发中摸爬滚打，这部分更加关注这三者具体的研发。

页面研发现状

现在的 ProCode 应用和 LowCode 应用还未整合，当前页面、模块和组件的关系非常清晰：

这种形态下 ProCode 应用和低代码应用各不相关，但是已经渐渐不能满足我们业务的需求：

• 工作台模式下的多应用的集成牵扯到各种不同的系统
• 跟钉钉融合情况下，酷应用、协同卡片要求现有应用满足多个端的要求，有些端更适合搭建（LowCode）

简单的混合

当然在实际的使用中 ProCode 的组件也会以 VC 组件的形式注入到 LowCode 的应用中，但是很少 ProCode 应用的项目内组件直接可以在 LowCode 应用中使用。

进一步我们如果实现可以在 ProCode 应用中可以引入 LowCode 的模块或者组件就可以形成一种简单的混合方式：

这种方式下可以实现组件在 ProCode 应用和 LowCode 应用之间的互相集成，可以解决一部分工作台集成、跨端融合的问题，但是当一个应用有不同类型的页面（数据页面、表单、详情、定制页面）时，要么分别创建 ProCode 应用和 LowCode 应用再做集成，要么以 iframe 的形式嵌入，仍然存在解决不了的问题。

理想的页面研发方案

而理想的页面研发方案应该满足几个条件：

• 应用上不做 ProCode 应用和 LowCode 应用的区分
• 页面上不区分 ProCode 还是 LowCode 的组件和模块，都有一致的引入方式。ProCode 的模块/组件 和 LowCode 的模块和组件在研发态有区分，但是在消费态有一致的表现
• 页面、模块类型和组件可以让用户自己决定是用 ProCode 还是 LowCode

因此理想的页面研发方案应该是这样的：

从上而下的集成角度来看应用、页面、模块、组件的概念是一样的：

• 从平台视角，所有的应用是一样的，既可以 ProCode 开发页面，也可以 LowCode 开发页面
• 从应用的视角，所有的页面都一样，有一样的元数据，可以接入一样的通用能力（水印、数据防丢失、监控告警等），仅仅是开发模式不一样
• 从页面的视角来看，所有的模块、组件都是项目内组件，有相同的引入方式

但是自下而上的研发视角来看 LowCode 和 ProCode 又是不一样的：

• 所有的 ProCode 页面、模块和组件要在一个 GitLab 的仓库下维护，不同的迭代要拉取不同的分支
• 所有的 LowCode 页面、模块和组件直接在低代码平台上维护，不同的迭代要生成大的版本

我们前端一直说 “把复杂的留给自己，把简单的带给用户”，站在应用生产平台的角度是一样的，这种方案的集成成本会大大降低，各个环节都可以做成配置化和支持扩展开发的能力，可以有效的降本提效，也利于后续交给 isv 和 合作伙伴。

更多的思考

我们是否可以再进一步，不再有 ProCode 的页面，所有的页面都是在 LowCode 平台上创建，我们要做的仅仅页面的拆解和填空，拆解出来的模块约束好输入（状态、mock 数据）和输出（UI 表现），按照工业领域的 BOM （物料清单）的方式来生产页面，很多模块和组件可以交给不同层次的人员来研发，更低的成本，更高的质量不再是梦想。