毒瘤还是银弹 -- 低代码与传统研发模式案例对比

低代码技术最近火了，火到什么程度？火到行业大佬亲自下场打口水仗的地步。大佬们言之凿凿，吃瓜群众则看得心惊肉跳，低代码这个坑到底要不要跳，刚伸出去的脚又骂骂咧咧的缩了回来。恰巧最近看到一篇设计模式在外卖营销业务中的实践，文章 1 万 5 千字，阅读需要半小时，里面非常详细的介绍了如何基于设计模式等技术构建一套营销系统。我将用这个案例演示利用低代码工具如何完成同样的功能，从而让读者对基于低代码的研发过程与效率差异有一个感性的认识，从而获得自己的结论。

设计模式在外卖营销业务中的实践介绍了外卖营销业务里面的三个子业务，以低代码的视角来看，第一个与第三个属于一类问题，因此本文会以第一个和第二个举例，第三个省略。每个业务先介绍需求，业务模型和原做法，再介绍低代码的做法。最后是关于传统方式与低代码方式的对比总结。

邀请下单需求

“邀请下单”是外卖用户邀请其他用户下单后给予奖励的平台。即用户 A 邀请用户 B，并且用户 B 下单后，给予用户 A 一定的现金奖励（以下简称返奖）。返奖会有多个计算策略。

业务模型

对于满足返奖条件的用户，根据新老用户分类和邀新效果分为普通奖励，梯度奖和多种返奖机制。计算完奖励金额以后，需更新用户的奖金信息，并进行结算服务。

基于工厂与策略模式的原做法

将返奖规则抽象为返奖策略，将不同用户类型对应的不同返奖方案，实现为不同的返奖策略。返奖策略作为值对象通过工厂模式根据用户类型生成。下面是对应工厂模式和策略模式的设计。

原文给出的部分示例源码，贴在这里做参考。

策略与工厂定义：

上下文如何使用策略：

注：这里的 insertRewardAndSettlement 的调用写成了定义，应该是原文作者笔误。

整体使用流程：

基于流程处理框架的低代码做法

原需求是一个标准的处理流程，可以用面向流程处理的低代码框架。用低代码框架 x-series 中的流程图组件 xunit 来实现的话。只需先照着业务模型画一遍流程图，再为可视化单元关联业务代码就行。我们再复习一遍原始需求：

首先用 xunit 创建对应流程图，这里还补充了需求中没有明确说明的不能返奖流程：

虽然已经很清晰，但还是简要介绍一下处理流程：

1.      系统首先判断是否要返奖，返奖走可以返奖分支，不能返奖走遗憾通知分支；

2.      返奖分支根据用户类型进行判断，新老用户根据类型对应到不同的处理分支后，统一进行更新奖金并结算。

接下来为各个节点提供具体代码。Xunit 框架预定义了一套面向流程处理的函数式接口， 并会保证执行顺序和画出来的流程图完全一致，研发人员只需要提供整个返奖逻辑中最核心的分支判断和返奖处理逻辑即可。

为方便理解，先提供返奖流程处理的上下文

判断能否返奖，实现 Validator 接口

根据用户类型选择具体返奖处理分支，实现 Locator 接口

每个用户类型对应的返奖处理，以新用户普通返奖为例，其他用户类型类似，实现 Processor 接口：

更新奖金并结算处理略。

调用这个模块的代码如下：

返奖流程需求

业务模型

基于状态机模式的原做法

通用状态机的类图:

原文给出的状态机代码太长了，而且和返奖业务紧密耦合在一起了，为节约篇幅这里我就不再重复。

基于状态机的低代码做法

既然原需求是个状态机，那么我们就用状态机低代码框架来实现。用低代码框架 x-series 中的状态机组件 xstate 照着业务模型直接画个状态机就是我们要做的全部工作：

Xstate 会基于返奖流程的业务状态机模型和事件来自动处理状态变迁。如果状态变迁没有其他额外的检测条件，无需提供任何代码。

返奖流程状态机的使用方法如下：

看到这里，有没有一种开发也可以这么玩的感觉？

在总结低代码优势之前，我们先聊聊：

软件研发的现实

学习门槛高

