技术干货 | 高生产力Web应用研发平台建设与探索

编者按：业内在可视化建站的相关探索工作已经逐步从单纯的面向业务（运营/产品）的可视化搭建系统转向面向研发的Low Code研发平台。更进一步的，即是对高生产力应用平台服务（HPaPaaS）的探索，本文从理论推导及工程实现两个层面介绍我们在这一领域所做的相关工作。

1.

前言 - 领域背景及现状

在过去的数年间，各类可视化建站平台通过实现对前端工程师的部分技术迁移，深刻的改变了特定场景下的页面生产方式，并释放了巨大的研发生产力。在刚刚过去不久的双11就是其中一个例子 —— 数以千计的、形式丰富的各类会场、营销页面的背后是以可视化建站、代码智能生成为核心技术的阿里前端研发体系生产力的一个呈现。

虽然可视化建站相关技术在过去取得了非常丰硕的业务成果，业内也涌现了许多优秀的产品，但其所面临的一些困境也逐渐呈现出来，并且成为制约其进一步发展的关键因素。

从去年Gartner发布了 Low-Code/No-Code? HPaPaaS? Here's What Everybody Is Missing 之后，业内在可视化建站的相关探索工作已经逐步从单纯的面向业务（运营/产品）的可视化搭建系统转向面向研发的Low Code研发平台。更进一步的，即是对高生产力应用平台服务（HPaPaaS）的探索。这背后的一个基本共识可以简单归结为对逻辑二次开发能力的集成上。

本文的核心主题即是介绍我们在该领域（HPaPaaS）的相关探索工作 —— 余下章节首先会重点介绍对问题域的抽象及针对该问题域所制定的目标的推导过程，然后在《理论基础》一章中介绍用于指导系统实现的设计原则及其理论基础。在《工程实现》一章中我们会介绍整个研发体系关键模块的设计思路及其实现。最后会在本文的结尾对后续的产品技术规划作一个简要的介绍。

出于对历史称谓的继承，下文提及的“可视化研发平台”在概念上与“高生产力应用研发平台”基本一致。

2.

动机与相关工作

问题域 - 逻辑的二次开发与规模化

我们尝试从以下三个场景来介绍可视化建站目前所面临的一些困境，然后从中抽象出我们的核心动机：

1. 1688微供市场频道页

2. 普惠营销活动

3. 各类中后台mis页面

如下图展示的1688微供市场频道页是一个较为典型的电商h5页面:

其页面结构自上而下可以作如下分解 - 一级类目导航、轮播图、二级类目/标签筛选导航、商品列表。该页面产品化的开发方案会很自然的将这四部分沉淀为通用组件（component），然后在一个页面容器（page）当中完成各组件的交互（点击筛选项 => 刷新页面；下拉列表页 => 切换到特定的Tab）。

对于没有提供事件或其它通信机制的可视化搭建平台而言，上面这个页面的搭建会变得比较棘手（相较于Pro Code方式的开发几乎是没有优势的）。基于此，一些可视化搭建系统开始在运行时框架层面提供组件间的通信机制（例如上述场景中，二级筛选导航在Tab切换的时候会发布一个事件，然后商品列表组件监听该事件并作相应的更新处理）。但这会带来另外一个问题，即相应组件

耦合在了一起，失去了一定程度的通用性。

我们再来看另外两个例子：

星云互动营销在过去的时间里沉淀了多种概率抽奖及其变体的活动类型，虽然在样式呈现上各不相同，但其核心的抽奖交互逻辑都是类似的，大体上可以由一个相同的流程图来进行描述。与营销活动类似，中后台mis页面也存在这样的例子，最典型的就是如下的列表页：

这个页面主要包括三个模块：筛选区、列表、操作弹窗。虽然模块可以进行这样的划分，但其包含的逻辑却难以枚举 ——这使得试图提供一个类似数据字典一样的组件来渲染自定义表单的方式来实现这种类型的mis页面变得更为复杂（虽然如此，下一章相关工作中我们会提到，这一思路依然有一些出色的尝试，例如amis）。

上面三个例子基本可以引出目前可视化搭建平台所遇到的一个问题 —— 即如何集成逻辑的编写能力。针对这一问题，一个基础的解决方案是在搭建时提供事件的动态绑定能力。这确实可以解决一部分问题 —— 但是由于在应用模型/运行时框架层面缺少规范化的处理，一方面使得开发者对于不同系统的实现存在额外的学习成本，另一方面则使得逻辑部分的实现缺少复用性。基于此，我们对可视化研发平台的问题域进行了进一步的抽象，最终概括如下：

当前可视化研发平台的一个核心问题是对逻辑二次开发能力的集成及规模化支持。

