大家好，我卡颂。
你有没有发现，每过几年，「低代码」的概念就会被翻出来热炒一番。
这也难怪，软件行业最大的成本就是人力成本（程序员的工资），「低代码」号称能够：
- 用一个外包替代几个程序员
- 用产品、设计、财务人员替代程序员
- 用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」的「低代码工具」，你喜欢么？