原文简要介绍了传统的系统设计思想以及做法，涉及到的工作有业务抽象识别，模式选择，数据类型定义，接口设计，接口实现与逻辑整合等等。毫无疑问是好方法，但问题是概念抽象本质上是一种反直觉的思维方式，一个工程师需要大量的学习与练习才能熟练掌握。即使你懂了，你的队友也懂吗？这直接导致下一个问题。

缺少合格人员

虽然很残酷，但工作中能搞定面向对象设计的人都很少。我不否认有的优秀团队里面每个人都很强，但这是豪华配置，不是每个公司都玩得起的。绝大多数研发干的其实就是将业务逻辑翻译为代码，根本谈不上设计。那种写的又臭又长的程序我相信每位都看过，而这又导致下一个问题。

可理解性与可维护性差

可理解性与可维护性是个一体两面的概念。如果把代码比作树叶，那么系统就是森林。由于大多数情况下，除了代码，我们缺乏清晰，准确，一致的设计文档。只有花大量的时间去读源码，可以想象用这种方式去理解系统全貌会有多困难。一个无法难以理解的系统自然难以维护。

低代码的优势

学习门槛低

从上面我给出的低代码示例可以看出，低代码框架一般来说会提供可视化界面，并且产出物会和需求原貌高度一致。由于有视觉引导，学习起来非常简单，就像手机应用一般，基本上按直觉或常识操作即可。用好低代码/无代码工具的关键是要搞清楚业务需求到底可以套用那种类型的模型，以及对应这种模型有哪些可用的低代码框架。

可理解性好

好到什么程度？由于与需求原貌高度一致，即使是产品经理可以非常容易的理解并验证研发人员给出的设计是否正确。更不用谈程序员了。与此相反，基于传统方法产出的类图，时序图等设计文档，即使有，产品经理也不大可能看得懂，自然也无法有效评审。

可维护性好

可视化模型让研发人员理解系统的难度大大降低，即使很长时间不碰系统，再熟悉起来所花的时间也很少。而且在必要的场景下，这些可视化模型还能直接关联到代码，这一点对于系统的维护尤其有利，可以极大的减轻理解系统所耗费的心智负担。

其他优势

由于低代码框架本身会提供底层或编织层面的能力，开发系统仅需提供特定接口的业务逻辑，开发相同功能所需的代码量远远小于传统方式。良好的接口设计和较低代码量也方便了研发人员和测试人员开展单元测试和白盒测试。

除此以外，由于可视化模型本身具备的自解释性，使其天然具备文档属性，从而可以大幅减少手工编写文档的工作量。比较成熟的低代码框架，例如 x-series，都会直接基于模型来运行系统，无需经历基于模型生成代码这一步，也就不存在模型与实际运行代码不一致的情况，消除了文档更新维护成本。

关于低代码的思考

低代码并不是要否认传统的系统设计与开发方式。传统方式提供了一套完美的方法论，学好了当然有用。但仅仅依靠传统方式，而没有现代化的工具辅助的话是远远不够的。否则软件危机也不会一直拖到今天都没有消失。

跟传统方式相比，低代码/无代码的学习难度和研发效率在特定领域里具备明显优势，有利于大规模推广。两者的区别有点类似于弓与弩的区别，普通人想要通过练习成为弓箭高手很难，但弩的话，掌握起来容易很多。在古代，官府对民间的态度是禁弩不禁弓的，因为弓难以掌握。但当今社会，我们不应该让学习门槛成为提升效率的阻碍，而低代码就是软件工程之弩，就是银弹。

我也不认为低代码会导致能力较弱的程序员被替代，道理很简单。如果低代码都能让普通人具备开发能力，那么受过专门训练的程序员就更不在话下。而那些能力本来就很强的，用低代码/无代码只会如虎添翼，因为他们终于可以把精力集中在真正值得突破的技术难点，而不是重复性的基础建设上，这才是高手的正确用法。低代码能让高级程序员变为超级程序员，让普通程序员变为高效程序员。

不要认为用低代码就拉低了逼格，因为简化才是真正复杂的事。

参考文档：

开源低代码框架x-series

关于软件设计的错误假设