关于低代码平台的一些思考

前言#

我理解上的低代码主要是一种可视化应用开发方法。通过低代码开发，不同经验水平的开发人员能够通过图形用户界面，使用拖放式组件和模型驱动逻辑来创建 Web 和移动应用，而低代码平台的面向人群决定了工具和平台的适用人群，一般来说，有针对开发的低代码工具，也有针对不懂代码的运营和产品人员的无代码工具，相比较来说，无代码是一个理想下的产物，可以说在接触这么长时间以来，基本上是一个比较虚无的概念，任何平台和工具都没办法做到完全的无代码，毕竟业务和模型都是不一样的，而某些业务场景足够复杂或者说迭代频繁的情况下，无代码更是一种理想状态，满足不了所有业务场景，所以相对理想的情况，一个比较合理的低代码平台才是应该做的，毕竟平台搭建完成之后，更多的是一些平台的补充、物料的开发了

介绍#

通常意义上的低代码平台会有三个关键点（来自阿里开源的 Lowcode Engine ）：

• 一个用于生产软件的可视化编辑器
• 中间包含了一些用于组装的物料，可以通过编排、组合和配置它们以生成丰富的功能或表现
• 最后的实施结果是成本降低

其中低代码平台最重要也是应该做的就是节省时间，而第三点成本降低就是考量低代码平台是否达标的一个关键性因素了

关于低代码的一些想法#

在新公司之后了解现有的低代码平台也是这个样子，主要由三部分组成

• 设计器（模型设计、页面拖拽、搭建等）
• 物料平台（组件、通用能力、API等）
• 后台服务（数据持久化、接口、模版和页面数据等）

其中因为之前同事他们之前想的是做一个无代码工具，而我进去之后所做的一些事情看基本上伪需求，根本就没有满足任何一个业务场景需要的业务模型，所以只能是一个伪命题，后续给营销提供低代码能力的时候也证明了这一点

营销的业务变化会比较大，但有时候也会比较单一，主要也就是围绕着拉新和复购活动、抽奖、领券、奖品等这些，所以低代码就能很好的解决他们的了问题，后期的节日性质或者说比较特殊的业务场景，也可以通过修改、添加新的低代码组件的形式给予支持，这部分组件也是可以交由营销的开发自己去实现的，毕竟运营需要的只是一种能力，这种能力通过修改组件的属性形式是完全可以支持的

因为低代码平台已经开发完成，因为时间效率缘故所以对平台能做的就是一些修修补补（之后会重构大部分逻辑，主要也是因为之前代码前后端没分离oh my god），这次记录的也是主要的一些想法

低代码平台部分#

平台提供给运营的能力主要是两部分组成，模版和页面，其中模版主要是由产品配置后给运营使用的，在模版内会固定页面需要的组件、组件的基础属性和业务属性等

• 这部分需要改造的是模版和页面的组件部分，之前的组件加载和打包都是在线上完成的，通过开子线程来做组件的打包和页面内整体组件的整合打包等，实际使用情况来看组件和页面应该是隔离的，在开发组件的时候就应该完成这些事情，所以需要的是改造组件的脚手架，把这部分逻辑提前做掉，对组件的打包和上传都在本地或者CI环境内完成（目前是在本地），开发只需要在本地执行命令后就可以通过API告诉后台服务此次组件更新的版本号、打包后的CDN地址等，不再上传打包后的源代码
• 后台服务中组件的加载逻辑需要修改。由原先子线程打包的形式修改为加载形式，只去加载已经打包好的CDN地址，主要涉及两点，1：组件库部分，原先提供了一个组件库管理组件，模版只需要引用组件库就可以使用这个组件库内的所有组件；2：模版和页面部分，需要为加载组件库的CDN地址，不在后台继续打包整理组件库和相关组件的依赖关系
• 脚手架改造。虽然已经提过需要改造脚手架，这个单列主要是区分一下，上面针对的是组件打包部分，这次需要提供新能力，将组件的打包和构建提到CI环境，提供一个统一的环境来处理组件升级、构建、打包等操作

其中主要通过 systemjs 完成组件库和组件的CDN模块加载，免于处理组件+组件的依赖，之前通过异步加载会有顺序问题，这次同步处理掉这个小问题

低代码组件部分#

