2022，低代码彻底火了，甚至火到没有点相关经验，都不好意思出去面试的程度，堪称lowcode“元年”。在整个互联网大裁员的背景下，无论你是否相信它是降本提效的利器，彷佛都不重要了。因为行业趋势总是这般浩浩荡荡，是不以个人意志为转移的。从下图某技术峰会的分享主题中就可见一斑。

image.png

刚好笔者最近正在开发一个B端低代码的平台。所以，想把这段时间的感悟整理一下与大家分享一些。不过，开头先声明一点，本文只聊观点与感悟，不聊具体技术细节。

01

低代码的产生背景

互联网产品趋于标准化

这是一个新事物发展初期必经的一个阶段: 与现有环境水土不服。假如站在更高的角度，设想一下: 当有一天，你的老板宣布，产品经理以后提的需求一律不得超出低代码平台支持的能力范围时，该作何感想。不要轻易说不可能，因为资本的本质就是追逐利润，假如由于这些非标需求额外付出的开发成本，创造不了预期的收益，那对那些试错成本宽容度较低的团队而言，这些需求完全没有存在的必要（回头想一想，你的产品经理提的那些奇奇怪怪且上线没几天就又改回去的需求，你真的认为有价值嘛）。

了解点软件外包行业的都知道，很多外包订单都是先copy一个个的模版项目，在之上稍加改动即可交付。因为和他们对接的大部分客户需求都很标准化。比如，客户需要开发一个H5商城，商品、订单、物流再加一个商品运营后台就完全可以满足需求了，甚至不在意UI的样式与竞品一模一样。不过这里也不排除有定制化开发的报价相比完全套模版会高出一大截的因素，但这也至少说明这些非标需求是锦上添花的功能，根本不是刚需。

其实大厂也有这个趋势。毕竟各厂的业务范围越来越出现交叉的态势，产品层面也都是互相copy，真正具有创新性的产品越来越少。C端的产品，尤其在一些大厂充分竞争或者优势的业务领域，因为要追求UI设计、交互、产品体验的差异性，所以相对不容易标准化。比如每年双11的促销各家要紧跟潮流，玩法每年都不尽相同，这种就很难标准化。但大部分的B端产品，对定制化要求不高，随着产品形式的固化，用户已然形成了一套约定俗成的交互习惯。

应用开发的技术栈趋于成熟

就拿前端出活的主力:js框架来说，vue、react虽然还在大版本的迭代，但对整个开发方式的影响，已经不足以与15、16年jQuery到现代框架的那种革命性相提并论了。更多是一些类如更灵活的逻辑拆分、服务端渲染等方面的优化。针对前端开发中的痛点，拆分出的比如构建工具、前端框架、框架之上的UI组件库、跨端等等各个技术领域的边界，也都划分的比较明确了，且发展日趋成熟。这是前端低代码出现的技术背景。

02

前端低代码实现

笔者对低代码的理解是: 可以通过配置化的低成本交互方式（主流是拖拽）加上少量的一些胶水代码，去满足一类应用的需求。这里笔者以发展更加成熟的B端低代码讲述，C端也是很类似，但是因为样式、动画等定制要求要比B端的复杂许多，所以目前前端低代码相对成熟的应用是在B端。低代码实现原理其实非常简单，就是先预置丰富的原子组件，通过拖拽选择所需组件在画板上进行位置的编排。之后，进行一些组件属性的设置。

image.png

最终生产出一份jsonSchema或者供开发者二次开发的“源代码”，驱动用户端的内容渲染。原理虽然简单明确，但它也有一些实现难点。比如以下几种：

一、宏观设计

首先设计一个能够面向不同业务场景的低代码项目，是个不小的挑战。比如一个公司级别的低代码项目，目标是赋能各条业务线。这个就会有一个问题：每个业务对低代码平台的能力要求是不同的，除了大量可复用的功能，肯定也会有不少的定制化需求。甚至各条业务线的产品形态很不一致，有面向C端的，有面向B端的。

如果是中心化的思想，一套低代码平台，满足各业务线的需求，首先人力成本很难均摊下去，其次平台随着接入业务线增多，不可避免的会变得臃肿不堪，难以维护。如果每个业务线都独立做一套符合自身业务特性的低代码，这样难度会降低不少，但也意味着公司级别的低代码物料复用变得困难。讲下业界目前比较流行的解决方案：

1、在公司级甚至业界推动低代码协议统一。这样就让跨业务甚至业界的物料复用变得可能，阿里前端委员会为此付出了不少努力，大家有空可以了解下。

2、将低代码架构分层。先有一个低代码基础架构，再用它去“生成”一个个面向具体业务场景的低代码平台。那么如何设计好这个“生成低代码平台的低代码平台”就成为了重中之中。这有点类似于低代码“中台”与“前台”的关系。

03

低代码对行业的影响

框架、类库的作者也许会喜闻乐见

04

自上而下的推动最有效

• 前端开发模式换用低代码之后，UI及产品经理如果还是按照原先对你的期待去要求实现效果。这肯定会造成一些难解的冲突与麻烦。他们也许会认为这个开发最近肯定偷懒了。以往像让某个按钮变个颜色，换个位置这种轻而易举就能答应的事情，现在要思索很久或者直接给个此功能无法支持的回复，这显然不符合产品方的利益。

• 前文提到，如果只是前端开发模式换用低代码，而后端的字段约束，返回格式还是像以前那样的随意，肯定会造成低代码平台上需要处理前后端交互兼容的地方越来越多，这就导致可维护性大大降低。有人说这里可以用node做一个BFF层的接口格式转换，但这种方式也只是换了个地方写兼容代码，治标不治本。

05

会造成失业吗

一定会造成一部分失业。是的，笔者对这个问题表现的偏悲观一些，或者说，更理性一些。针对这个问题，我也询问过很多身边的同行，有一部分说根本不会造成程序员失业，他们给出常见理由如下：

1、低代码平台是用来帮助开发者从日常繁琐重复的工作中解放中，去做一些更有价值的事情。是一件双赢的事情，怎么会失业呢？

不看好目前的低代码创业

06

总结

原文地址：https://juejin.cn/post/7131801252500865055

原文作者：郑鱼咚