关于前端低代码的一些个人观点

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

刚好笔者最近正在开发一个B端低代码的平台。所以，想把这段时间的感悟整理一下与大家分享一些。不过，开头先声明一点，本文只聊观点与感悟，不聊具体技术细节。低代码的产生背景互联网产品趋于标准化据我观察，有相当一部分的程序员一提起低代码就摇头say no，表示曾经被这些低代码平台“伤害过”，因为产品需求一旦涉及平台暂不支持的功能，轻则导致加班返工，重则绩效堪忧，甚至丢了工作。这是一个新事物发展初期必经的一个阶段: 与现有环境水土不服。假如站在更高的角度，设想一下: 当有一天，你的老板宣布，产品经理以后提的需求一律不得超出低代码平台支持的能力范围时，该作何感想。不要轻易说不可能，因为资本的本质就是追逐利润，假如由于这些非标需求额外付出的开发成本，创造不了预期的收益，那对那些试错成本宽容度较低的团队而言，这些需求完全没有存在的必要（回头想一想，你的产品经理提的那些奇奇怪怪且上线没几天就又改回去的需求，你真的认为有价值嘛）。了解点软件外包行业的都知道，很多外包订单都是先copy一个个的模版项目，在之上稍加改动即可交付。因为和他们对接的大部分客户需求都很标准化。比如，客户需要开发一个H5商城，商品、订单、物流再加一个商品运营后台就完全可以满足需求了，甚至不在意UI的样式与竞品一模一样。不过这里也不排除有定制化开发的报价相比完全套模版会高出一大截的因素，但这也至少说明这些非标需求是锦上添花的功能，根本不是刚需。其实大厂也有这个趋势。毕竟各厂的业务范围越来越出现交叉的态势，产品层面也都是互相copy，真正具有创新性的产品越来越少。C端的产品，尤其在一些大厂充分竞争或者优势的业务领域，因为要追求UI设计、交互、产品体验的差异性，所以相对不容易标准化。比如每年双11的促销各家要紧跟潮流，玩法每年都不尽相同，这种就很难标准化。但大部分的B端产品，对定制化要求不高，随着产品形式的固化，用户已然形成了一套约定俗成的交互习惯。应用开发的技术栈趋于成熟就拿前端出活的主力:js框架来说，vue、react虽然还在大版本的迭代，但对整个开发方式的影响，已经不足以与15、16年jQuery到现代框架的那种革命性相提并论了。更多是一些类如更灵活的逻辑拆分、服务端渲染等方面的优化。针对前端开发中的痛点，拆分出的比如构建工具、前端框架、框架之上的UI组件库、跨端等等各个技术领域的边界，也都划分的比较明确了，且发展日趋成熟。这是前端低代码出现的技术背景。前端低代码实现笔者对低代码的理解是: 可以通过配置化的低成本交互方式（主流是拖拽）加上少量的一些胶水代码，去满足一类应用的需求。这里笔者以发展更加成熟的B端低代码讲述，C端也是很类似，但是因为样式、动画等定制要求要比B端的复杂许多，所以目前前端低代码相对成熟的应用是在B端。低代码实现原理其实非常简单，就是先预置丰富的原子组件，通过拖拽选择所需组件在画板上进行位置的编排。之后，进行一些组件属性的设置。

最终生产出一份jsonSchema或者供开发者二次开发的“源代码”，驱动用户端的内容渲染。原理虽然简单明确，但它也有一些实现难点。比如以下几种：一、宏观设计首先设计一个能够面向不同业务场景的低代码项目，是个不小的挑战。
比如一个公司级别的低代码项目，目标是赋能各条业务线。这个就会有一个问题：每个业务对低代码平台的能力要求是不同的，除了大量可复用的功能，肯定也会有不少的定制化需求。甚至各条业务线的产品形态很不一致，有面向C端的，有面向B端的。如果是中心化的思想，一套低代码平台，满足各业务线的需求，首先人力成本很难均摊下去，其次平台随着接入业务线增多，不可避免的会变得臃肿不堪，难以维护。如果每个业务线都独立做一套符合自身业务特性的低代码，这样难度会降低不少，但也意味着公司级别的低代码物料复用变得困难。
讲下业界目前比较流行的解决方案：在公司级甚至业界推动低代码协议统一。这样就让跨业务甚至业界的物料复用变得可能，阿里前端委员会为此付出了不少努力，大家有空可以了解下。将低代码架构分层。先有一个低代码基础架构，再用它去“生成”一个个面向具体业务场景的低代码平台。那么如何设计好这个“生成低代码平台的低代码平台”就成为了重中之中。这有点类似于低代码“中台”与“前台”的关系。二、实现细节事件编排下图就是目前最常见的一种设计，可以配置点击一个button时，要触发哪种类型的事件，事件触发要调用哪些函数，一般都会内置一些比较常见的函数，比如打开一个Modal框等。如果内置不满足需求，就需要插入一些定制化的代码。状态联动这个相对好解决一些。 阿里的formily、x-render、jsonschema-form等这些成熟方案的都能够解决，他们之间的差异更多的是在联动性能上，不过这也是在超长表单场景下差距才会比较明显。以下是阿里lowcode-engine的交互设计。

这个平台内置的相对简单。我接触过的内置相对丰富的是iofod这个全场景低代码平台，这里为他们的开发者打个广告。笔者还与他们的开发者加了好友，吃惊的是这么大的工作量竟然是一个人完成的，体验下来比很多公司团队级的产品都用心。

异步数据绑定传统的前端开发大量时间其实是花在与后端接口的对接上，这些工作在目前前端低代码的开发模式中，一点都不会少。如下图，你需要一个表单回填的功能。后端给的详情数据，与前端表单需要的格式差异很大，这里就不得不去手写一个转换函数去解决。

这也是低代码平台大家诟病最多的一点，即：还是需要写代码。但是低代码的价值，从来就不是追求一行代码不写，而是让开发者尽量的少写代码。有人说，我copy代码其实来的更快，而且这功能我开发起来很熟，代码不会有任何问题。但是，你是不是经常在提交cr之后，又悄悄的commit了几个fix呢。最可怕的是测试也觉得这功能很常见，不用细测了，将隐患带上了线。试着回顾一下过往项目的bug列表，是不是很多都是因为不经意的走神或者疏忽造成的。这就是低代码目前就能够解决的一个问题，通过内置一些常见的功能，减少常见功能的开发、测试成本。使大部分功能的交付质量，不依赖于某一个开发者在某一段时间的开发经验、精力及水平。这是笔者认为，现阶段低代码技术的最大价值。