低代码平台 - 危险的赌注

低代码应用平台（LCAP - Low Code Application Platforms）在多样、复杂的现代软件开发情势下应运而生。根据 Gartner 的数据，Mendix 是这方面的翘楚，但其实类似的分析也适用于 Outsystems、Appian、Kony、Betty Blocks 以及其他低代码平台。

在向企业高管营销时，LCAP 们会号称业务人员（也有说市民开发者，非专业开发者）就能构建企业级的解决方案。那么，后来专业开发人员都失业了吗？我们知道并没有，反而几年后 Mendix 推出了面向专业开发者的版本：

我猜测 Mendix 后来也意识到任何比基本的增删改查复杂的事情都需要一个软件工程师，就好像除了给轮胎打气之外的汽车维修工作都是需要专业人员一样。

那么，长期依赖低代码平台对业务业务发展来说，究竟有何利弊，下面我们将做一些分析。

非常适合原型开发

事实上，低代码平台对开发简单的自动化商业流程、或者交付可运行的原型系统来说，是业务开发人员不错的选择。在一个可视化的设计器中定义数据模型，使用内置的组件、模板来设计脚手架交互 UI，甚至可以使用特定的工作流组件描述业务逻辑，例如 Mendix 使用的 microflow：

完成之后，可以将配置好的应用一键部署到低代码的云上运行（低代码一般都有云服务）。看上去简单并且易操作，很多时候，这种神奇的演示会让高管愿意买单。

但是，当你的系统从原型阶段升级到真正的业务阶段时，用户交互和业务逻辑会不可避免的越来越复杂。为了避免把系统搞得一团糟，此时，你亟需一个专业工程师来继续推进项目。

那么，从专业开发人员的角度看，又如何呢？

低（慢）代码

以 Mendix 为例，使用时，任何逻辑（包括计算和用户交互）都需要用一个 microflow 来描述，如上节中的图示。这里就有一些问题。

首先，想象一下，拖动、配置，然后将十几流程环节连接起来，不但繁琐，还容易出错，相比同样的逻辑，开发者只需要在好用的 IDE 里敲十几行代码，相比之下，低代码反而成了慢代码。而业务规模上去以后，你的 microflows 不可避免的多到难以管理。

其次，可读性。这种流程图看上去很不错，但是第一个框框里的 Sub_RegistrationValidation 呢？不跟进去根本无法阅读。

权宜之下，Mendix 提供了 Java Action。你可以在一个 microflow 中调用 Java 方法（但是由于云部署的限制，对这些 Java 方法也有严格的限制）。它支持在 Eclipse 中编写 Java 代码，尽管更多人选择更优秀的 IntelliJ IDEA。另外，代码的透明度也是一个风险 - Java 代码的入口都在 microflows 中，所以调试、跟踪都变的复杂了，逻辑和流程分散在两处。

最后，在版本控制方面，Mendix 提供了基于 Subversion 的版本控制（开发者熟悉的 Git 还处于 Beta 阶段）。

低技术要求

业务人员即可完成系统的配置，降低了对技术的要求。对业务主管来说可能很不错，不再需要昂贵的、难找的专业开发者了。但事实可能不是这样。当你真的需要一个专业开发人员时，就会苦恼如何找到一个好的开发人员，因为对于专业的工程师来说，使用低代码平台意味着职业生涯的结束。

不可控

任何熟悉 Java 生态的人都不会低估开源的能量。当有一个异常抛出时，你能看到发生异常的代码，也能通过调试来看发生了什么，你能 Baidu，也能提一个 PR。最坏的情况下，你可以 fork 整个开源项目。这些都是可控的。

而使用低代码平台，这就不用想了。低代码平台是一个商业权属的产品，对使用者来说，调用栈完全不可见。一旦出错，只能选择付费的售后支持，或者祈祷在某个讨论群有人遇到过同样的问题。无论是付费支持或者讨论群，这种方式对知识并没有形成积累（或许是不愿意将产品的暴露的问题留下证据？），这与打开搜索引擎直接粘贴 Java 调用栈然后敲回车的体验可差远了。

供应商锁定

使用低代码的一个关键问题是，你实施的业务逻辑运行在供应商提供的产品内。由于供应商使用的特定数据库、特定流程组件、特定的业务逻辑编写方式，所以很难将已有业务迁移至其他平台。

