低代码平台实践

低代码页面的关联联动是一个比较复杂的工作，场景较多，难以统一抽象。因此我总结了几种类型，可以分别设计。

低代码平台是一个高成本投入项目，建设周期长，难度大，人员成本也高。然而低代码平台的工作，很容易出“成果”。但在我看来，很多“功能成果”，不过是“虚假的繁荣”。低代码团队的成果，不在功能堆砌而在效益提升

仅以此文总结一下团队在低代码平台建设中犯过的错：虚拟表/无状态工作流/外键设计等。如果能对其他低代码同仁有帮助，那便再好不过了。

本文介绍 web worker实践中的两个问题：worker.js打包（404报错）和第三方依赖的加载。

低代码平台，无论是功能抽象还是功能设计/交互体验，本质上都是替用户理解，替用户决策。 功能局限未必是低代码平台的缺点。

远程组件，即运行时可以远程拉取的组件。此文并不是介绍远程组件的原理和设计方案，只是记录一下个人感想：技术之外还有更多的问题需要考虑。

前端的代码编辑器选型主要有monaco-editor和CodeMirror两种，我司低代码实践中的代码编辑场景主要是函数设置，因此选择了更为轻量的CodeMirror。

配置时和运行时，看似简单清晰的分界，实践中有非常多的细节问题需要思考。既不能站在谁改的多的角度，也不能强行设置变更流程/约定等方法简单的一刀切，而应该看清楚，运行时可修改的配置与其他配置的本质区别。

不同类型的低代码平台必然有它自己的交互特性和路径依赖。不要试图满足所有群体的需求，也不要轻易的改变平台的主要目标客户。

在平台推广的过程中，随着各种业务压力与某些政治因素，低代码平台的配置迅速膨胀，虽然满足了功能需求，但牺牲了多数用户的开发体验。

一转眼在低代码平台已经3年了。我对低代码的认知，也从好奇——不屑——怀疑——自豪——坚定——反思，经历了漫长了心路过程。 人比工具重要，这是我三年里最深的一点感悟。

虽然可视化视图编辑器几乎成了国内低代码平台的必备要素，但在to B的大型复杂项目中的列表视图，可视化视图编辑器无论是交互体验还是配置效率不如预期。

国内的大多数低代码平台，都有一个非常显眼的，可拖拉拽的视图设计器，但可视化编辑器并不适合所有的低代码平台。

to B类saas产品，低代码平台可以在很大程度上降低定制成本。 然而在项目实践中，低代码这个工具本身就会带来诸多问题，在很多情况下反而并不能提升项目组的效率。

低代码平台的元数据查询是最核心的功能之一，而低代码平台面向的查询场景非常复杂，查询契约的设计直接影响平台的扩展。

我将低代码平台底层分为三种：流程引擎驱动、元数据对象(模型)驱动和视图驱动，不同类型平台具有各自的特点。

低代码平台的国际化改造，应该分为三个部分：低代码组件/sdk内置文字国际化改造，配置schema的国际化改造和数据的国际化改造。

低代码平台架构实践，包括运行时技术架构、配置时应用架构、部署架构、商业化改造架构迁移，以供后续参考、反思总结

低代码应用运行时大多为aPaaS架构，即每个低代码应用可以作为一个独立的应用服务，包含登录、基座/菜单、配置出的应用视图和后端服务。

低代码平台前端二开机制，大致有两种： 平台直接提供整个页面的代码，即出码 平台提供视图组件，组件约定二开机制，即配置扩展