低代码平台设计的边界问题

ainio

　　最近在研发低代码平台产品，研发的过程中的一些思考在这里记录一下。[b][url=http:///www.dimaxq.com/]低码星球[/url][/b]的内容欢迎详细阅读下文，也可以到网站了解，作为业内的标杆企业和网站，我们会安排专业人士为您解答，让您更了解！

                               
登录/注册后可看大图

　　与低代码（low-code）相对应的几个概念：

　　低代码平台面向不同的领域也有不同的细分，本文以我正在研发的企业经营管理领域的低代码平台为主要讨论对象。

　　以上三种用户其实可以归为两类，一类是有一定编程能力的技术人员，一类是没有编程能力的管理人员。

　　这里一定要强调技术人员是“有一定编程能力”的，而不是超高编程能力的，因为超高编程能力的人也许不愿意受到平台的束缚，他们更愿意用库来搭建自己的系统。

　　而管理人员既是管理系统的用户，也是管理系统需求的源头，如果能够让他们通过平台对管理系统进行一些简单的定制（如字段级的调整）能够节省大量的沟通成本。

　　这两类用户在平台的视角下，都是一个最终系统的开发者。

　　概括来讲低代码平台是为用户赋能的。

　　何为赋能？这里的赋能不同于管理学和心理学中的概念，在这里是”赋予能力“的意思：平台为用户提供开发应用的能力。

　　这种能力注定是有局限性的，因为无论何种低代码实现，都是在提炼经验的基础上隐藏“不必要”的复杂性，而这个“不必要”是在特定领域中基于"经验“的共识。这个“不必要”并不能通过纯理论检验，也就是说总会有“黑天鹅”的。

　　举例来说，通过 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 来生成表单的想法无非是想借助通行的标准来白嫖一些学习成本和一些使用成本。

　　对于管理人员而言，做这种复杂程度的操作太耗费时间，还不如交给专业的人来做。

　　如果用可选的方式隐藏复杂性呢？

　　这也分三种实现方式：

　　综上，低代码平台是为开发者赋能的，这种能力是快速开发一个质量稳定的应用系统的能力，但是这种能力终究是要有边界的，否则无异于重新发明一门没人爱用的通用编程技术。

　　低代码平台可以承托软件质量和开发效率的底限，但不一定能抬高上限。

　　低代码平台不能抬高上限，但也不该成为上限的天花板。

　　把开发者从重复性劳动中释放出来，让他们能够投入到创造性的工作中去（而不是从一种重复性劳动变成另一种重复性劳动），对于低代码平台和开发者而言都是一件幸事。