React：搞了半天，我才是低代码的最佳形态

出处：魔术师卡颂（ID：gh_52d0bec584f9）

你有没有发现，每过几年，「低代码」的概念就会被翻出来热炒一番。

这也难怪，软件行业最大的成本就是人力成本（程序员的工资），「低代码」号称能够：

• 用一个外包替代几个程序员

• 用产品、设计、财务人员替代程序员

• 用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」的「低代码工具」，你喜欢么？