我理想中的低代码开发工具的形态

提到低代码，大家脑中浮现出的低代码产品的形态大都如下吧

或者这样的

可以发现，这类产品的操作界面几乎都是这样布局的：左边是组件物料，中间是画布，右边是属性面板。只是面对的目标用户以及使用场景不一样，比如第一张图其实是开源低代码框架 amis 的可视化操作界面，使用的用户大都是开发人员，主要用来写管理后台的表单界面。第二张图是低代码平台稿定设计的操作界面，使用的用户大都是业务运营，主要用来生成营销页面。

低代码平台

低代码平台相比于低代码框架或者低代码工具，功能更加完善，更加能称得上是一个产品。低代码平台面向的用户群体更多的是非专业的开发人员，或者需要投入的开发成本极低（二次开发除外）。但是低代码平台的通用性也是很低的，比如就算你拿到了稿定设计的源码，部署出来的东西并不适合你们公司财务部门的人员去使用。

低代码框架/工具

低代码框架/工具适合专业的开发人员使用，使用低代码框架或者工具可以极大的提高开发效率。开发人员甚至可以根据公司的具体业务，对低代码框架进行二次开发，开发出与公司业务契合的低代码平台，提供给其它业务部门使用。

技术原理

不管是低代码平台还是低代码框架，实现的时候大都会涉及到 JSON Schema、DSL、AST、逻辑编排这几个相关的技术。粗糙的说就是页面上的各种拖拽操作，属性面板的操作最终都会映射到一份 JSON 数据上，解析引擎拿到 JSON 数据后根据已经定好的规则进行解析进而生成页面。一些低代码框架还支持 “出码” 的功能，就是使用 AST 实现的。使用逻辑编排可以实现一些复杂的交互。

低代码的发展

平台型的低代码是很难落地的，但是低代码框架或者低代码工具还是有很好的前景的。

往前就不说了，就前端领域三个框架的时代，早期出现了 react-jsonschema-form，amis 等框架，那时候低代码这个词还没有出现或者所知甚少，amis 的介绍里也没有低代码一词。之后就是 form-render，formily。近两年低代码这个词火了之后，陆续出现了的各种 xxx-form 表单类的低代码概念的库。

还有一些适合营销类页面使用的开源作品也出现了很多，但是要根据公司的业务拿来落地实施，难度还是很大的，几乎都要二次开发。不像上面说到的几个管理后台表单类型的框架，只需要在项目里安装相应的包就可以直接使用。

低代码框架的好与弊

我自己在18年左右的时候就开发过类似低代码的东西，就是针对管理后台的 CURD 页面，封装了两个大组件，Form 组件，Table 组件，两个组件都是通过传入 json 数据，内部通过各种判断渲染出页面。当时前后端都是我自己写，大致是这样开发的：前端页面组件几乎没有任何代码，只是从后端接口拉取指定的 json，解析渲染界面。当时这样开发确实快，每当 json 定义无法满足产品需求时，改起来也比较容易，因为组件都是自己封装的。

直到我维护别人写的 xxx-form，xxx-table ，真是改一次吐槽一次小可爱。

好处

• 开发的效率也许确实变高了（看对封装的组件的熟悉程度了）。
• 代码风格统一（都是一样 json 配置）。
• PPT 上有东西写了。

弊端

• 增加代码维护难度和成本：低代码框架就是一个黑盒，当无法满足产品的需求时，需要去研究源码做定制开发。
• 对开发人员是一种残害：如果项目中使用的是比较出名的低代码框架，维护的人也许心里会好受一些，如果是某些不知名的练习生产物，维护的人估计要吐槽为什么加个字段还要去扒别人的屎山。
• 不利于经验少的开发人员的成长：没有经过大量的 CURD 代码的洗礼，怎么发现痛点，怎么有造轮子的 idea，沦为 json 配置工程师。
• QJ 产品的想法：“这个需求无法实现，代码不是我封装的，看不懂”。
• 后续可能会招不到人维护：练习生写的库或者大厂背书的 KPI 框架不维护了。

