《低代码平台》分享文字稿(上)

最近几周没时间写博客，主要是一直花时间(顺便补了打越的999)在整理这个在公司内部分享用到的一个ppt以及文稿，做分享的一个目的是安利一下我写的框架，也算是来b站半年来主要花时间做的东西。另一个目的就是相当于一个总结与记录吧，学到的以及用到的知识只有总结成体系才不容易忘。第一次分享会也结束了，文稿基本定型，所以在博客这里分享给大家。内容比较多，分成上下两篇。

第一页——介绍

大家好，我是来自前端技术部的折梓，首先感谢大家抽出时间来听这次分享，今天我要分享的主题围绕两个点，中后台开发，低代码平台。前者是问题，后者是方案。在谈到解决方案之前，先看一下中后台开发目前存在什么问题。

第二页——展示现状

首先就是多。这不算问题，应该说是中后台开发的一个特点。因为每个稍有规模的项目都免不了对数据进行处理，小到博客，大到我们整个主站，这是我从OA上截的一张图，可以看到，有大量的后台管理系统。每个后台项目都由各个独立的项目组维护，开发方式和写一般的前端项目没什么不同，都是借助优秀的三方组件库，比如Element或者自己项目组沉淀的一些组件开发并维护，属于最传统的开发模式。

第三页——说明问题

传统开发模式本身没有问题，但是因为中后台需求的特性，再加上量大带来的质变，两者结合就产生了问题。因为中后台的需求都是围绕着数据进行处理，离不开curd+展示，就造成了大多数情况下，我们编写的代码模式及其重复。相信有过后台系统维护经验的人都有过这样的经历——接到一个新的页面需求开始开发时的第一件事，就是找到一个类似的页面，COPY AND PASTE，然后再根据后端文档改改ajax方法里的url和传参，表单和表格组件的model，最后再看数据怎么展示，再去找对应的表单组件复制粘贴过来。最后再修一些细节就可以提测了。中后台开发就是这么的朴实无华且枯燥。但这些虽然重复繁琐，却又是不得不做的工作。

第四页——问题展示

我再以我们项目为例，举几个具体的例子。一，代码模式重复率高，比如fetchData这个为代表的一系列和数据交互的方法，过滤的时候要fetchDatawithquery，提交的时候要处理fetchdatawithform，我们在每个页面中都要一遍又一遍的写。其二，风格混乱，比如表单验证，有直接在提交方法里做的，有单独抽一个方法的，也有html上验证的。当然我们可以用什么表单工具约束，但这只是一个小代表，要约束的地方不止有表单，应该是所有可以重复的地方。其三，不易维护。时间长了就涉及到组件的更新和替换。比如我们项目里的FormItem和FormGroup来处理表单布局，职责比较相似，我到现在也搞不清楚这两个组件的区别，如果有一天想把这两个组件合并。或者干脆换一套统一的表单方案，那旧代码处理起来就很麻烦了，只能让新老代码共存。

总结一下就是，可以简单重复的模式仍然在用手工维护。鲁迅曾经说过，越是简单的东西越容易出错，我自己的一个体会就是，写复杂需求精力更集中，一但重复写法太多，就很容易在细节上出问题，比如一个表单字段传的参数稍有变化，由必填变成非必填就很容易忽略，反而被测试测出的bug会多一些，虽然改起来快但总是个麻烦的事。每个后台管理应用的基础设施是相同的，部分的代码逻辑也是相同的，它们可能只是数据模型不同而已。结果却导致了要一次又一次地重复编写大量相同的页面。一直重复的过程中，我们其实就应该想一下，是否可以有更好的解决方案？也就是我今天要谈到的另一个关键词了——低代码平台。

第五页——抛出解决方案

那么首先要解释一下低代码平台是什么。 实际上这并不是一个新概念，从早期的DreamWaver到现在百度的amis，美团的乐高，阿里的飞冰，云凤蝶等等，都在尝试通过低代码的手段降低应用开发门槛，提高生产效率。核心特点有3个：1. 面向开发人员 2.支持可视化配置 3. 跳过基础架构和代码细节的快速开发。 可以看到和低代码相对应的还有no code和pro code两种模式，pro code就是我们的常规JS代码+组件开发模式，no code就是H5页面搭建那种在编辑器中不写代码通过拖曳就能生成页面的模式，low code就算在两者间的权衡。三种不同的编码模式本质上也就是代表了三种不同的封装层次，有不同的特点和适用的需求复杂度。

第六页——不同模式特点

