大家好，我卡颂。
你有没有发现，每过几年，低代码的概念就会被翻出来热炒一番。
这也难怪，软件行业最大的老本就是人力老本（程序员的工资），低代码号称可能：
- 用一个外包代替几个程序员
- 用产品、设计、财务人员代替程序员
- 用xxxx代替程序员
一个只有程序员受伤，还能降本增效的世界，资本怎能不爱。
概念翻来覆去炒了这么多年，为啥市面上还没呈现颠覆程序员工作形式的低代码平台呢？
明天，咱们来聊聊这个话题。
欢送退出人类高质量前端框架群，带飞
低代码，咱们聊的是一回事么？
程序员和资本眼中的低代码是一回事儿么？
对于程序员来说，低代码的概念更靠近于DSL。比方，JSX是对DOM的形象。
如果将间接书写操作DOM的办法看作代码，那么应用JSX这套DSL编写的React代码就是低代码。
因为前者是开发者面向宿主环境（浏览器）间接命令式的书写代码。
后者是开发者申明式地操作状态，React这个低代码平台再将状态变动转化为操作DOM的办法。
而对于资本来说，低代码的概念更靠近于珍妮纺纱机，有了他，就能革了纺纱工（程序员）的命。
为什么前者这种开发模式可能在业界大规模遍及，而后者不能呢？
这就要提到他们的本质区别 —— 是工具还是平台？
工具 vs 平台
工具与平台的目标都是为了降本增效，他们的区别是什么？
一个利用从开发到上线安稳经营，波及到很多工种的不同工作。
工具降本增效的形式是 —— 帮忙从事这些工作的工种降本增效，比方：
- 前端、后端框架晋升业务开发效率
Git用于多人合作时的代码治理Github Action用于欠缺CI、CD流程
而平台降本增效的形式是 —— 将工作流程、工作内容形象成模块，这样即便是在行，只有组装不同的模块，就能拼凑出一个利用。
也就是说，前者降本增效是通过进步专业人士的效率，而后者是通过以可视化的形式，升高工作门槛，让非专业人士代替专业人士。
但这里有个问题 —— 尽管平台屏蔽了软件开发的复杂度，但软件开发会遇到的问题，他也没法防止。比方：
如何应答定制化需要？
遇到依附模块组装无奈满足的定制化需要，低代码平台怎么办呢？
业界常见的解决方案是 —— 为低代码平台保留编写代码的能力。
毕竟，低代码平台的产物也是代码，只有产物代码构造清晰，程序员还是能在此基础上开发定制化需要的。
但问题是，程序员的染指，这就将低代码平台推崇的如下映射条件：
从非专业人员组装的模块到利用
变成了：
从非专业人员组装的模块到程序员的补丁代码再到利用
那这个利用的后续迭代，是不是也得程序员染指？这老本不又回来了么。
如何合作开发
当初咱们假如，有个巨牛逼的低代码平台，十分好用，极大晋升了开发效率。
老板一看，员工闲下来了，这不比股市跌了还让人好受。
于是，马上拍脑袋安顿新的需要开发。开发人员不够用了，怎么办？招人。
这些人如何在低代码平台合作开发呢？难道再把Git的概念引入平台？
如何测试
是个利用就会有bug。低代码平台再欠缺，可能解决模块本身的单测，但E2E测试谁来做？财务么？
思路要关上
上述林林总总的问题，随着我的项目复杂度回升、保护工夫变长后都会呈现。
那该如何解决呢？在这里插个眼，有缘人晓得答案请通知我。
如果解决不了，那咱们换个思路，如何能力不让我的项目复杂度回升？不让我的项目保护工夫变长？
那就限度低代码平台的利用场景，比方：
- 开发营销流动页的低代码平台
- 开发企业官网的低代码平台
让咱们思路再关上下，平台开发进去是为了卖钱的，只有用户在意识到上述问题前把钱收了，不就行了？
搞互联网的不好忽悠，那咱们能够助力传统企业数字化转型嘛。20分钟就给你搭出个官网，这转型速度，将来可期啊。
请，转账付费。
现实的低代码平台
平台型低代码很难跑通，然而工具型低代码却有很好的前景。以React举例。
在应用React前，前端开发者间接操作DOM。有了React后，业务的前端逻辑被封装到名为组件的模块中。
接下来，React提出了Server Components，组件能够在服务端运行。
这一步将业务的服务端逻辑也封装到组件中。
同时，Hooks在前端能够与视图状态挂钩，在后端能够与微服务挂钩。
这种基于组件、Hooks的低代码工具，你喜爱么？