直接被嵌入的“工作流”：才是低代码平台的毒瘤！

大家有没有想过：

1. 为什么低代码平台 不能生成代码？或者不能生成完整代码？（这会导致对企业平台锁定）

2. 为什么低代码平台 弄出了一大堆工具？还要求研发和业务共同使用这些工具和产品？

3. 为什么低代码平台 通常会有画“工作流”的工具？工作流很重要吗？

要搞清楚个问题，我给大家学习一下两个概念：“运行时逻辑”和“开发态逻辑”。

开发态逻辑：往往生成代码、需要编译、本身作为独立的程序或操作系统的一部分（不依赖其它主程序）、对代码性能要求高、需要独立考虑应用的所有部分的开发。

运行态逻辑：生成即时运行的代码例如JS（JSON例如）、不需要编译、本身依赖另一个主程序/另一个系统而运行、更注重和现有程序或数据的交互（有时候需要和人进行交互，例如BPMN、RPA、自动化测试...）。

由此可见：开发态逻辑（更底层），更适合研发人员/程序员；而运行时逻辑（应用层），则更适合业务配置员或测试人员，要求会相对低一些。 现在几乎所有低代码平台最大的问题——在产品架构时，同时使用“开发态”逻辑和“运行时”逻辑，最典型的例子就是“BPM工作流”，都被直接嵌入到低代码平台中！工作流是很重要，但是我觉得并不应该直接嵌入到“低代码”平台的底层开发逻辑中，这样可能很多事情都无法做好！（由于最早的mendix/outsystems这些都是这么设计的，大家可能就有样学样了）

直接嵌入工作流的好处，就是这部分不用开发了，因为有现成的。但是，拼接出来的东西，限制也是非常明显！ 低代码平台直接嵌入工作流的弊端：

以某家低代码平台架构为例（直接截图）

一、（见附图1）由于嵌入工作流（一般是Flowable或Activiti等成熟的开源产品）作为底层架构的一部分，而这部分一般是成熟产品，因此这部分代码其实无法生成或很难维护。（灵活性和维护都存在很大困难，代码也无法完整生成通常）

二、由于嵌入工作流，工作流通常需要使用到“人员/角色/权限”系统，因此这部分也就需要提前定义好，也就是“写死”到了低代码平台里面。导致这部分代码也很难生成，同时也降低了系统的灵活性。

三、工作流设计器，通常每个低代码平台人手一份，而且这部分还不太容易和前后台逻辑整合，因此，还需要多弄几个设计器出来...

一步错步步错，导致现在低代码平台基本就长成了“这个样”，大家也都差不多（几十家低代码平台都这个样子），就是这个原因。罪魁祸首就是 “工作流”！ 其实，也不是完全没有解决方案，就是解决方案会比较“麻烦”（见附图2） 说起来简单，其实就是用 纯“研发态”的低代码平台，再开发出一个 纯“运行时”的BPM工作流设计器，就可以了！这样所有问题都迎刃而解，代码可以全部生成（包括工作流设计器的代码），研发和业务再也不会打架！（iVX就是这么做的）