对于集成逻辑二次开发能力这一点，目前业内已有基本的共识。我们这里进一步强调的是应对规模化的问题 —— 当面对大规模复杂的状态流时，我们可以想象在单个页面逻辑中可能会有上百行的代码 —— 由于逻辑间的调用关系、store的结构无法被清楚的展示给开发者，维护成本将会大大增加。本章余下部分会介绍业内的相关探索工作，并由此推导出我们针对上述问题域所制定的目标。

相关工作

传统的可视化建站（无/低逻辑编写能力）业内已有非常多的实践，本文的附录部分列举了其中部分具有一定代表性的产品或技术解决方案。作为HPaPaaS的探路者，本章我们会重点介绍云凤蝶、飞冰、lugia、amis(百度)的设计思想及其主要特性，以及对我们设计原则有重要影响的设计稿转代码的imgcook。

云凤蝶

云凤蝶今年开始转向中后台研发平台的建设工作。其核心设计思想可以概括为对应用生产流程进行分层设计（流水线）并完成各层间产物的自动化（no code）/半自动化（lowcode）推导工作。

飞冰（Iceland）

飞冰的官方定位是基于物料的一站式可视化源码研发工作台，其主要的特性有以下两点：

1. 完备且集成了GUI的CLI

2. 丰富的物料库

通过飞冰提供的GUI与物料库，开发者可以通过配置化的方式快速构建应用的初始骨架，然后在本地的集成开发环境当中实现应用的布局样式与业务逻辑。

lugia

lugia 的核心目标是重塑前端工作流：

amis

前端低代码框架，通过 JSON 配置生成各种后台页面。

其主要特性是提供一个 json schema 来生成mis页面。

imgcook

imgcook 当前主要提供设计稿生成各种DSL代码（Vue, React, 小程序, h5）的能力。除此之外，还支持对节点的样式修正、类名称修正，以及属性的绑定、方法的声明。如果将导出的结点替换为自定义组件，那么从技术层面imgcook已经可以完成视图层排版布局的自动化工作了。

小结

本章的最后我们尝试对以上产品技术方案从业务场景、核心特性、所处阶段及主要挑战四个维度进行概括如下：

名称	业务场景	Pro/Low Code	核心特性	当前阶段	主要挑战
云凤蝶	中后台	Low Code	领域分层	原型开发	工程实现
飞冰	中后台	Pro Code	GUI/物料库	已发布	门槛
lugia	中后台	Pro Code	重塑工作流	原型	理论支持
金蝉	中后台	Low Code	完备逻辑编写	已发布	规模化
amis	中后台	Low Code	json2code	已发布	规模化

3.

目标与当前进展

目标 - 构建低门槛、高效率、

多场景的 Web 应用研发平台

我们的原始目标是构建高生产力应用平台服务（HPaPaaS），但是目前业内对这一概念还没有一个较为标准化的认识。因此从本章第一节给出的问题域出发，结合第二节业内的相关工作，我们将这一原始目标拆解为三个相对具体的维度作为后续系统设计及工程实现的主要切入点，整体可以概括如下：构建低门槛、高效率、多场景的 Web 应用研发平台。

当前进展 - 初步实现具备完全

逻辑编写能力的可视化研发引擎

这里是我们对于典型mis列表页的一个搭建示例。

为了展示完整的布局搭建及逻辑编写能力，我们演示了如何从一个空白项目搭建上述示例页面的全过程，原始搭建时长约在6分钟左右。如果基于模板来进行创建，该类型页面基本上可以通过接近零代码的方式进行生产。

另一方面，基于我们研发引擎提供的能力，开发者可以操作页面中所有组件的状态及其暴露的方法/事件。更进一步地，基于我们的应用模型，开发者可以实现逻辑层面的复用以应对规模化的问题。下一章我们会介绍其中的设计原则及其理论基础 —— 其中的关键概念“差量更新”是对研发效率度量标准的一个尝试性探索。

虽然基于当前的开发方式，开发者已经不需要直接对产物进行修改即可完成完备的逻辑开发工作，我们依然可以导出高度语义化的工程项目文件。

4.

理论基础

差量更新 - 研发效率的度量标准

研发效率

在不考虑所投入生产资料（例如不同的工程师、不同的研发体系等）的前提下，研发效率 de 可以被描述为产能 da 与研发周期 T 之比（式1.1）：

接下来我们需要对 da 进行分解。

生产模式及其应用模型

应当注意到应用模型与领域模型的区别 - 前者是为生产效率服务的，因此是“业务无关的”。举个例子来说 —— 营销C端的应用模型属于前者，而营销活动则属于后者。

