云凤蝶-如何在企业级中后台业务实践低代码搭建

本文为在 《第二十一届前端早早聊大会 | 前端搞搭建》的分享文字稿。
推荐使用阅读体验更佳的 语雀 阅读。

Hello，大家好，我是来自 蚂蚁金服-体验技术部-云凤蝶 团队的江木，我今天的分享主题是《云凤蝶-如何在企业级中后台业务实践低代码搭建》。

首先做一个简单的自我介绍，我的花名是江木，大家可以通过 paranoidjk 这个 id 在各种社区找到我。
在蚂蚁个人的经历的话主要是在 17 年的时候重点参与过 antd-mobile 的建设，那个时候在 github 上提交了比较多的代码，后面基本都是在投入做移动端的运营活动搭建和中后台的可视化搭建产品，也在 知乎 上发布过一些博客文章。大家如果想要跟我做进一步的讨论沟通也可以扫信二维码添加我的微信来找到我。

首先《如何在企业级中后台业务实践低代码搭建》这个标题显得有点长，我花点时间给大家解释下。

首先什么叫”企业级中后台业务“？

中后台业务比较好理解，就是那种前端同学们非常熟悉的充满着表单，表格，详情，图表的后台管理系统，某种程度上我理解他是传统的数据库管理软件的延伸。

其次，为什么加一个企业级的前缀？这是由我们团队的业务特色决定的，在蚂蚁这边，类似金融云、阿里云这样的控制台是要面向外部用户的，它对视觉美观，交互体验，加载性能都有很高的要求，而且功能复杂度也相当高，因此它的业务重要性会比传统认知里面的一些 xx 后台系统要更高一些。

最后，低代码大致是指什么？
我摘取来自于低代码领域明星厂商 Mendix 的解释：
低代码开发是一种可视化应用开发方法。通过低代码开发，不同经验水平的开发人员能够通过图形用户界面，使用拖放式组件和模型驱动逻辑来创建 Web 和移动应用
这段话比较拗口，我觉得不管专业名词怎么阐述都不用纠结，其实它都是代指现代软件研发领域的一种思潮，也代表着这个行业的生产关系发展变革的趋势，主要是从商业诉求上，目前的研发效率已经不满足需求，我们需要在传统的代码研发之上来想办法进一步降低软件研发的专业门槛以及提升效率。

我今天的分享主要分为四个部分，
首先会大致介绍一下云凤蝶这个产品，因为它目前还只对蚂蚁内部服务，那么演示一下功能会帮助大家有个印象。
第二会介绍下云凤蝶为什么做，解决问题的设计思路是什么，底层逻辑是怎样的。
第三会深入细节介绍下云凤蝶的技术实现以及挑两个比较关键的点来展开分析。
最后会简单总结一下以及发一个招聘广告~

一、云凤蝶产品简介

首先给大家看一下云凤蝶的编辑器主界面的截图，可以看到和 VSCode 这种大家日常用的 IDE 是很像的，只不过最明显的差别是除了编码之外，还多了可视化的画布功能。

核心特性演示

无图无真相，下面通过几个视频给大家演示一下云凤蝶的几个核心的功能特性。

第一个给大家分享的是云凤蝶的自由画布。
大家可以观看下这个 demo 视频，我拖拽添加了两个 antd 的按钮到页面上，你可以发现所谓自由画布就是类似 Sketch 设计软件或者做 PPT 的那种拖拽体验，它更符合用户直觉，而且它的门槛更低，没有编程技能的用户也可以使用。

当然云凤蝶的自由画布的用户体验和功能集合相比 Sketch 还差很远，如果对这个领域感兴趣的同学也欢迎找我沟通讨论~

第二个给大家分享的功能就是智能向导。
它其实是一种 UI 生成引擎，它直接从后端的接口的元信息出发，通过对 API 数据字段类型的理解和对蚂蚁的 Ant Design 设计规范的掌控，直接生成完整的真实可运行的应用。

比如这张图是早期我们做的一个对比，左边的是我们的设计师人工设计的一张大表单，右边的是云凤蝶的智能向导根据这个页面的后端接口自动生成的表单页面，可以看到在品质上甚至机器生成的更优，非常惊喜！

经过不断的迭代和进化，到目前为止，云凤蝶的 UI 生成引擎产出大约已经占到我们平台总代码数的 45%。

下面还是通过一个视频演示了一下智能向导的主要使用流程。

基本上就是你选择一个后端的接口，云凤蝶会自动帮你生成合适的表单、表格、图表、详情等等完整的真实可运行界面，你可以实时调整和预览，这其中既包含的数据字段的理解，也包含对设计规范的掌控，更包含对整个低代码的应用 DSL 的理解。

