低代码平台（低代码应用程序平台，LCAP）的出现是对现代软件开发工具的复杂性和多样性的一种反应。
根据Gartner的说法， Mendix是该地区最著名的玩家之一。 西门子以7亿美元的价格出售证实了这一点。 因此，我将以该平台为例，尽管类似的结论对于Outsystems，Appian，Kony，Betty Blocks等也适用。
因此，低代码平台供应商将销售目标锁定在高层管理者身上，他们保证即使是普通用户也可以自行创建业务应用程序。
也就是说，不再需要开发人员？！
好吧...几年后，Mendix被迫承认：
“现在，开发人员比以往任何时候都需要更多。”
这是一个转折！
似乎Mendix认识到，除了处理数据的基础工作之外，还需要专业的开发人员，就像维修汽车需要专业的机械师一样。
不幸的是，现代的低代码平台根本不是为开发人员设计的，从长远来看，依赖于它们对企业来说是有风险的。 如果您的公司正在认真考虑在工业操作中使用低代码平台，那么值得再次权衡此解决方案。 下面我将尝试对此进行争论。
出色的原型制作工具
Mendix是自动化简单流程或原型的绝佳选择，可供分析人员或高级用户使用。
可视化编辑器使您能够描述数据模型，使用一组小部件和模板快速创建屏幕，甚至使用所谓的微流来描述逻辑：
完成后，您可以一键式将应用程序部署在Mendix云中并开始使用它。 如此简单，听起来像魔术！ 而且看起来卖得不错。
但是，经过原型阶段之后，系统与用户和业务逻辑的交互几乎不可避免地变得复杂。 为了进一步发展该项目，需要专业人员。 因此，让我们从开发人员的角度来看Mendix。
发展缓慢
如上所示，任何逻辑（无论是计算还是用户交互）都应在微流流程图中进行描述。
这里有几个问题。
首先，很长一段时间 。 显然，在一个好的IDE中编写10行代码比拖放，自定义和连接数十个块要快得多。
其次， 可读性 。 块看起来很漂亮，但这Sub_RegistrationValidation是什么意思 ？ 不陷入困境就不可能理解这一点。 一旦块的数量增加到几十个，将很难理解其逻辑。
作为复杂情况的替代方案，Mendix支持来自微流的Java代码调用。 您可以使用Eclipse编写代码，这通常很好，尽管许多人希望使用更流行的IDE。 缺点是缺乏透明性：所有入口点都在微流中，因此逻辑分散在两个松耦合的环境之间。 结果，调试和跟踪依赖关系很困难。
我最后要提到的是版本控制。
好消息是他是。 不好的是，它是Subversion的精简版本。 忘记git flow。
缺乏控制
任何熟悉Java生态系统的人都不能低估开源的力量。 当错误出现在堆栈中的某处时，您会看到发生在代码的哪一部分。 可以调试代码以确切了解正在发生的事情。 您可以谷歌解决方案。 您可以发送拉取请求。 在极端情况下，您可以派生该库。 您完全控制该项目。
使用Mendix，您可以忘记它。 这是一个封闭的商业框架，内部发生的事情是一个真正的黑匣子。 您剩下的就是购买有偿支持或等待有人在论坛上提供每月大约200个问题的帮助（与stackoverflow上的#spring标记比较！）。
供应商依赖性
Mendix可能经常对此进行指责。 他们甚至发表了一篇文章，说确实没有上瘾。 如果您在术语之间阅读，则其内容为：
您可以获取数据，DDL，UI资源和代码（将微流神奇地转换为Java代码）。
它将在没有运行时和API Mendix的情况下执行或编译吗？ 可以维护和发展吗？ 问题是修辞。 实际上，您将需要完全重写所有内容。 您依赖专有平台。 您不拥有创建的系统。
扩展性有限
Mendix营销专注于最大的公司，因此“可扩展性”一词在营销材料中不断出现。
在2017年，Mendix引入了无状态运行时-即所有会话信息都存储在客户端或持久性存储中。
从理论上讲，这意味着无限的水平可伸缩性。 听起来不错，但像往常一样有细微差别-数据库。
数据库几乎总是成为企业应用程序的瓶颈。 那么，数据如何存储在许多Mendix无状态服务器后面？ 毫不奇怪-这是一个很好的旧关系数据库。 在云端Mendix-PostgreSQL。 而且，温和地说，生成的Mendix DDL并非完全最佳。 例如，我看到了一个中间表，该表通常用于为1：N关系创建的N：M关系模型。
可伸缩性问题可以通过标准方法解决：优化数据库结构，缓存甚至使用Citus之类的解决方案。 但是，当然没有这种可能性。
扩展数据库的唯一方法是使用只读副本（例如，Amazon RDS）进行扩展。 但是记录下来，这是行不通的。
综上所述，Mendix对可伸缩性有根本的限制，并且没有优化性能的方法。
人力资源问题
寻找合格人员始终是一项艰巨的任务。 Mendix似乎是任何经理的梦想，因为资格要求大大降低了。
实际上，我们已经发现，无论使用哪种工具，大多数项目都需要一支专业的团队。 但是，任何有自尊心的开发人员都不太可能同意与Mendix合作，因为这显然是他职业生涯的死胡同。
价钱
最后但并非最不重要的。 一个应用程序的许可证费用为每月1875美元，需订阅三年，许可证仅限于50个内部用户。
可以在本地部署的公司许可证的价格从7,825美元起，大约每年100,000美元。
一家拥有数百名用户的中型企业每年将支付数千万卢布的账单。
从上面您可以理解，不要忘记我们在谈论相对简单的应用程序。 对我来说，这太疯狂了。 这种定价模型实际上也使得不可能复制您创建的应用程序。
那为什么LCAP仍然很流行？
我认为，原因在于对现有流程的失望。 在大型组织（无论是内部团队还是外包）中管理开发团队太复杂了。
预算计划，无休止的批准，缺乏愿意承担责任的人-我认为许多人对此很熟悉。
有趣的是，当IT项目发展太慢时，首先想到的是雇用更多的开发人员，当然还有经理。 不用说，这只会使情况恶化。 我知道有几家拥有10,000多名开发人员的银行，其中至少有一半在做无用的工作。
绝望的是，企业领导者正在寻找LCAP之类的“魔杖”解决方案，据说该解决方案能够解决所有问题。
如何摆脱这个恶性循环是另一篇文章的主题。 但这是管理问题，而不是技术问题。
如果不做任何细节，如果您设法创建一个由3-10人组成的小型合格团队，完全参与该项目，并与决策者直接联系，您将比预期的更快，更便宜地获得出色的结果。
有哪些选择？
现在，有大量可供开发人员使用的工具和框架。
例如，Spring Framework是最流行的开放源代码技术，用于创建可与React或Angular等Web框架完美配合的企业软件。 在过去的几年中， Spring Initializr和JHipster之类的工具极大地简化了项目创建。
如果您想更快地获得结果，则应考虑使用RAD工具，例如CUBA Platform 。
它基于相同的Spring框架，并通过可视化开发工具和大量现成的组件对其进行了补充。 也许这是LCAP的最接近替代方案，它提供了灵活性和舒适的开发过程。
最终选择应取决于任务，团队的技能和您的偏好。
结论
低代码平台非常适合原型制作。 它们缩小了业务用户和IT之间的差距，使您可以快速获得有效的原型并形成对未来系统的愿景。
由于原型用户很少，因此现阶段的成本也很小。 而这时值得停止！
当使用LCAP开发完整的系统时，工作速度将不可避免地下降，并且您将依赖昂贵的专有平台来限制自己。