关于低代码和无代码---喧嚣背后的致命问题

前言

2021年的时候，刮起了一阵”低代码”和”无代码”的风，结果猪没见吹起来，风却早早停了。

在我的职业生涯中遇到了很多的低代码的构想和实现，通常他们的想法非常朴素：写代码写烦了！或者是觉得增删改查代码太没有价值，又太有规律，于是就想着用工具解决劳动重复的问题。

如果你也是这样觉得，首先还是要表扬：你确实是一个程序员，具备非常好的发现问题并解决问题的思维；如果你已经开始动手了，那么恭喜你，已经进坑了。

文章先说结论：

• 没有想清楚之前，不要做低代码，更不要做无代码。
• 投资者如果想正经投资获取回报，谨慎投资低代码，不要投资无代码。

当然，用这个练手除外。上手实践是掌握技术的必由之路。

故事

我们先从一个故事说起。很早之前还是delphi时代，那时候的最新操作系统是Windows 2000，大家最熟悉的XP还没有出来。我的一群做基金核心系统的同事们代码写烦了， 于是做了一个快速代码生成器，通过简单的配置和勾选，可以快速生成复杂的界面和增删改查功能。80%的功能可以很快出来，无论是开发还是客户都很高兴。

但是问题在于剩下的20%，这剩下的部分通常是某个复杂的业务界面，或者是系统的算法核心，并且和前后端都可能关联。 大量的精力都投入在了20%的工作上，甚至需要跳出原有的框架，用一些技巧去满足功能需求。 一句话，就是痛苦指数相当高。前面省下来的时间，可能还不够后面折腾的。让我印象深刻的是客户对我同事所在项目组工作的评价：

你们啊！把Delphi的优点做成了缺点！

所有的低代码和无代码平台都有这个问题。工作量的严重不均衡：80%增删改查爽的要死，20%的特殊功能折腾得想死。

根据”工作量转移”原理，应用程序的工作量是≥某个值的，如果某一部分的工作量变小了，肯定是把工作量转移到了其他的地方。例如spring框架封装得这么好，我们只需要编写业务代码就可以了，貌似我们简单了，但Pivotal的架构师们投入在spring上的工作量可不小了。这还是有人分担的情况。抛开框架不谈，哪怕我们集中在业务层，只要有类似业务框架这种全局影响力的部件存在，工作量转移的现象就表现得很明显。业务框架做的事情越多，开发难度就越大，但没有业务框架支持，每个业务模块的复杂度则会升高，关联会越多，最终超出管理能力，逼迫架构师去提炼业务框架。

我的老东家K有自己的低代码开发平台，并且围绕这个做成了一个生态体系，集团开发核心产品，外围供应商负责实施和二次开发。 但这个低代码的生态是一个围城，防止了外人的侵入，也把自己困在里面。我问过几个好朋友这个低代码平台对业务需求的满足率，大概在50%左右，也就是一半业务开发很快，一半业务要在这个体系之外编写代码。

我在老东家D的一个同事，独立开发了一个低代码平台。这个低代码平台的特点是用了一些”算子”概念去扩展，缺点是依然是前端和逻辑绑定太死。

这几个例子可以看出，所有的低代码平台最大的问题就是”不灵活”。

另外的一个严重问题是”没有普适性”。一个开发人员如果学习了某个X代码平台的开发技术，就意味着他用X代码平台的期间里，和开放架构是脱离的。 直白了说，这个开发人员换工作的时候会发现自己已经和行业流行技术栈脱节了。

低代码和无代码成了员工发展的绊脚石。

本质

低代码

低代码等价于DSL（Domain Specific Language，领域专用语言），马丁福勒（Martin Fowler）说DSL最重要的特征就是：

有限表达力

这是和通用语言相比最显著的特征，DSL是针对专门某个特定领域的编程语言。也就是意味着，DSL通常需要一个业务化的基础平台，并且为这个基础平台提供胶水代码。 而我们所谓的低代码，充其量就是给DSL加了一个可视化的界面。

无代码

无代码和低代码虽然只有一字之差，但是要求是天壤之别。无代码实际就是对标通用编程语言的，它要实现的是”图灵完备性”。当前市面上除了Mendix和有限几个竞品之外， 几乎所有自称无代码的产品，都实际上是低代码。 信通院2022年在整理低代码和无代码平台的标准，我在各种大佬参加的研讨会上斗胆提问了一下，发现没人意识到无代码需要和图灵完备挂钩。

无论是低代码，还是无代码，最终需要的都是元数据的描述能力。

元数据

元数据的定义是”描述数据的数据”，通俗点讲，SQL里的DDL定义的就是元数据。

CREATE TABLE table001 (
    id INT,
    title VARCHAR
)

现在元数据的描述能力还相当原始，大部分人对元数据的认知都集中在数据库建表层面。实际上，我看到目前最高的元数据是OMG组织的CWM（Common Warehouse Metamodel） 规范定义。除了字段定义之外，还有数据变换。

低代码和无代码的元数据更复杂，实际上考验的是设计者对应用程序构成的理解。目前的这些X代码产品，通常会抽象出来的应用程序元素有：

• 页面：就是对应一个一个可以看到的页面
• 控件/组件：页面上的各种元素的抽象，基本都会支持绑定一些数据
• 事件/调用：调用后台API的消息，也有扩展成可以调用非后台API
• 算法：独立的算法或业务逻辑。通常会支持第三方定义

其他还有很多产品特有的概念和术语，然后把这一切糅合起来，就以为可以描述一个应用程序了。我很怀疑他们是否真的收集到了足够的用例，并对他们设计的架构做过充分的验证。

现在元数据最大的问题就是

描述能力不足

展望

对于西门子的Mendix无代码平台来说，最好的一个广告就是特斯拉使用Mendix用4个月编写完成了一个ERP。 看到这个新闻的时候我只想说一句话

那是因为Elon Mask不是中国人，换个中国甲方试试！？

国内的几个大厂的低代码/无代码平台，做一些促销表单应该是没问题的。但是真正要达到替代应用程序的境界，难！

如何判断一个X代码平台是否有足够的能力？只需要去看他们的数据结构定义功能，只有元数据能力上来了，才有提升的机会。否则，只是靠几个牛人拍脑袋想是没用的。 他们至少需要一个博士，去证明元数据模型的图灵完备性，否则做啥无代码？

这才是要点。

附加

目前加速代码编写的工具不少，但是我只用一个工具JHipster，用它生成代码，然后自己改。这个又是一个很好的故事，我们下次聊。