第三个给大家分享的功能就是组件导入。
对于组件化的搭建平台来说，组件或者说物料的丰富和好用是极其重要的一部分。
云凤蝶采取了一条从代码世界自动导入组件的开放资产体系的道路。

照例给大家演示一下，可以看到大概几分钟就可以完成导入一个 antd 的组件到云凤蝶上来使用。

典型案例页面

看过上面几个核心功能的视频演示之后，大家应该大致对云凤蝶有一些了解了，那云凤蝶的主要应用场景是哪些呢？
出于数据安全的考虑，我直接以开源的 antd-pro 的网页截图来介绍， antd-pro 代表的这种系统其实就是云凤蝶最典型的目标客户，而且在能力上限上我们目前也可以说，antd 能实现的效果，云凤蝶都可以实现。

二、云凤蝶设计思路

为什么做云凤蝶？

第一部分简单介绍了云凤蝶是什么，那这一部分也要简单介绍下为什么会做云凤蝶，它意图解决什么问题？背后的思路是什么？毕竟任何一种工具或者技术产品或者解决方案的诞生，都会有它的背景。

云凤蝶的诞生缘由很简单，主要是业务和人之间的矛盾，一方面是模式化的 CURD 中后台业务需求连绵不绝，但是整体效率和质量都存在问题。而另一方面，虽然设计体系和基础技术在飞速的发展，但专业前端工程师数量瓶颈依然存在。

云凤蝶解决问题的思路是什么？

云凤蝶解决这个问题的思路是什么呢？
让我们朴素的来思考这个问题，投入的人数乘以单人的工作效率就大致可以得到工作产出，因此两头都可以发力。
一方面我们想办法让事情更简单，尽量提高单兵效率，比如可以通过提供一些更简单的方案：可视化拖拽，低代码，可以提供更好用的工具：全链路一站式 IDE 等等
另一方面我们想办法让更多角色参与进来，赋能更多人，比如我们尝试让产品经理、设计师、后端等这些非专业前端参与到研发中来，我们甚至可以让机器智能参与进来，毕竟做一些模式化的事情，人肯定比不过机器。

总结来说，我们是在尝试降低上手门槛、减少人工工作、并且想办法提高效率。

前端代码研发有哪些可以优化的痛点？

前面介绍了云凤蝶低代码的思路，那么低代码相比”高代码“（Pro Code）有哪些优势呢？要回答这个问题，首先要去挖掘下现在的前端代码研发有哪些共享的痛点问题亟待解决？

首先我想从宏观的架构层面来探讨一下，HTML 这种 XML 的设计，天生就有两个架构上的特点： “垂直嵌套，水平扩展”。

垂直嵌套是指标签之间是互相嵌套的，水平扩展是指标签本身的种类是可以无限扩展的。

而这样的特点也导致目前前端的三大框架基本都是 以组件抽象为核心，进行分治与组合。
比如图中大家可以看到三大框架在 Component 这一层面的设计概念和 API 之复杂。

这些因素综合起来导致，代码研发的门槛是很高的，效率也存在提升的空间。

具体来说有如下一些问题：

• 组件和页面等价，单点就是整体，做微小改动都需要先学会整个框架才能上手
• 组件之间的位置关系编排需要学习专业的 CSS 布局知识
• 组件的父子兄弟通信、动态数据绑定需要学习复杂的框架方案
• 标准化的表单、表格、详情、图表等需要重复研发

注：对这部分话题感兴趣的推荐延展阅读 面向 Model 编程的前端架构设计

除此之外，还有很多普遍存在的问题，比如：

• React 聚焦在视图层，逻辑层缺乏简单好用的方案

这里其实有一个挺有意思的细节，其实 Mobx 诞生 Mendix 这家低代码领域的明星公司，感兴趣的可以阅读：
Making React Reactive: The Pursuit of High Performing, Easily Maintainable React Apps

• CSS 没有好的工程化解决方案，百花齐放
• 技术栈升级迭代快
• webpack 构建慢
• node_modules 依赖黑洞
• 各个领域技术选型多而复杂，缺少最佳实践

云凤蝶选择怎样的应用架构？

云凤蝶虽然是低代码的平台，但本质也是在完成前端应用研发，那不可避免我们仍然要思考云凤蝶推荐的应用架构是怎样的？
说起前端的应用架构或者说 GUI 软件研发架构这个话题，其实大家应该能想起不少耳熟能详的名词。
我按照时间整理如下：

• MVC 1970
• Reactive Programming 1987
• MVP 1990
• MVVM 2005
• Flux 2014

应用架构如何指导低代码平台设计？

整体来说，云凤蝶的宏观的架构是：视图和逻辑分离，宏观分层，不同层采用不同策略提效

