提效是企业级前端框架非常重要的目标之一，如何借助框架和工具让 1 个人可以做 10 个人的事情，要做 10 倍的提效，则要做一些破局的事情。

蚂蚁尝试在写代码（Pro Code）的基础上做可视化辅助编程（ Visual Assist Programming ），借助和框架、平台、组件和物料市场的互补，以及用类微前端的架构方案来提供插件机制，以此来提升开发者的研发效率并降低上手门槛。

以下内容根据蚂蚁金服高级技术专家陈成在 GMTC 深圳 2019 全球大前端技术大会上的演讲整理而成。

以下为正文。

我主要分为以下几个方面来讲，可视化编程的优势、可视化编程在蚂蚁的实践、可视化原理的剖析、可视化破局的，最后展望一下未来。

可视化编程的优势

近年来，可视化搭建系统越来越多的被提及，一般来说，可视化搭建系统分为两类：无代码（ NO CODE） 和低代码（ LOW CODE），这两种的区别是，前者完全不需要写代码，后者需要写部分代码，整体通过拖拽的方式生成。在阿里内部的可视化编程系统有 30 多个，分别解决不同垂直领域的问题。在业界，可视化的应用也越来越多。为什么可视化会火起来？可视化有哪些优势？

1.可视化搭建的优势

可视化搭建优势主要分为以下几点：

• 所见即所得：通过拖拽的方式生成页面，再通过一些配置就能生成网站；
• 增删改查，十倍提效：针对垂直领域，可视化就可以进行深入的分装，然后针对常见的增删改查，做到十倍提效也是可能的事情；（搭建系统一般针对垂直领域）
• 一站式研发：一站式研发通常会管前端的代码，还会管后端代码以及一些服务，开发完了之后还会一键发布上线，处理些回滚等；
• 专业门槛低：不需要很强的专业技能，也能完成这部分工作；
• 技术收敛：自己开发网站的时候会去选择和对比，这个平台就会做一个技术收敛，节省成本。

既然可视化编程这么好，以后是不是就可以不用写代码了？

2. 写代码的优势

虽然可视化编程带来了很多便利，但是写大量代码（Pro Code）的优势也很明显，可以对可视化编程做一些补充。

• 针对可视化编程，写代码的优势在于精确表达，极致体验；
• 搭建系统针对垂直领域的分装，以此来达到提效的目的，写代码能在分装的基础上更好的实现提效的目的，及产品增值业务；
• 很多产品不仅有 PC 端、移动端，代码涉及到共享和复用，一站式研发并不能很好的满足部署平台兼容性；
• 前端技术日新月异，如果把技术分装在平台里，平台更新迭代可能不会像前端技术更新迭代那么快，而很多业务又涉及到更新和迭代，写代码的优势更加凸显。

分析了可视化系统的优势和写代码的优势，接下来我们改怎么去选择呢？

答案显而易见，写代码为主可视化功能为辅。我们应该基于 Pro Code（写很多代码） 去做 VAP（可视化辅助编程）。

基于 Pro Code 去做可视化辅助编程，社区已经有很多先行者。

Pro Code 的痛点又是什么？

• 文档链路长；
• 门槛高；
• 命令行不够友好；
• 非一站式研发，流程割裂；
• 研发效率不够高等。

可视化辅助编程在蚂蚁的实践

1. 可视化辅助编程在蚂蚁的实践

基于以上的 Pro Code 的痛点，蚂蚁开发了一个可视化辅助编程工具 Umi UI。主要包括两部分，一是流程，二是功能。

流程是解决从创建开始到最后部署、发布之后等的一系列问题。在社区上还好，如果你要把工具推给内部开发者使用，就必然要解决一些流程上的问题。

功能包含：

- Dashboard；

• 基础：配置管理、任务管理；
• 进阶：资产市场、数据管理；
• 功能闭环：Terminal；
• 运行态能力：Mini 气泡。

来看一个例子，创建项目。

创建项目其实很简单，即脚手架可视化。

外部创建流程：更新脚手架代码 —>创建项目 —>安装依赖 —>打开项目 —>出错重试。

内部流程相对外部会复杂一点，会走单独的创建、部署和发布流程。

任务管理是基础命令的可视化形式。如：启动、构建、lint、test 等。

配置管理其实是打通文档和工具的一个环节。做配置时就不需要再返回查询文档，就能看到一些具体的选项。

资产管理是可视化编程里面一个比较重要的环节，通过资产管理这个工具可以做一个真正的提效。资产管理包含区块和模板，现在有 antd 的 400 多个 DEMO 区块，以及 antd-pro 数十个模板。通过资产管理，我们把模板都整合进来，这样就可以快速的创建页面。