我们需要一些基础的假设来为应用模型的构建提供原则性的指导。目前可以得到的一个基本共识是 —— 希望业务的开发者只关注业务逻辑的实现。基于这样一个共识，我们可以推导出高生产效率的一个假设：

对于同一个开发者以及同一个需求迭代，业务逻辑的实现在整体研发工程中的占比越高，则该次迭代的生产效率越高。

基于这样一个基础假设，我们提出基于“差量更新”的应用生产模式，即（式1.2）：

与之对应的是全量更新（式1.3）：

差量更新生产模式的语义化表述为 —— 当一个应用出现迭代需求时，可由对当前应用状态的一个差量更新 delta(Modular) 实现。delta 是一系列研发工程工具的集合（可以近似理解为集成开发环境），而 Modular 是开发者需要实现的业务迭代所对应的增量模块。为了做到这一点，我们需要找到应用最细粒度的基础模块及其正交化分解，即（式1.4）：

其中 m 即为应用的一个基础模块，而一个应用的状态空间则由该应用正交化的基础模块集合所决定。正交化可以简单理解为模块中的任何一个属性都不能通过其它模块经过计算所得出。该式即为差量更新生产模式所对应的应用模型。

Modular 可以拆分为两部分（式1.5），

即当原有状态空间无法包含新的迭代逻辑时，需要扩展应用的基础模块集合。

对基础模块的更新 - 这一操作需要注意保持更新后的基础模块的原子性。

因此对于应用状态空间的扩展有两种方式：

1. 基础模块的更新

2. 基础模块类型的扩展

再参考式1.2，开发者需要关注两部分的工作 —— 基础模块的维护（更新及扩展）、合成器（compose）。

研发效率最大化

研发效率最大化基本上等价于完全的差量更新 —— 通俗地讲就是没有任何冗余的代码，所有逻辑都是对业务流程的表达。然而完全的差量更新很可能只存在于理想化的场景，其困难在于 —— 对于实践中大部分的工程，我们不一定能够找到并始终维护应用的一组正交基础模块集合。而这部分工作依赖于业务开发者对于问题域的架构能力。另一方面，缺乏基础模块/合成器的标准规范与相应的工程支持 —— 而这正是研发平台所要解决的核心问题。

设计原则 - 

分离状态逻辑与UI组件无状态化

这里我们主要强调以下一些观点：应用模型是特定业务域在语言之上的一层抽象 —— 通过给出特定的约束，丧失一定程度的通用性为代价来提高应用域的物料复用性，以此来提高生产效率。

以此观点来看， react 提高生产效率并不是说作为框架，而是因为其提出了一套组件规范（react只是这种组件规范的一种实现）。

当超出应用模型的理想应用场景时，其丧失的通用性将会带来复杂度的指数级增长。这对于 react 这类组件化框架而言，就是大规模状态逻辑共享与复用的场景。

因此需要引入额外的模型来处理这部分的复杂度，那即是 redux 等状态管理技术。

而研发引擎，与特定类型的游戏引擎类似，是基于特定应用模型的一系列规范（如组件、状态逻辑、合成方式）辅助开发者实现特定应用生产的研发工具集合。

当前研发引擎的核心挑战，即是找到这样一个具备更普遍通用性（多场景）且支持细粒度状态逻辑复用（规模化）的应用模型。

而度量这样一个应用模型的标准即是其是否支持该问题域的差量更新

现有的以 React, Vue 为主要代表的前端框架，并不能支持完全的差量更新（这被认为是 React Hooks 的其中一个动机）。我们认为，无论是采用 hooks 或者其他的逻辑复用方式，为了实现差量更新，需要做以下两个工作：

1. 分离状态逻辑与UI组件无状态化

2. 提供状态逻辑的细粒度复用

在相关工作中提及的以imgcook为代表的设计稿转代码相关技术的支持下，分离状态逻辑与UI组件无状态化还可以为我们研发平台在工程层面的实现带来种种便利。

站在前人的肩膀上 -Dan Abramov 在2015年提出的关于展示组件（Presentational）和容器组件（Container）的相关概念，以及基于容器组件来完成与 Redux 状态管理库连接的技术实现方案（Dan Abramov's original article describing the concept ofpresentational and container components），对我们今天的工作仍然启发良多。

5.

工程实现

应用模型与运行时框架

这一层是整个研发体系大厦的实质性基础，而指导我们实现这一基础的理论即是上一章提到的 “分离状态逻辑与UI组件无状态化” 。基于此我们设计并实现了如下的状态管理方案 MarkII：