• 对于视图层，可能是由广义上的设计师负责，基于基础组件可视化拼装，基于约束来布局，不需要写 css
• 对于逻辑层：可能是由工程师来负责，主要工作是设计 ViewModel 和完成响应式的数据绑定，只需要写简单的 JS

当然这里的意思并不是较真说做视图和做逻辑的真的要是同一个团队的两个不同的人，而是在表述说这两份工作其实可以是不同的角色来负责，它们的技能要求和特点其实是有差异的。

比如有一些先行者，微软给 WPF 搭配做的 Blend，一个针对 XAML 的可视化设计器，希望让设计师负责界面，工程师负责逻辑。
再比如虚幻引擎的蓝图可视化脚本系统，思路都是尝讲讲一个大型软件中的不通部分工作进行切分和重组。

三、云凤蝶技术实现

前面介绍了云凤蝶是什么，为什么，以及怎么设计的，这一部分会重点介绍一下云凤蝶一些核心功能的技术实现。

首先看下云凤蝶宏观架构，我按前后端来区分，大致如下。

整体来说前端技术栈是以 TypeScript 和 React 为主，包含的模块则是从 底层的DSL，往上走到编辑器、运行时、UI 生成引擎等等很多，此外还有独立的资产体系。
而后端主要是以 Node.js、 Java 以及 Serveless 技术为主。

而本次分享由于时间因素和个人的专业范围限制，仅将重点介绍一下自由画布和大型 Web IDE 技术架构这两个话题。
如果大家对云凤蝶更多的细节感兴趣可以查阅 云凤蝶可视化搭建的推导与实现 - SEE Conf2020

是什么，为什么？

面对一个问题首先问是什么？
我觉得用 Sketch 做过设计稿，用过 Keynote 或者 PowerPoint 做过演示文稿的都会比较容易理解什么叫自由画布。

而对于为什么选择这种模式？我觉得好处也是显而易见的，因为它更简单易上手，屏蔽了专业前端概念，更契合普通用户心智，可以让设计师，产品经理等这些角色参与到研发链路里面来。

如何实现鼠标 select、drag、resize 任意组件？

自由画布最核心的功能无非就是点选，拖拽，resize 等等了。

大家可以思考一下，由一堆 react 组件组成的页面，如何实现鼠标点下去绘制出对应的选中边框，并且组件可以随意拖拽和改变大小呢？

这里只简单介绍下云凤蝶的核心原理和思路。
最核心的原理就是对 dom 进行打标，然后通过 Dom 的 MutationObserver 机制监控所有组件的 dom 组件的坐标，当鼠标点击时就可以通过鼠标光标位置与组件 dom 位置之间的关系进行算法运算，从而计算出来选中了什么组件。

至于拖拽的核心原理，则相对简单，只要在编辑态通过绝对定位来渲染所有组件，那么在拖拽的时候就可以通过计算鼠标运动差量来完成定位的更新了。

如何在原始渲染结果上附加海量的交互与显示？

一块自由画布有点像设计软件，有很多的辅助功能，比如图中演示的缩放、拖拽、对齐、测距、吸附、分布扥等，那这么多的功能，每一个功能都有它的事件监听，处理逻辑，ui 渲染，那这些东西是如何与原始的组件渲染结果融合在一起的呢？

答案就是云凤蝶画布的分层架构，这个思路就是参考设计类软件的图层概念，将渲染层和交互层拆开，逻辑独立，dom 独立，仅视觉位置重叠，这样在代码的维护性和操作的性能和体验上都会有很大的提升。

如何让页面和布局更低代码？

上面讲了自由画布，而不论是 Sketch 还是 PPT 制作的都是一个静态的布局，云凤蝶如何实现不写 css 就可以制作一个自适应的页面呢？

这背后核心有三点设计：

• 一是不让用户手动维护组件树，而是基于一个区域的包含算法来自动识别组件树，毕竟除了专业前端，普通人是很难理解平面为何要按树结构来组织的。
• 二是通过绝对位置的水平垂直行列分割，将大面积的绝对定位切割转变成小的局部的相对定位
• 三是通过定义一套语义化的可配置式布局约束规则，并且将其翻译成 css

而云凤蝶的这套布局系统整体来看做了如下简化：

• 简化了布局范式，只保留了相对最近元素定义
• 简化了盒模型，将 padding 和 margin 统一成 spacing
• 尽量采用智能推测，减少手工配置

之所以付出这么多努力来屏蔽 css，主要是 css 的复杂度很高，而中后台场景的布局模式相对收敛，无需整套 CSS 能力。

大型 Web IDE 技术架构