前面的资产管理 1 是有模板的情况，那么没有模板的情况又是什么样呢？我们以资产管理 2 为例。

没有模板的情况下，我们如何创建页面？

首先，我们先创建一个空的模板，然后选择布局，再在布局里面添加功能区块；

实现这些配置不需要单独的页面去做，如图所示，页面的右下角有一个气泡，通过 Mini 气泡去添加资产，完成所有的事情。

2. Umi UI 使用路径

基于以上所述，我们有两种方式去使用 UMi UI 工具。

（1）正常启动我们的项目，通过预览页去做配置、资产管理、添加等一系列事情； （2）单独去启动一个命令行，去打开一个完整功能的页面，然后在里面完成具体的事情。

3. Umi UI 的优势与挑战

如图所示，右边的表格显示的是各家可视化框架工具的优势，左边则是 Umi UI 的优势与挑战。

4. 功能矩阵

功能矩阵主要包含三部分：流程、运行态能力、体验和提效。

关于蚂蚁可视化辅助编程工具 Umi UI 到底是怎么实现的，我们一起来探索其原理。

原理解析

1. 架构大图

以下是 Umi UI 的架构大图。

• 所有操作反馈到用户代码：所有在可视化上面的操作都是最终作用于用户的代码，代码变更后，Webpack 的编译就会重新触发，浏览器就会重新刷新，这其实是一个单项的流程；
• 插件分客户端和服务端：要实现一个功能需要同时覆盖客户端和服务端的能力；
• Mini 气泡：Mini 气泡和用户最终展示的 Dom 结构能有一些更深入的融合。

2. 插件体系

Umi UI 插件体系是 Umi 插件体系的一环。在蚂蚁，我们有几百个插件，如果这些插件需要增加可视化能力，只需要多增加一个编辑态即可。

下图是 Umi Ui 的界面，可以看到我们的界面里面的色块包含：侧边栏、底部状态栏、内容区，插件能力的好处就是可以扩展这些色块。

3. 类微前端的实现

插件的实现有两个特征，即每个功能块都是一个 npm 包，及 npm 包之间的发布节奏不一致。

基于这两个点，我们可以通过微前端的方式去实现插件功能。

扩展方式和现有的微前端方式又有些不同。现有的微前端方案通常基于路由，路由变化之后可以去渲染不同的子应用。在 Umi UI 里，不仅是在路由区域，每个区域都可以被扩展，它更像是跑在浏览器端里面的一种插件体系。

运行态能力是怎么做的呢？

先切换到一个编辑模式，在编辑模式里面就可以看到一些可以插入的“点”，点击这些“点”之后，可以把我们想要的代码插入到具体的位置里面去。

资产添加的实现是基于 AST 解析的。

实现原理步骤：

（1）在 <div> 里面套一个<UserLogin/>组件；

（2）然后它在进入编辑模式后，我们会自动分析出来，我们有哪些占位符。

（3）用户点击占位符之后，会点击一些具体的区块，选择具体的区块之后，我们就会执行添加的操作。

（4）添加之后也会做一个语法输入的解析（需要注意的是：这两个语法解析需要保持相同的语法逻辑），然后把他添加到我们想要的位置去。

关于这一点值得一提的是，这种实现方式其实他有一定的侵入性，开发的时候他会修改用户的代码，大家在实现这套方案的时候保证谨慎和小心。

破局

上面介绍完值得一提的功能点，接下来我想说一下破局。可视化辅助编程一个非常新的东西，要让用户去使用它，就需要真正能打动用户的点，当我们要做可视化编程辅助工具的时候，我们先分析了下目前开发者的时间分布。

根据以上的时间分布图，很明显，我们要做一些提效就要解决上面 70% 的问题，即交互场景和组件相关。

1. 资产市场

接下来，我们通过资产市场来解决组件相关的部分问题。

资产市场主要由以下几部分组成：组件、业务组建、区块、模板；

资产市场要真正做到提效，还有一些关键的点。通过实践，我们发现通过以下点能达到提效：

资产覆盖率达 80%、模板和区块的质量、生产和消费流程。

##2. 场景市场

场景市场（如下图）约占开发者 30% 的时间(这里与下图有差异，请以30%为准)。

右边是一个例子，它像一个 suggestion，我们可以做的很简单，也可以做的很复杂。做复杂的话我们要考虑很多点。我们在快速输入的时候，前面的东西其实是要做取消的，前面的输入可能会产生一些请求，这些请求也是需要做取消的，以及输入和 URL 需要去同步的，还要支持浏览器的前进和后退，像这类场景其实很多，我们要做好的话是需要去覆盖很多小的点，如果每个开发者都去关注这些比较小的点，其实开发成本是件很高的事情。

