最近在做新一年的产品规划，不可避免的就要给很多人讲一个“为什么”的问题。给技术讲这些还好，毕竟自己也是程序员，很容易就能切换到一个程序员的视角上进行一顿输出。给产品讲也不麻烦，自己团队里的人早就洗脑不止一遍了，基于洗脑的结果，新的东西其实很容易说明白。但是如果把这套东西照搬给实施销售，去解释低代码和平台规划，那大部分人是听不明白也不关心的。

不同的听众，即便是解释同一个事物，讲解的侧重点也应该有所不同。不过总有一些东西是共性的，然后再从这些共性的知识延展出去，针对性的把价值点体现出来。这就对导致自己在规划文档里写了非常冗长的一大段文字，后来虽然弄了一个更精简的版本去给内部实施讲故事，但那些长篇大论就这么删掉未免觉得可惜，毕竟这些文字在我看来还是很能说明现象背后的本质，于是就整理出来，单独聊聊为什么越来越多的toB公司都在搞低代码。

载体，价值，媒介

如果要从生产力与生产关系的角度去讨论下为什么低代码的优势，就得先搞明白载体、价值和媒介这三个概念是什么，以及在目前的互联网公司的构成元素与这三个概念的对应关系。否则就会像网络上的各种“低代码的意义”、“低代码的优势”一样泛泛而谈。

如果把一家互联网公司当作一个模型抽象，可以考虑这么来讲：一个互联网公司就是投资人购买的一台赚钱/赔钱系统，这个系统里有很多专业的人通过编写代码的方式生产业务，交给终端的客户，争取赚钱。那这个模型里，价值是业务，媒介是专业的人，载体就是代码。整理一下这句话就应该是：程序员通过操作代码来生产业务。

所以整理下来就是：

  • 媒介 -> 程序员
  • 载体 -> 代码
  • 价值 -> 业务逻辑

生产关系的革命

代码本身并无价值，它是业务表达的载体。程序员通过某种变成语言把业务逻辑表达出来，写在代码文件里，并存储在代码仓库中。既然如此，如果有另外一种可以承载业务/表达业务的载体，那么我们就可以不用维护如此大量的代码。

而代码的生产需要人与代码直接打交道。通过生产关系的角度去审视这个情况，是人与“载体”直接发生关系，于是造就了这种复杂度。

这会造成如下的限制条件：

  • 专业的人员，必须是程序员。
  • 专业的技术，必须是某种技术栈的程序员。
  • 通过标准化的互联网流水线过程进行质量的保障，必须经过多方沟通。这套功夫打下来，少说1星期，多则若干月。
    • 需求评审
    • UI设计+UI评审
    • 技术设计+技术评审
    • 进入研发（思考怎么写-各种debug-自测-联调-提测）
    • TC设计+TC评审+测试介入
    • 疯狂的debug
    • 上线+可能的线上bug
  • 不可跨越的客观事物的发展规律。比如你想让一个人1天内产生10000行有效代码并且0bug。

而搭建类产品（往大里说是低代码产品）可以跨越这种鸿沟。

低代码产品通过：

  • 对功能进行产品化抽象，形成一个个的标准组件
  • 对UI进行标准化，并支持定制化
  • 把生产代码的过程，转化为可视化的配置的过程
  • 直接免去了功能性测试和debug的步骤，因为你所有的业务表达都是基于标准功能组件和标准的UI构建出来的
  • 把上线转变为0风险的发布，平台集成的SRE功能来统一管理平台内应用运维和产品生命周期

传统生产关系中，IT部门是主导开发和维护应用程序的，而业务部门只能提出需求并等待IT部门完成。但是使用低代码平台后, 业务部门可以自主的构建和维护应用程序，这使得业务部门更加自主，并减少了对IT部门的依赖。

从生产关系的角度去审视这种不同，会发现低代码的搭建类系统，其实是在人和“载体”之间增加了一层关系，从人<-->代码之间的交互，变成了人<-->搭建<-->代码之间的交互。人不再与代码产生直接关系，于是这个人就不再限定为程序员，不懂程序但主要懂业务的人，就可以直接参与到业务生产的过程中，于是生产力进行解放。人可以自由、快速、高效、灵活的通过搭建进行业务表达。

举个例子。就像我们在汇编语言发明之前，人与机器只能通过指令与计算机交互，后来汇编语言极大增加了人与机器的交互效率，从而提高了通过计算机达到意图的效率，汇编以后有了BASIC、C/C++，后来有了解释型语言、函数式语言、解释JIT模型，各种高级语言如同雨后春笋，用Django写一个网站到上线，可能只需要1小时。这个过程里，人与机器码的距离越来越远，效率越来越高。

但人与代码的关系本身，最终会成为一种生产力矛盾，毕竟代码只是用来表达业务的载体，高级的编程语言只能提高媒介水平，让我们“生产代码”的效率提高了，但语言进化本身对于“生产业务”的效率提升是有限的。这时候人<-->代码之间的交互，就成了阻塞生产力发展的矛盾。而这种矛盾，不跳出代码和语言的范畴，是不可解决的。（我之前讨论过矛盾分为“可解决矛盾”与“不可解决矛盾”，不可解决矛盾往往具备其存在的必要性，因为这个矛盾本身就是系统的必要组成部分）比如你说，我对xxx进行了性能优化，做了xxx工具来生成dao层mapper，这都是徒劳的，不会在根本上改变生产关系，因为你无法跳出“人与代码”的范畴，这是一个世界观问题。

人<-->代码之间的交互，可以理解为一个“业务生产系统”，人和代码的矛盾，是这个业务生产系统所赖以生存的，即便人与代码间有着低效的矛盾。这是对上述“不可解决矛盾”的一种狭义解释。

当人不再与代码直接打交道，于是生产力解放。

说到“人不再与代码直接打交道”，可以再延伸一点，聪明的你一定发现了，这里的人指的是程序员，这时候问题变成了“谁与什么打交道”再加一句是“去生产什么”的问题。这个填空题应该怎么填呢？