Mendix 可能是被经常问到这个问题，他们发布了一篇文章来解释如何解除锁定。其中提到了，你可以拿到你的数据、SQL DDL，UI 资源和 Java 代码（microflows 可以神奇地转为 Java 代码）。但是，这些代码可以脱离 Mendix 的运行库和 API 独立编译或者运行吗？很显然不行，你需要自己重新编写系统运行的框架，你拿到的，仅仅是你原来就有的模型和业务逻辑。因此，基于低代码平台构建的系统，系统本身并不属于你，你有使用权，而无所有权。

扩展性受限

Mendix 的目标客户是大型企业，所以“扩展性”在他们的市场材料中被多次提及。2017 年他们引入了“stateless runtime”的概念，并支持业务节点的集群部署，所有会话信息既存在客户端，又持久化到数据库。理论上，业务节点的横向扩展将没有上限。听起来很棒，但有一个问题 - 数据库。

数据库通常是企业级应用的瓶颈所在。在集群的无状态 Mendix 服务后面是用什么在存储数据呢？就是关系型数据库。Mendix 使用的是 PostgreSQL。在集群部署的架构中，要求所有的业务节点都连接至同一个数据库。

如果控制权在自己手里这样也可以接受。Oracle 及其他数据库已经证明了 RDBMS 是可以横向扩展的，可以优化 DB 结构、缓存数据或者使用 Citus 这样的方案来做扩展。但问题是使用低代码平台后，数据库并没有掌握在你的手里。最终，平台的扩展性上有所限制并且无法提供对性能进行微调的参数。

价格

最后还得说一下价格问题。由于低代码平台涉及的开发量很小，因此，一般都是以系统的用户人数和部署方式收取授权费用。公有云部署相对便宜，私有部署相对昂贵。对于几千内部用户的大型企业，每年的费用要超百万。而这个费用，仅仅只能算是使用费或者租赁费。

LCAP 的流行

通过上述分析，我们可以看到，低代码平台的缺点应该说是远远大于能提供的便捷性的。但是为什么 LCAP 还是那么流行，甚至一度站上创业的风口呢？

在大型企业机构中，对专业软件工程师团队的管理（不论是内部团队，还是外包团队），目前看来有些过于复杂。由于需要软件团队负责不同部门、不同系统的实施，而交叉管理的技术负责人和项目负责人又有各自的预算和任务优先级，造成工作互相推诿、或者难以合作，最后导致各自的想法都很难实施。而有意思的是，面对这种复杂的情况，高级管理人员的下意识对策是招聘更多的开发人员和一线经理。毋庸置疑，情况会越来越糟。最后，企业高管会因此寻求那种神奇的、能解决所有问题的解决方案，比如，低代码平台。

如何避免这种情况的出现不是本文需要讨论的内容。但这也只是一个管理问题，而非技术问题。团队管理的最终结果如果能让 3~10 个具有相当资质的开发人员全力投入一个项目，并且能与直接拍板的人沟通，那肯定能获得更快、更便宜的产出。

其他选择

软件开发方面，根据使用工具的不同，可以分为三个等级：传统开发、使用少代码平台开发、使用低代码甚至零代码平台开发。这几个选择的比较如下：

我们可以看到，传统开发的优势是自主研发度和自由度非常高，并可以实现任何想要的功能，但是代价就是开发速度慢。而低代码（零代码）平台，在开发速度（T2M）上无人能敌，缺乏的是系统的灵活度和自主度。少代码平台则兼顾了开发效率、自主度和灵活度。以 Jmix 为例，构建在开源的 Spring Boot 之上，结合 IntelliJ IDEA 提供快速的可视化开发工具，并无缝集成扩展组件提供开箱即用的功能。对于开发人员而言，这类平台可能是 LCAP 的最接近的替代方案，同时仍然提供灵活性和便捷的开发过程。

因此，可以根据项目的需求、团队的情况和偏好选择开发方式，然后再选择具体的框架、平台。

总结

低代码平台很适合开发原型或者演示系统，直接提供了面向业务人员的 IT 系统，并提供结果的可视化展示。这种场景下，由于参与的人很少，因此成本也很低。

但是不建议在复杂且多用户的业务系统中使用低代码平台，一方面随着复杂度提高，开发速度会变得更慢且难以管理，而另一方面，用户数量大使得每年的“使用费”居高不下，并且系统难以迁移和替换。

只要人工智能还没有替代编程的工作，企业软件就应该由专业开发人员来构建。因此，设定一个可到达的目标，组建一支精干的小型团队，聘请有能力的领导，让他们自己选择工具，并且融入业务领域，你的想法将很快实现！

如果对我们提供的内容有意见或者建议，欢迎联系我们：

blog：https://blog.abmcode.com

wechat：abmcode_gh