低代码应用平台（LCAP - low code application platforms）在多样、复杂的现代软件开发情势下应运而生。依据Gartner（高德纳，全球最具权威的IT研究与顾问咨询公司）的数据，Mendix 是这方面的翘楚，所以允许本文将它做为参照。但其实类似的结论也适用于 Outsystems、Appian、 Kony、 Betty Blocks 以及其他平台。
在向高管推销时，LCAP 们会号称业务人员（即非专业开发人员）就能构建企业级的解决方案。那么，后来专业开发人员都失业了吗？事实是 - 几年以后 Mendix 承认：专业开发人员比以往更需要。
好尴尬呀！我猜测 Mendix 意识到任何比基本的 CRUD 复杂的事情都需要一个软件工程师，就好像除了打气之外的汽车维修工作都是需要专业人员一样。
不幸的是，当下的低代码平台并不是给专业开发人员设计的。并且长时期的依赖低代码平台对业务来说是危险的赌注。下面我来解释其中的原因。
做原型开发很赞
事实上 Mendix 对开发简单的自动化商业流程、或者交付可运行的原型系统来说，是业余开发人员不错的选择。在一个可视化的设计器中定义数据模型，使用内置的组件、模板来设计脚手架交互UI，甚至可以使用 microflows（microflow 类似于 Java 中的方法，有入参，出参，可在里面做循环，判断等等）描述业务逻辑：
完成之后，可以把应用一键部署到 Mendix 云上，然后运行。看上去简单而有魔力，这足够让企业高管签支票。
但是，当你的应用过了原型阶段，用户交互和业务逻辑会不可避免的越来越复杂。这个时候，为了避免结果一团糟，你将需要一个专业工程师来推进项目。
所以下一步，我们从专业工程角度来看。
低（慢）代码
用低代码平台的时候，任何逻辑 - 包括计算和用户交互 - 都需要用一个 microflow 来描述，如上节中的图示。这里就有一些问题。
首先，会慢。想象一下，拖动、配置，然后将十几个模板连接起来，相比于在好用的 IDE 里敲十几行代码。 规模上去以后，你的 microflows 不可避免的多到难以管理。
其次，可读性。模板看上去很妙，但是后面的 Sub_RegistrationValidation 呢？不跟进去根本无法阅读。
权宜之下，Mendix 提供了 Java 操作。你可以在一个 microflow 中调用 Java 方法（但是由于云部署的限制，对这些 Java 方法也有严格的限制）。你可以在 Eclipse 中写好 Java 代码，尽管更多人选择更优秀的IDE - IntelliJ。透明度是一个风险 - Java 代码的入口都在 microflows 中，所以调试、跟踪都变的复杂了。逻辑流程分散在两处。
最后不得不提的一点是版本控制。好消息是确实有这方面的版本控制软件，坏消息是它是 Subversion 的一个受限制的子集。跟 git 再见吧。
不可控
任何熟悉 Java 生态的人都不会低估开源的能量。当有一个异常抛出时，你能看到发生异常的代码，也能通过调试来看发生了什么，你能 Google，也能提一个pull request。最坏的情况，你可以 fork 整个项目。这些都是可控的。
用 Mendix 的话就什么都别想了。它是一个商业权属物，调用栈里是个黑盒子。你可选的只有付费的售后支持，或者祈祷上天能在社区获得回答，每月大概200个问题，与 stackoverflow 上带 Spring 标签的问答数目比比？
销售商锁定
Mendix 可能是被经常问到这个话题，他们发布了一篇文章来解释如何解除锁定。如果仔细阅读，它提到了：
你可以拿到你的数据、DDL，UI 资源和代码（microflows 可以神奇地转为 Java 代码）。
那么你拿到的代码可以脱离 Mendix 的运行库和 API 独立编译或者运行吗？事实上，这需要重写整个系统。你被锁在一个商业权属物平台上，你甚至不拥有你构建的系统。
扩展性受限
Mendix 的目标客户是大型企业，所以“扩展性”在他们的市场材料中被多次提及。2017年他们引入了“stateless runtime” - 无状态运行时，所有会话信息即存在客户端，又持久化到数据库。理论上，横向扩展将没有上限。听起来很酷，但有一个问题 - 数据库。
数据库通常是企业级应用的瓶颈所在。在集群的无状态 Mendix 服务后面是用什么在存储数据呢？没有惊喜 - 就是关系型数据库。 Mendix 使用的是 PostgreSQL。Mendix 没有缓存，而且它生成的 DDL 是有问题的，比如，我见过对一个 1:N 的关系生成了一张 N:M 的临时表。
如果控制权在自己手里这样也可以接受。Oracle 及其他数据库已经证明了 RDBMS 是可以扩展的，你可以优化 DB 结构，缓存数据或者使用 Citus 这样的方案来做扩展。但问题是使用 Medix 的话控制权不在你手里。
唯一可行的是使用只读复制（如 Amazon RDS），但这个对写数据没有帮助。
总结，存在基础上的扩展限制，并且缺少微调性能的选项。
降低（提高）技术要求
降低技术要求对主管来说听起来很美妙，昂贵的、难找的专业人员不再需要了。实际上，这是一个坏招。当你真的需要一个专业开发人员时，就会苦恼如何找到一个好的开发人员，因为对于专业的工程师来说，使用低代码平台意味着职业生涯的结束。
价格很美丽
最后但并非不重要。一个单应用授权最低 $1875每月，限于50个内部用户，并且最少购买三年。可以部署到 premises 的企业授权最低 $7825，几乎$100K（10万$）每年。所以一个有几千内部用户的大型企业每年大概需要几百万美元。
并且要注意的是依据以上讨论，我们只是针对相对比较简单的应用。这对我来说很疯狂了。这个定价下，你还不能自己发布你自己构建的应用。
那为什么LCAP还如此流行？
在我看来，答案令人沮丧。在大型机构中管理工程师团队 - 无论是内部还是外部 - 目前来说都过于复杂。预先进行预算规划，相关人员（架构师或者直线经理）各自有各自的议程，缺乏责任感等等。 所以推进、实现自己的想法很难。更有趣的是，管理人员下意识的应对策略还是雇用更多的开发人员，当然还有更多的经理。毋庸置疑，这会使情况变得更糟。我知道有几家拥有超过10,000(!!!)个开发人员的银行，我还知道里面至少有一半的人在从事无用的工作。 令人绝望的是，企业高管因此寻求那种神奇的、解决所有问题的解决方案，例如LCAP - 低代码应用平台。
如何摆脱这一团糟是另一篇文章的主题。 但这是一个管理问题，而不是技术问题。 跳过所有细节，如果你能让3-10位具有相当资质的人员全力开发，并能与相关人员和决策者直接沟通，你将获得比想象中的更快、更便宜、出色的结果。
有其他选择吗？
如今，开发人员工具和框架有很多选择。 例如，Spring Framework 是最流行的企业软件开源框架，可以与 React 或 Angular 等 Web 框架很好地结合在一起。 在过去几年中，Spring Initializr 和 JHipster 之类的工具使上述操作变得更加容易。
如果你需要更快的结果和更容易采用的方法，那么CUBA Platform之类的RAD工具非常值得考虑。 它建立在 Spring Framework 之上，并通过可视化开发工具和无缝集成扩展插件市场进行补充。 对于开发人员而言，这可能是 LCAP 的最接近的替代方案，同时仍然提供灵活性和便捷的开发过程。
因此，有很多选择，如何选择应取决于任务、团队技能和偏好。
总结
低代码平台用来开发原型很赞。 它们将业务相关人员和 IT 连接，使结果可视化，促进双方更快地达成一致。 由于参与人员很少，所以成本也很低。但也只能到此为止！
否则，继续使用下去，开发速度将减慢，你将越来越多地陷入又贵又限制诸多的商业权属平台中。
只要 AI 还没有替代我们工作，企业软件就应该由专业开发人员来构建。 因此，设定一个可到达的目标，组建一支精干的小型团队，聘请有能力的领导，让他们自己选择工具，并且不要忘记将他们纳入业务领域。 很快地，你将看到你的想法逐渐成形！
————————————————
版权声明：本文为CSDN博主「Jmix」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/cubacn/article/details/104492376
