低代码平台设计的边界问题
最近在研发低代码平台产品，研发的过程中的一些思考在这里记录一下。
与低代码（low-code）相对应的几个概念：
1. 背景
低代码平台面向不同的领域也有不同的细分，本文以我正在研发的企业经营管理领域的低代码平台为主要讨论对象。
平台的目标用户
企业信息化项目外包团队
企业IT部门
企业管理层
以上三种用户其实可以归为两类，一类是有一定编程能力的技术人员，一类是没有编程能力的管理人员。
这里一定要强调技术人员是“有一定编程能力”的，而不是超高编程能力的，因为超高编程能力的人也许不愿意受到平台的束缚，他们更愿意用库来搭建自己的系统。
而管理人员既是管理系统的用户，也是管理系统需求的源头，如果能够让他们通过平台对管理系统进行一些简单的定制（如字段级的调整）能够节省大量的沟通成本。
这两类用户在平台的视角下，都是一个最终系统的开发者。
2. 低代码平台的边界
概括来讲低代码平台是为用户赋能的。
何为赋能？这里的赋能不同于管理学和心理学中的概念，在这里是”赋予能力“的意思：平台为用户提供开发应用的能力。
必要的局限性
这种能力注定是有局限性的，因为无论何种低代码实现，都是在提炼经验的基础上隐藏“不必要”的复杂性，而这个“不必要”是在特定领域中基于"经验“的共识。这个“不必要”并不能通过纯理论检验，也就是说总会有“黑天鹅”的。
举例来说，通过 JSON Schema 生成表单是一种很常见的低代码实践。
JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.
JSON Schema 是一种用于标注和验证 JSON 文档的词汇表。
考虑到 JSON 格式与 JS 语言是天生的一对儿，而 JSON Schema 也是汇集了众多智慧的通行规范。那用 JSON Schema 来反推数据的输入方式并形成表单，也是很自然事情。
但是 JSON Schema → 表单之间显然还缺少一些东西，比如设定了最大值和最小值的数字类型，你可以用一个增加了输入限制的input（或者各种UI库的NumberInput），也可以是一个定制的滑块输入方式。
那好，我们增加一个扩展语法（当然可以通过可视化的设计器来编辑），用来指定 JSON Schema 各输入项的控件，这样是不是就能弥补了？
是的，能弥补一部分。
表单的布局呢？
生成这种布局的表单并不难，但是如果我们要把其中的一些字段放在同一行上呢？比如上图中的Activity zone 和 Activity time，我要放到同一行上。
当然解决这种情况也不难，让扩展语法支持设置表单项的宽度就好了。
那如果要让表单支持对字段进行分组，并且要为分组增加描述呢？
这里有两种情况：
一种是JSON Schema本身就是以这种结构描述的，也就是说前后端的接口定义上，基础设置、流量规则、出价和排期方案、推广对象这四组数据各自都是一个object类型。这种情况其实通过一个递归/递推结构就可以解决了。
另一种情况是JSON Schema本身是扁平的，但是为了提供更友好的表单界面，在前端人为的分组，或者同一组数据要在不同的角色的视角下要有不同的组织方式，这都是很常见也很合理的诉求。这时候扩展语法就不够用了，你需要一个独立的定义，能够对表单字段的重布局能力。
更多的问题
那要在表单项之间增加一段文字、图片甚至视频用以指导用户录入操作呢？
一个表单项要根据其他表单项联动显示和隐藏呢？
后分组的表单项要根据其他表单项联动显示和隐藏呢？
表单项需要异步检查合法性呢？
多个表单项的值要联合计算更新呢？
要做向导式的表单呢？
不可能三角
当然这些技术上都可以实现，但是回到最初的关键字“不必要的复杂性”，这里面哪些是必要的复杂性，哪些是不必要的？这里不得不考虑用户使用成本问题，复杂度到了一定程度之后，直接写代码反而效率更高。
而且平台设计的太复杂了意味着引入了更高的学习成本，这个学习成本不一定是用户愿意付出的。
对于技术人员而言，学习低代码平台中的使用是一种特定领域的知识，这种知识不能给他带来编程技术水平的提升。在上面的例子中，最初的通过 JSON Schema 来生成表单的想法无非是想借助通行的标准来白嫖一些学习成本和一些使用成本。
对于管理人员而言，做这种复杂程度的操作太耗费时间，还不如交给专业的人来做。
如果用可选的方式隐藏复杂性呢？
这也分三种实现方式：
平台把所有可能性划分等级，大多数时候只暴露最常见的部分，其他部分在打开了高级选项之后向资深用户提供。 这种做法依然有用户愿不愿意投入学习成本的问题，并且穷举所有的可能性这件事本身就是一个近乎不可能的任务。在低代码平台研发的初期，投入太多精力做这种工作显然是得不偿失的。
平台以生成静态代码的形式向用户提供无限的定制能力。 这种做法的问题是平台能力是一次性的，生成的代码被修改后，平台设计器难以将用户代码同步回来。
平台划清明确的能力边界，在边界外终极定制能力，嵌入用户代码（埋点、插件、替换）。 比如在上面的例子中用户可以直接设定一个Vue/React组件或者页面来全权接管平台的表单。在这个基础上，也许还可以把平台的实现暴露成可复用的组件，并且这个组件符合通行标准，技术人员可以把平台的实现以Vue/React组件的方式引入到自定义页面中，并通过注入插槽和为内部组件注入属性的方式来实现精确复杂的定制（但这种形式的可行性也是存疑的，毕竟依然会引入平台特有的技术特性）。
综上，低代码平台是为开发者赋能的，这种能力是快速开发一个质量稳定的应用系统的能力，但是这种能力终究是要有边界的，否则无异于重新发明一门没人爱用的通用编程技术。
3. 边界之外
低代码平台可以承托软件质量和开发效率的底限，但不一定能抬高上限。
低代码平台不能抬高上限，但也不该成为上限的天花板。
把开发者从重复性劳动中释放出来，让他们能够投入到创造性的工作中去（而不是从一种重复性劳动变成另一种重复性劳动），对于低代码平台和开发者而言都是一件幸事。