组件部分做的比较重要的工作是瘦身，因为公司内的页面在推行秒开率的检测，一般要求一秒打开率要在70%以上，而现有的打包到一个文件(app.js)的形式完全不满足，并且是反着来的，这样就很坑了，所以这部分需要做该做，主要是瘦身工作，包含两部分

• 设计器内的瘦身。主要是围绕整个组件的大小来做的，之前组件会包含编辑项（编辑业务和基础属性）、运行时（runtime，包含设计器内和C端，通过环境变量区分）、样式（style）、描述文件（xg.json，描述组件版本、名称、样式和编辑项等文件的引用地址等），而通过描述文件可以看出来，所做的主要瘦身也就是抽离，把C端的和设计器内的做一个抽离，其中编辑项部分因为会有很多的属性编辑等方法存在，而且大部分格式基本类似，主要也就是编辑项类型不同、setter方法不同、属性值和字段名不同，这部分需要提供一个编辑项的生成平台，生成平台可以整理编辑项的所有类型，开发可以通过拖拽Tree的形式来生成相关编辑项代码，后期还可以把编辑项和组件抽离，直接在线上通过约定的形式加载
• 组件瘦身。组件包含的内容上面已描述，其中的想法是希望组件是一个纯粹的 react 组件，不在是一个约束的低代码平台组件，希望把这部分能力释放出去，之后任何业务项可以直接使用他们自己已有的业务组件，只需要接入低代码平台提供的 SDK 就可以变成一个低代码平台的组件了，这样释放后的组件能力就变的比较广泛，任何一个开源或者业务自身的UI、库都可以直接用了，而平台内提供的能力也变成了上面说的编辑项的生成平台和一个接入的 SDK了，也不再需要单独再开发一个新的低代码组件，提高了组件的抽象，封装，重用能力

关于组件的另外一个设想，是提供一个低代码的IDE，来完成设计、开发、数据和部署的过程；也就是可以对组件进行“全生命周期管理”，这样的话就像开发小程序一样，将低代码组件变得更便捷化，当然这部分是一个设想，可能之后会实现

其他畅想#

如果再加上设计链路的话，可以畅想的页面开发场景是：

简单的展示类页面能从设计稿直接上线。

需要交互逻辑的，由前端在生成的代码上补全逻辑。录制测试用例，然后上线。

如果设计有样式上的修改，不影响逻辑，那么设计改完之后能自动重新回归测试并上线，不再需要前端参与。

如果有逻辑变化，平台能通过 diff 设计稿得到组件的改动，再通过语意分析得到影响的逻辑代码范围。

总结#

低代码平台业务跑下来更多场景主要是通过堆组件实现的，运营和产品更多的时候使用的是平台提供的基础组件和业务组件来生成运营组件，类似一些按钮、图片画廊、商品等的展示，到瀑布流、抽奖等的静态

只要有足够的组件，运营甚至可以实现任何事情，当然他们不会写代码，所以这个时候组件的逻辑部分就不重要了，只需要简单的 event hub 就可以满足

而开发如果直接从源头介入是不是更能提高生产力呢。从前是运营-产品-设计-开发-运营，现在我们可以直接让运营去生成运营组件，这样就由平台提供必不可少的代码转换的逻辑，毕竟不管是从设计稿到代码、还是从平台组件到新平台组件，其中最重要的是转换，而直接由运营来上传设计稿生成组件应该更可以展现低代码的高效和便捷性了

当然可能会有人说这样就没办法让测试介入，如何保证质量呢？

实际上大部分低代码平台都会有组件仓库、模版、页面的组合，所能看到的大部分在组件仓库渲染的时候是直接渲染的组件代码，如果可以通过实时截图，是不是更能展示相关组件呢？甚至可以提供不同渲染逻辑来生成不同的组件截图，这样可以在某个时刻去对比这些截图，来做自动化测试，或者展示时候提供不同条件下的截图？

如果上面所想的完善的话，应该算是一个达到合格线的符合业务使用的低代码平台了

尾言#

文章是这一年以来对低代码开发的总结，其中有这一年多的思考，大部分提到要做的事情算是上半年的一个验证，这次整理了下之前记录的 flomo，经过这半年来的开发总算把上边畅想的全部完成了，现在公司内的低代码平台应该算半合格的产品了，剩下的主要是之前架构一些不合理的地方的修改和重构，像是前后端分离、组件和模版的管理等都需要重新梳理下，接下来的目标是希望把平台做成一个合格的产品了，💪

资料：#

• Lowcode Engine
• systemjs