低代码工具选项难题浅析
X-Series 是从 2012 年就开始研发并开源的一套低代码框架。在对 X-Series 社区长年的支持过程中，我发现一个有趣的现象，就是虽然这两年低代码彻底火起来了，产品也很多，但很多研发人员在选项时却发现很难找到完全令自己满意的，直到尝试 X-Series。最近刚好和一个在推广过程中遇到困难的低代码产品研发团队做过交流，我觉得这本质上是个低代码产品定位和设计导致的选型问题，有必要解读一下。
先直接说结论，目前绝大多数低代码无代码工具比较适合 0 到 1 的场景，但对 1 到 10，或 10 到 100 的场景就不一定很给力。那些找不到合适工具的往往是处在 1 到 10 或 100 的场景里，并希望利用的代码技术提效的研发人员。而 X-Series 之所以适用，是因为其最开始就是为了解决后者的问题才研发出来的，并且在设计上做了非常周全的考虑。
先解释一下什么叫 0 到 1 的场景，就是有了一个初步的想法，在没有任何系统的前提下，想快速低成本建设一个。这个时候的需求往往很简单，仅需要一些简单的页面来展示，修改和保存数据就可以满足。即使是非专业人员，也可以在合适的工具帮助下独立完成。这正是绝大多数低代码无代码工具的市场地位，既面向普通人的开发工具，能快速构建包含页面和后台数据读写功能的简单系统。
什么叫 1 到 10，或 10 到 100 的场景，就是系统已经复杂到需要一个独立的后台。此时建设重点和难点已经不是构建页面或读写数据，而是如何应对日渐复杂庞大的后台系统。这种后台系统往往对应着庞大的代码库，具备复杂的静态与动态结构，难以理解和维护。普通人即使有再强大的工具也根本插不上手，只有专业的软件研发人员才能胜任。
在后面的场景里，工作重点已经不再是构建页面和读写数据，因此只能构建页面和处理数据的这一类低代码无代码系统往往就会力有不逮。此时必须寻求具备后台处理能力的低代码无代码系统。目前市面上具备后台逻辑构建能力的低代码工具对后台逻辑的处理一般有三种做法：
试图将后台逻辑吸收进前端页面中。既通过增加对编程语言的支持，将本属于后台的逻辑塞入事件响应代码。编程语言一般选 JS，讲究一点可能是类 Java 或某种自研的语言。如果逻辑不算很复杂，开发者又没什么设计洁癖，也不失为一种方案。
通过外部调用的方式，将后台逻辑抛给其他系统处理。
提供某种试图完全替代编程的流程模型来实现后台逻辑。
方案 1 很明显无法适应真正复杂的系统，因为如果真的将逻辑都堆到页面，其实是倒退回两层 CS 结构的老路。这种开历史倒车的做法，只会导致问题在后期越来越大。方案 2 本质上是放弃了做成一个大而全的工具的企图，将自身仅定位于前端页面构建，并不准备面对后台逻辑处理问题。这两种方案显然都不理想。
方案 3 貌似是个很好的办法，并且实现一个流程图编辑器在技术上似乎也不复杂。但事实上方案 3 实现的难度极大，因为很难设计出一个既能够完全覆盖代码的能力，又能同时在使用效率和可视化表达的简洁性方面表现出色的流程模型。绝大部分此类尝试要么必须简化或放弃很多代码能做到事情，要么搞成图形化编程。前者会导致场景覆盖不全，后者的实际使用效率极低，与纯编程的方式相比完全没有优势。下面就以前面提到的团队的低代码产品作为例子说明一下。
他们自研的低代码工具是基于网页的图形化开发环境，能快速搭建前端页面，并支持用流程图构建后端逻辑。工具的定位是即支持前端也支持后端。按理说功能覆盖齐备，但推广过程却很不顺，即使是公司内部，也没几个人愿意用。他们不太明白问题出在哪里？在听完他们的介绍和演示后，我脱口而出的第一句话是：你们几乎把能犯的错误全犯了。
首先是抽象粒度不对。以流程图为例，他们的流程图里面的每一个步骤对应于一个可配置组件，组件是由专门的组件研发人员提供。业务研发人员通过选择和配置组件来构建流程图。这种方式其实就是图形化编程。图形化编程中的每个步骤对应的是传统编程方式中的一句或几句完整的代码，因此组件的粒度其实就是在语句之上，方法之下。而一个完整的流程图对应的是传统编程方式中的一个方法调用。对于一个熟练的程序员来说，拖拉组件并配置相关属性，例如 SQL 语句片段，URL 等，来实现一个方法的功能，比在 IDE 的辅助下直接手写慢得多。而在维护的时候，通过查看组件的各种配置项来理解系统比直接看完整的代码多了一个内心再加工的过程，因此也低效得多。这就是为什么这么些年来，图形化编程仅仅只在少儿编程等对效率没有要求的场景里存在。
其次是过高的开发环境切换成本。基于网页的开发环境要求预先开发并注册好组件，研发人员无法像在 IDE 里面一样随时从组件进入代码。这点非常致命，因为仅看组件的介绍配置是无法获得跟看代码一样的对组件的理解的。当缺乏这种理解时，研发人员要么不敢用，要么用错，总之是不敢放心大胆的使用。并且在实际工作中，组件的开发者和使用者往往可能是同一个人，那么当发现组件设计需要改动时，他必须退出 WEB 开发环境，进入 IDE 里面开发并部署好组件，再切换会回 WEB 继续去使用组件。这种频繁打断心流的切换操作，会让研发人员非常反感。
最后是工具本身定位不准。听完他们的介绍我的感觉是他们的工具最适合的使用场景是让专业的前端去开发后端，或者专业的后端去开发前端。而事实上前后端技术的差异到今天已经如此之大，研发人员没有经过长时间的培训几乎无法开展相关工作。稍具规模的公司都会建立独立的前端与后端团队并专注在各自领域。而他们的工具在专业的前端眼里不够强大，在专业的后端眼里又不够高效，而让前端开发后端，或后端开发前端在有专业团队的情况下显得完全没有必要。综上，这个工具到底准备给谁用是个非常尴尬的问题。
上面案例分析说明了即使是自研，也很容易掉进坑里。上面这些产品设计与定位的问题应该是普遍存在的，这就是为什么很多研发人员在调研过程中很难找到真正让他们满意的工具。
此外一般的低代码无代码系统往往从解决页面构建入手，逐渐扩展到后台逻辑层面。这虽然是一个从简单到复杂的一般路径，但很容易把解决前端问题的思路照搬到后端，例如前端的构建过程往往是现在在页面中放置布局管理器和组件，再对两者进行配置，这在前端是可行的做法，因为这种配置变更会立即以可视化的方式反馈到编辑页面。但对后端组件而言，配置的变化是无法直观的在流程图等图形模型中表达出来的，因此简单的照搬前端的解决思路大概率会碰壁。
要为后台逻辑提供低代码无代码解决方案，必须真正理解后台的问题是什么。那么什么是后台面临的真正问题，主要有三点：
如何理解和维护后台处理系统。一个前台请求是如何被后台系统处理的，各模块之间的调用顺序，整体的结构是怎样的。本质是如何高效的建立后台系统的心智模型。传统方式就是死读代码，但是 1 千行代码可以读懂，1 万行，10 万行咋办？
如何理解和维护复杂的逻辑判断。系统中总会存在某些跨度大，层次深的巨大的 if-else 树，非常难以理解，维护以及测试，这是个问题，不是吗？
如何正确处理数据模型在不同状态下的更新。例如订单，商品，货物等业务数据，会在生命周期中不断根据外界变化和自身状态来做出改变，其复杂性体现在根据当前状态做判断和触发后继处理。
X-Series 就是为了解决上述这些后台问题而诞生的，它包含 3 个独立工具，xUnit 用于构建清晰的后台系统；xDecision 用于表达复杂的判断逻辑；xState 用于管理复杂的状态变迁。X-Series 面向的是专业的后端研发人员，目标是高效构建可理解，可维护的后台系统。为了最小化落地难度，X-Series 被设计得非常轻量级。每个工具都仅包含用于可视化编辑的 IDE 插件和独立 maven 运行时依赖 Jar 包。研发人员利用插件在 IDE 中以可视化的方式编辑模型文件，并以 XML 格式保存到本地项目的 resource 目录下。模型可以和项目一起打包，通过运行时直接调用。运行模型不需要生成任何代码（xDecision 可选是否要生成测试代码），不依赖任何后台，不依赖第三方 SaaS 服务，也不需要数据库。工具间无任何依赖，可以按自己的需要单独或组合使用。
xUnit 基于流程图模型构建后台系统，流程图节点对应的代码粒度是函数类，即包含一个完整方法的模块，而不是一两条语句，因此可以用方法而不是语句的效率构建系统。利用集成在 IDE 中的可视化编辑器，研发人员可以随时从节点跳转到代码，从而可以在基于流程图的抽象层面和具体代码层面平滑切换，而不会迷失在代码海洋中。有了 xUnit 相当于有了一张系统蓝图，再也不用靠苦读代码来建立对系统的认知。
xDecision 基于决策树模型来构建复杂判断，节点和路径支持表达式。对决策树的创建维护完全在模型中，如果事实变量和决策集合没有改变，则模型变更时无需改动主程序。xDecision 还支持生成测试代码，用于快速检验模型的正确性。
xState 基于状态机模型来构建业务对象的状态模型，支持状态变迁校验和事件处理调用。无论业务模型的状态有多复杂，都可以用状态图清晰的表达。同 xDecision 类似，如果事件和状态集合没有变化，修改模型后无需改变调用程序。
X-Series 效果如何，看看最近一个用户反馈吧
如果准备搭建或已经据具备一定规模的后台系统，希望利用低代码提高后台系统的研发效率，并同时满足可理解性，可维护性，那么 X-Series 是最佳选择。如果同时还有前端页面研发需求，完全可以同时既用 X-Series，又用其他擅长页面构建的低代码无代码工具，从而各取所长。如果是 0 到 1 的场景，并且不准备搭建后台，那么市面上大多数低代码无代码工具都可以满足，没必要用 X-Series。
在 X-Series 的推广中我发现那些非常了解研发痛点的资深后端研发或研发管理人员都非常认同 X-Series。他们往往是在技术选型过程中发现并主动学习和使用 X-Series 的。有人反馈说之所以 X-Series 对自己胃口，主要是因为只有后端程序员才真正理解后端研发的痛，才能研发出适合的工具。
参考资料：
开源可视化系统构建工具x-series作者 2020-06-09 加入
还未添加个人简介
评论