前言
2021年的时候，刮起了一阵”低代码”和”无代码”的风，结果猪没见吹起来，风却早早停了。
在我的职业生涯中遇到了很多的低代码的构想和实现，通常他们的想法非常朴素：写代码写烦了！或者是觉得增删改查代码太没有价值，又太有规律，于是就想着用工具解决劳动重复的问题。
如果你也是这样觉得，首先还是要表扬：你确实是一个程序员，具备非常好的发现问题并解决问题的思维；如果你已经开始动手了，那么恭喜你，已经进坑了。
文章先说结论：
- 没有想清楚之前，不要做低代码，更不要做无代码。
- 投资者如果想正经投资获取回报，谨慎投资低代码，不要投资无代码。
当然，用这个练手除外。上手实践是掌握技术的必由之路。
故事
我们先从一个故事说起。很早之前还是delphi时代，那时候的最新操作系统是Windows 2000，大家最熟悉的XP还没有出来。我的一群做基金核心系统的同事们代码写烦了， 于是做了一个快速代码生成器，通过简单的配置和勾选，可以快速生成复杂的界面和增删改查功能。80%的功能可以很快出来，无论是开发还是客户都很高兴。
但是问题在于剩下的20%，这剩下的部分通常是某个复杂的业务界面，或者是系统的算法核心，并且和前后端都可能关联。 大量的精力都投入在了20%的工作上，甚至需要跳出原有的框架，用一些技巧去满足功能需求。 一句话，就是痛苦指数相当高。前面省下来的时间，可能还不够后面折腾的。让我印象深刻的是客户对我同事所在项目组工作的评价：
所有的低代码和无代码平台都有这个问题。工作量的严重不均衡：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
)