共计 1671 个字符，预计需要花费 5 分钟才能阅读完成。
大家好，我卡颂。
你有没有发现，每过几年，低代码 的概念就会被翻出来热炒一番。
这也难怪，软件行业最大的老本就是人力老本（程序员的工资），低代码 号称可能：
- 用一个外包代替几个程序员
- 用产品、设计、财务人员代替程序员
- 用 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 的低代码工具，你喜爱么？