在说到如何设计一个低代码平台之前，我先说明一下为什么低代码平台适用于中后台开发，因为包括我自己，大多数开发者对于可视化编辑器的第一反应其实是排斥的。最直接的理由就是：有使用上的学习成本，不如手写代码灵活。确实是这样，封装到越上层，就越不灵活，编辑器很难应对平时复杂多变的需求。但我们需要搞清楚这个问题的本质。

我们平时处理的需求是属于高复杂度的一类，特点是灵活，对应到三种层次，最适合的其实是Pro-code，用上面两种手段去处理都是不对应的，就会体现出灵活不足的问题，我们排斥编辑器的本质是想用它处理不合适的需求。那么我们回过头来看中后台开发，需求强度应该在中间，这时用编辑器其实就很合适了，能做到复杂度和封装层次对应。再想想为什么之前用pro-code的模式去处理中后台需求会有那些重复问题，本质还是封装层次过低，和需求复杂度不对应，中间的差异就要用重复编码弥补。

第七页——中后台通用模式

具体来说，不讨论UI展示和交互细节的情况下，90%的后台管理页面的需求复杂度都可以简化为这样一种模式： 首先是新建数据，把数据提交到外部API，再从外部API的列表接口获取数据展示。有了数据后就可以编辑或者过滤，最终都要落到展示上，整体形成这样一个流程图。然后其中的新建和编辑可以封装为表单组件+逻辑代码。和API交互的部分可以封装为ajax+逻辑代码，展示数据的部分可以封装为表格组件+逻辑代码。这些被封装的部分就算是LOW CODE了。

第八页——DSL封装

然后用一层DSL表达出来，比如说用JSON。ajax+重复逻辑代码用一个特殊的API字段表示。表单+重复模式代码，用type: form + API + 表单相关的props表示。展示组件+过滤组件+重复模式代码用type: curd + API + filter表示。最后我们只需要解析这个JSON就能直接得到需要的页面了。

第九页——缺点

那么再看LOW CODE模式下的缺点，比较关键的有两个点。但因为我们把场景限定在了中后台开发下，所以这两个缺点都可以忽略。目前有很多低代码平台，核心思想都是相似的，但是根据解决问题的场景不同，有很多设计上的细节会有分歧。之前看云凤蝶团队的分享，他们产品在早期定位不明确的时候，按照中后台的思路去做，结果接到的第一个需求是门户类页面的开发。做的非常勉强，做出来还不能完全满足需求，别人不买帐，又推倒用手写代码的形式重做了一份。所以限定场景，想清楚要解决什么问题是很重要的。

第十页——优点

最后看优点就比较明显了。我们从开发流程的每个节点上来看：

首先是产品提出需求，中后台系统的特点就是产品来自各个产品团队，每个开发团队也有各种各样的中后台，基本呈现一个多对多的状态。产品第一件事肯定是看这个中后台的表现，设计上尽量保持风格统一。这首先就是个花时间的地方。有了框架的统一模式约束，所有中后台风格统一，产品就可以把关注点聚焦到最核心的地方，如何展示数据，如果操作数据，不用再考虑一些细枝末节的地方，比如搜索按钮放在哪里，批量操作按钮放在哪里，这些按钮什么颜色，表单验证的错误提示放在哪里。这些怎么表现不重要，统一的表现才重要，所以全部由框架统一约束。

对于开发来说，编码时间缩短不用说，不用再关注重复细节，还可以利用各种工具比如cli和可视化编辑器。后续维护代价减小，组件的更新和维护都可以聚焦到框架内部，不同的项目组不用再考虑用什么组件库再做二次封装，用什么表单验证方案，这些都统一由框架提供。

测试时间缩短，因为框架内部保证了能配出来就绝对是稳定可用无bug的，测试只需要关注流程是否正确。

对于用户来说，降低后台管理系统的使用成本与心智负担，本质是框架对产品的约束进一步反馈到用户上，能保证所有后台系统的交互统一。我以前就接过一个需求，一个后台系统里操作的数据我这边会取到并展示，两边都是多选框，结果两边多选交互不一样，产品希望保持统一还讨论了很久。用了框架约束就不会有这种问题。

最后再谈NO CODE，为什么不用NO CODE的模式，本质还是封装和需求的统一，NO CODE 封装层级过高，主要面向用户。后台管理还有10%的页面需要手工维护，LOW CODE主要还是面向开发，对于可视化不能满足的需求，仍然要提供pro code自定义的能力。

到这里，其实我们对于一个low code平台有哪些要素有一个概览了。下面就谈如何设计一个这样的平台。

小结

上篇主要介绍中后台开发有什么问题以及对应的解决方案——低代码平台。下篇就分析如何设计一个低代码平台。