这个模型遵循目前主流的 Store 规范，并提供 Store 模块的合成机制 —— 考虑到团队主要技术栈为Vue，我们在 Api 的实现上遵循的是Vuex 的标准；但区别于 Vuex 的状态映射方式，MarkII在状态/视图合成的方式上遵循 Redux 标准；另外，我们专门提供了一个 context 属性用来声明 Store 内部的各种常量、工具方法及三方库的注入，以及运行时相关的变量方法。

我们会在本章的末尾进一步介绍这样设计的原因。

上文已经提到 —— 与 Redux 一样， MarkII 的实现并不依赖于特定的视图层框架，目前我们实现了与 Vue 组件的合成。其实现思路是为目标组件创建一个HOC，并基于开发者声明的 mapStateToProps 与 mapActionToProps 两个函数：

1. 对 state 的合成， 首先映射到 HOC 的 data 中，再透传给目标组件。

2. 对 action 的合成，则直接透传给目标组件的 props。

然后在 HOC create 的阶段初始化 store 的 context —— 是的，核心工作就这么多。

现在我们可以通过如下方式进行 Store/UI 的合成：

在本章的最后，我们介绍一下：

为什么需要 MarkII ，而不在 Redux 或 Vuex 上进行扩展。

我们有以下几个主要考虑因素：

1. 视图框架无关

2. 状态逻辑的实现与UI解耦

3. 提供 Store 的合成机制

首先的一点是希望做到视图框架无关；同时，基于我们的基本设计原则 —— 分离状态逻辑与UI组件无状态化，我们不建议使用 Vuex 嵌入到组件内部的状态合成方式。以上两点是没有采用 Vuex 的主要因素。

而对于 Redux ，更多考虑的是后续为上层研发引擎服务可能需要做一些定制性的扩展（例如 context）所带来的成本。

系统架构

整个研发体系自上而下可以分为以下五层：

业务域 - 应用层

物料库 - 可复用物料层

HPA 研发平台

应用模型及其运行时框架

基础设施与服务

基于上一章介绍的应用模型，下一章我们会重点介绍研发平台的核心模块 —— 研发引擎的关键实现逻辑。从整体结构性层面我们需要强调的一点是 —— 研发引擎的设计是基于特定的应用模型的。研发引擎产物的适用场景及其为开发者提升效率的程度都依赖于其下的应用模型。

研发引擎

基于 MarkII 的研发规范，我们需要实现以下三部分的工作：

1. store - 实现状态逻辑

2. layout - 实现页面组件布局排版

3. page - 状态逻辑与UI合成

我们希望研发引擎可以帮助开发者解决掉 layout 及状态逻辑与UI合成两部分工作。基于此，需要设计一个中间产物 PageSchema 用来描述页面的布局排版结构及组件的属性配置数据，并且该中间产物可以被解析为对应的 layout 及 mapper。以下是PageSchema 的一个实例：

以上结构会被解析为如下的 layout.vue 与page.js：

整体交互/数据流

现在我们可以把研发引擎的整体交互及数据流给出来了。

6. 

远景 - 原型即产品与研发革命

从各方面的趋势来看，前端工程师的定位及Web应用研发流程在可预见的未来会发生深刻的变化。以终局的角度来看，我们希望可以消除从领域专家到终端产品实现过程的产品技术鸿沟。虽然这一工作涉及到软件工程的一些基础性主题，但其对生产效率带来的提升却是明显的。基于对目前形势的判断，我们规划将按照如下三个阶段来不断逼近这一最终的目标：

Stage1. 验证应用模型及系统架构 - 完备且高效的逻辑编写能力

Stage2. 全场景全流程的高生产力应用研发平台 - 跨端、Serverless 集成

Stage3. 原型即产品 - 重塑Web应用生产工作流

"我们对此充满敬畏之心，同时也倍感兴奋。"

7. 

附录

术语表

● 可视化搭建/建站 - 提供可视化/配置化的网页搭建能力

● 研发体系 - 从研发投入阶段到终端应用产出过程中所使用到的一些列的研发工具/平台的集合

● 研发平台 - 服务于开发者的应用生产/管理平台

● 研发引擎 - 辅助开发者完成应用生产的关键性工具，通常是研发平台的核心模块

● HPaPaaS - 高生产力应用平台服务

（Jason Bloomberg, Gartner, 2018/7/30）

● Low/Pro/NoCode - 对研发体系/建站平台的一种划分标准

● 状态逻辑 - stateful logic, react hooks

可视化建站相关产品

● Google App Maker

● MS Power Apps

● Outsystems

● Bubble

● Framer

● AppSheet

● FileMaker

● Tadabase

● Pagedraw

● ForestAdmin

● AIMaker

● Relim

● 简道云

● 乐高（阿里）

● 宜搭

编辑 | 钱维

推荐阅读

-