怎么让开发者写的又快，体验又好，我觉得需要一个类似场景市场这样的事情。

场景市场很多小的点可以去做沉淀，我们现在是通过 hooks 的方式去沉淀。

完成上面这些事情之后，我们来看下一个理想的项目开发流程。

3. 强约束的垂直领域框架

虽然现在的很多框架都有一些约束，但是这个约束其实是很弱的。大家在使用一些框架的时候还是能后去选择很多事情。

针对垂直领域，我们做了一些深耕之后，优化并总结了强约束的垂直领域框架。

基于这一点，我们就可以去做一个类似强约束有很多规则的框架。因为可视化编程工具是基于规则来产出的，有了规则之后，对于可视化辅助编程工具来说，就能去做更多的事情。

我们部门主要是去写前端的中后台代码，我们就会思考，“怎么去写中后台，是要个性话还是要非常集中式的，以及高效的？”所以我们现在的解法是，关键词“强约束”，另外一个是“配置化、约定化”。

（1）强约束

因为现在大家可选的技术方案还有很多，在内部做了很多的约束，大家可以选择不同的数据流，选择不同的 CSS 方案，那么这些技术方案我们是不是应该开放给使用者？尤其团队内部，是不是应该开放给别人去做选择，其实是一个可以讨论的点。我们现在决定的是不开放，所有的东西都是使用相同的，这样， 团队内部就可以保持一致性。

（2）配置化

配置化不仅仅是功能，还有 UI 层。我们看到这是一个 Design Pro 的一个例子，它有 logo、导航、菜单、页面区。每个页面的区别只有页面区这部分，其他部分基本是一致的，所以为什么不让其他区域通过配置自动在框架里面产生。做到这一层之后，其实就是像写小程序一样去写我们的中台代码。

配置层面的不仅包含 UI 层面，还有路由、布局、菜单、导航、面包屑、权限等，这些都可以通过配置化的方式去处理。

（3）约定化

大家通常看到一个框架的时候，可能会觉得它非常的黑盒，不知道为啥就能跑起来了，其实在它背后是有很多的约定。

通过约定，我放一个文件在那边，他就跑起来。

比如说，我有一个 modal 目录，放了一些 hooks，这就是一个数据流的方案。

然后，我放一个 locales 目录，里面去写一些国际化的配置文件，这就是国际化的方案。

我写一个权限点 JS，去定义一些权限，这就是我们的权限方案。

（4）数据流

这是我们简化后的数据流方案，

我们的项目背景是中后台，我们分析了几百个中后台的项目，我们发现大家用全局的数据流还是比较少，基于这种前提，我们把数据流做的很薄。

怎么做把数据流做的很薄呢？

• 基于 hooks 的极简数据流；
• 通过框架做约定和简化；
• 定义基于 hooks，使用通过 useModal。

（5）权限

权限也是类似于数据流，它是在 access.ts 的文件里面，去定义我们的权限规则，然后你可以在数据流的文件里面以及组建层通过 useAssess 去使用，以及可以在路由层做一些配置。

4. 强约束的垂直领域框架 + Umi UI

做了强约束框架之后，我们就有了很多规则，有了这些规则之后，有了约束、配置、规定之后，我们就可以让我们的可视化辅助工具去做更多的事情。

比如，我们可以通过可视化辅助工具，看项目的大图，你可以在页面里了解整个项目的情况，包括项目的 logo、title、路由、组件、权限、国际化、数据流、资产以及布局等。

展望和未来

目前，我们面临三条路：

• VSCode 插件；（优点：稳定；缺点：VSCode 插件限制非常多。）
• 基于 VSCode 封装 IDE；
• 命令行辅助（保持现状）。

未来，可视化辅助工具我们依旧专注提效。

总结

• 搭建虽好，写代码更佳；
• 我们的优势和挑战，包含框架、插件化、运行态能力；
• 插件化和类微前端前端的架构方式；
• 新事物需要破局点，破局点来自对开发者时间的探索；
• 未来三条路的选择。

作者介绍

陈成，花名云谦，蚂蚁金服高级技术专家，入职阿里已有 10 年。之前在淘宝，负责过淘宝首页、宝贝详情、购物车、下单等很多重要业务的前端部分，然后转岗到支付宝，负责 spm、支付宝开发者工具的开发，以及创建了 dva、roadhog、babel-plugin-import、umi 等。擅长的领域有工具、前端框架以及前端性能等，热衷于开源。