下面给大家分享第二个话题，上面介绍了许许多多云凤蝶的功能，那大家可以猜想下这一张大架构图里面整个云凤蝶这么多功能，前端的代码量得有多少？
你觉得如何来组织这些代码会比较合适？

如何组织代码？

早期的云凤蝶，就是采用最容易向导的，传统的 src 式的自顶向下的代码组织方式，当渡过了产品从 0 到 1 的阶段，当我们功能迭代节奏越来越快越来越多，逐渐暴露出了非常多的问题。

最重要的问题是：一个代码文件应该放到哪里，可以被谁用，能用谁，没有范式

这导致

• 引用关系难以管控，耦合严重，修改一点东西影响面就很大
• 测试 mock 困难，bug 率居高不下
• 循环依赖，构建慢，性能差...

另外还有一个问题是云凤蝶的编辑器本质上是在通过可视化的方式生成一份应用的 dsl，而在早期我们采用前端直接对这个 json dsl 读写的架构，导致演变成一个 5000 行，300+ 接口的巨型单体服务，而且修改随处发生无法管控。

在做云凤蝶 2.0 的时候，我们的思路是去学习借鉴业界最优秀的一些设计模式进行重构，我们重点参考的有：

• Thiea：基于贡献点和扩展点的 IDE 松散架构
• Electron：多环境代码严格隔离
• Hibernate：将直接的裸数据读写收束成充血领域模型

而且我们确立下来云凤蝶 IDE 2.0 的两个宏观架构设计：

• 垂直分层：UI -> Service -> Model -> Repository 后端的经典架构，对于云凤蝶 IDE，视图其实才是纯粹的前端，背后的 dsl 读写和存储其实是属于领域模型层的后端服务
• 水平分治：将一个大的 src 拆成多个独立 package 的 monorepo 的形态，而且每一个 package 严格保持相同的包结构

如何避免包之间循环依赖？

在上一小节中提到了云凤蝶 2.0 的架构是从一个巨大的 src 文件夹拆分了很多个子 package，那么随之而来的问题是，这些 package 互相引用的时候，如何避免循环依赖的产生？

这个其实在 vscode 和 thiea 里面有非常成熟的解决方案，即 “依赖注入”。
简单来说就是消费方以 TypeScript Interface 为协议进行注入，从而实现消费方只依赖类型，不直接依赖实现，类型在编译之后会丢掉，从而并未产生实际代码模块的直接依赖。

而且类型还可以起到更好的文档作用，提升维护性。

至于 TypeScript 依赖注入的核心实现原理就是“反射”，即利用 TypeScript 的 decorator 和 reflect-metadata 在运行时获取到类型信息，从而查找到匹配的实现。
其使用方式如图，基本分为构造函数参数注入和类成员属性注入两种。

如何将多个包的代码汇总起来运行？

上面提到云凤蝶 2.0 的架构是从一个巨大的 src 文件夹拆分了很多个子 package，那这些子 package 的代码如何汇总起来运行呢？

核心原理其实是以依赖注入技术为基础，实现一种 contribution 的贡献与扩展机制。

它可以简单的理解为一种分散式的配置。
为了更好理解，举一个实际应用，IDE 上面有很多一排排的工具栏，这些工具栏里面的每一个具体功能可能是来自于不同的功能模块的业务范围的，他们的代码应该分别维护在各自的业务 package 里面交给不同的人来维护，而负责将它们汇总收集起来渲染的，就是 contribution 机制。

更多有意思的话题？

上面提到过，由于时间的限制，本次分享仅探讨了整个云凤蝶架构里面的非常小的编辑器这一块的细节，其实还有非常多有挑战的课题，比如：

• 怎么让自由拖拽的画布在调整大小的时候能自适应的联动挤占？
• 怎么让 UI 生成引擎生成的界面排版更美观？
• 可视化搭建的平台如何处理多迭代开发？如何解决冲突？
• 怎么基于后端领域模型直接生成前端？
• 云凤蝶如何实现应用研发无构建 （bundless）?
• 低代码平台无法满足一个用户需求的时候怎么办？

上面提到的那些非常有挑战性且有意思的课题，都很难，非常需要感兴趣的同学加入进来一起探索。

因此这里不可免俗的发一下云凤蝶的招聘贴，我们是 蚂蚁金服-体验技术部-云凤蝶团队，我们不只招聘 前端，还亟需 Java、Node.js、产品、设计 等各类人才加盟。
具体招聘 JD 请查阅：蚂蚁企业级应用制作平台招聘啦！，也欢迎扫描二维码加我微信沟通~

早早聊推书环节

最后按照大会要求，给大家推荐一本我觉得对于编码挺实用的书籍，感谢大家。