现在每当看到 “xxx-form 开源了，效率提高100倍”，我就想说小可爱。

一篇文章送给大家，也是告诫自己，不要以 DRY 之名，发明低代码 DSL 去残害你的同事 - 知乎 (zhihu.com)。

我理想中的低代码开发

我们造出各种 xxx-form，xxx-table 无非两个原因：CURD 的代码写吐了，天天重复没有技术含量的体力活；看了别人开源的也想自己写一个。

代码生成器

针对第一个原因，我们可以遵循重复的工作模板化，工具化的原则，把重复的 CURD 抽离成代码模板，然后写一个代码生成工具去生成代码。

19年的时候我就写了这么个代码生成器 使用 Node.js 写一个代码生成器 - 掘金 (juejin.cn)

大致原理就是把前后端 CURD 的重复代码抽离成模板，借助模板引擎，模板内可以根据传入的 json 进行各种判断后编译出代码。每次的使用时候，配置好 json，使用 node.js 调用模板引擎进行模板编译，将代码输出到指定目录。代码生成器生成的代码，跟我们手写的 CURD 代码几乎是一样的，往里面填空式的写业务逻辑就行。

node.js 写的代码生成器没有可视化的操作，每次生成代码都需要手动配置 json，如果一个 CURD 页面查询条件有十几个字段，table 里也有十几个字段，json 写起来也很费事。

为了代码生成器可视化，专门研究了 vue ui 和 umi ui 的实现原理。 机缘巧合之下又了解到了 vscode 的插件开发，通过 demo 实践发现在 vscode 里实现代码生成器可视化会更加简单，而且 vscode 的插件里还可以加入更多提效的功能。

vscode 插件

插件读取项目下的指定目录内的代码模板，显示到页面上

某个具体的代码模板是这样的

写 CURD 页面的时候，选择相应的模板，进入可视化配置界面

Schema 表单，是用低代码框架生成的（用魔法制造魔法），目前支持 form-render，formily，amis，也就是每个代码模板可以根据需要配置使用不同的低代码框架，然后配置对应框架的 schema 就可以生成相应的 Schema 表单。

通过配置 Schema 表单，可以生成模板数据

之后就是使用模板引擎进行编译生成代码了。

相比手动配置 json，通过低代码框架生成可视化表单进而生成 json 会更加便捷，而且可视化表单可以清楚的描述每一个表单项配置的作用。

尽管可视化表单的方式已经很方便了，但是一个个表单手动去填的话也是个没有技术含量的体力活，秉着能造轮子实现就绝不动手的原则，加入了几个实用的小功能：

• Ask ChatGPT: 在模板配置中预置 Prompt，将模板数据中的中文 key 翻译成应为英文，在填表单的时候就可以全部使用中文了，解决了变量命名的难题。我在 vscode 插件里接入了 ChatGPT，解决了代码变量命名的难题 - 掘金 (juejin.cn)
• 执行脚本设置模板数据：目前用法是 - 用 ocr 识别出设计稿或者原型中的文字，将文字传递给模板中配置的脚本处理，脚本里根据规则重新生成模板数据并返回，这样减去了一部分配置表单的工作量。
• 拉取 YAPI 接口定义生成模板数据。

插件内可视化拖拽布局

这个功能目前还没有实现，想法就是实现像 amis，formily 一样的可视化的拖拽布局界面，最终也是生成一份 json 数据，这个 json 数据就是模板数据，模板引擎根据这份 json 数据编译出代码。

以上就是我理想中的低代码开发工具的形态，落地的产物就是 lowcode - Visual Studio Marketplace

完

不像低代码框架，对项目有很强的侵入性，你可以随时随地选择使用低代码开发工具，而且不受项目中使用的是什么技术框架的影响，只要你能抽离出重复的模板。

随着科技的进步，低代码工具可以加入更多有趣的功能，而且不会对项目有任何影响。