自从低代码（Low-code）成为新的流行术语之后，我就想知道“低代码”运动与我们过去所说的“模型驱动的工程 / 开发”相比，是否真的有什么不同。第一届 低代码研讨会（属于 2020 年模型大会 的一部分）是让我花时间思考并写作这个主题想法的一个很好的借口。 接下来你将阅读的是我思考的结果。里面还嵌入了我准备发表的论文的演讲幻灯片（见底部）。两者都包含了我在发布本文的第一版时得到的一些反馈（感谢大家给我的宝贵反馈！）。我相信这（低代码在模型驱动领域的定位）是我们作为一个社区所必须继续讨论的话题。即使我们不能达成任何共识。 免责声明：
说到这里，请继续阅读我关于在模型驱动工程领域定位低代码运动的想法。特别是，我试图给出这些问题的部分答案
低代码应用程序平台通过大幅降低所需的手工编码量来加速应用程序交付（该定义来自 Forrester 报告 [5]，被认为是低代码一词的起源）。这显然不是软件工程界第一次试图通过结合可视化开发技术（我们称之为“模型”）和代码自生成来减少手工编码。事实上，正如 GradyBooch 所说，软件工程的整个历史都是关于提高抽象层次的。
低代码可以追溯到模型驱动工程。但是模型驱动工程本身可以追溯到 CASE（Computer-Aided Software Engineering，计算机辅助软件工程）工具。早在 1991 年，在著名的 CAiSE 会议的第 1 版中，我们就可以找到这样的论文：“给定最终模型，可以自生成完整的计算机化信息系统”[2] 或“我们得出了一个可自动生成可执行代码的规范”[4]。 同时，低代码在当今商业世界中的影响也很明显，包括了一些大胆的预测，但也包括了最近投资于低代码工具的相关实际数据，其中一些工 具的商业成功或许仅仅是因为所有最大的软件公司都在确保他们在提供该领域的某种产品。 对于所有的 MD* 概念，我们并没有通用的定义。我自己的（非正式）定义 如下：
能区分 MBE 与 MDE 的一个例子是开发过程，在分析阶段，设计人员指定了独立于平台的系统模型，但是这些模型会直接交给程序员来手工编写代码（不涉及代码自生成，也不明确定义任何特定于平台的模型）。在这个过程中，模型仍然发挥着重要的作用，但不是开发过程的基础。 基于以上定义，我认为低代码是模型驱动开发的同义词。如果有什么区别的话，我们可以把低代码看作是 MDD 中的一个更严格的视图，其中我们仅针对某种特定类型的软件应用程序：数据密集型 Web/ 移动应用程序。 注意，术语“无代码”有时被用作低代码的细微变化。实际上，我们经常会看到工具将自己定义为无代码 / 低代码工具。然而，对我来说，无代码方法的关键特征是应用程序设计人员应该编写零代码来创建和部署应用程序。这在很大程度上限制了使用无代码工具的实际效果。我们基本上是在研究基于模板的框架或创建工作流，这些工作流将预定义的连接器与外部应用程序混合在一起，在这些应用程序中，设计人员最多是决定何时以及如何触发某些操作。 比较这些不同范例的另一种方法是查看你需要编写多少手工代码。在 MBE 中，你可能需要编写所有代码。相反，在 MDD 和低代码中，大部分代码都应该是自动生成的，但是你可能仍然需要定制并完成所生成的代码（大多数 MDD 工具都包含某种黑盒建模原语，你可以在生成过程中编写任何应该添加到其中的自定义代码）。在无代码中，你应该编写零代码。 显然，需要进行更多的研究来评估市场上的低代码工具，并更好地将其描述为比这里介绍的工具更细粒度的类别。事实上，目前基本上还没有关于低代码运动的研究（快速搜索只会发现一些关于将自己归类为低代码工具的论文，而不是将低代码本身作为研究对象），我相信这个研讨会将会使这一点开始改变。 如图 1 所示，对低编码的兴趣达到了顶峰，即使如图 2 所示，这个峰值远小于对模型驱动的注意力达到顶峰时的峰值。 谷歌趋势图显示了对低代码术语的搜索兴趣 但是，如果从技术上讲，低代码并没有真正带来什么新东西，为什么会如此流行呢？
总而言之，在低代码工具中，我还没有看到任何在模型驱动领域找不到的符号、概念、模型类型或生成技术。但可以肯定的是，这些相同的技术以不同的方式呈现、配置、调整和“销售”，这最终会使人们对低代码的新颖性和实用性在认知上产生巨大的差异。MDE 项目的成功通常更多地取决于社会和管理方面，而不是纯粹的技术方面 [3]。这并不是免费的（缺乏互操作性、供应商锁定、昂贵的商业模式等等），但目前看来这并没有阻止社区的发展。 如前所述，我不认为 MDD 和低代码趋势之间存在根本的技术差异。事实上，我们可以应用模型驱动工程中几乎所有的开放性挑战 [1]，只需将“模型驱动”变更为“低代码”即可免费获得低代码开发的研究路线图（例如，我们需要更好的方法将人工智能集成到低代码工具中，或者我们应该作为一个社区努力构建低代码示例的共享存储库用于未来研究）。 但是我不认为这是消极的。恰恰相反。显然，低代码吸引了很多人的关注，包括那些从未参与过建模的人。从这个意义上说，低代码是降低进入建模技术领域的门槛。因此，对我来说，低代码是将建模（以及我们的建模专业知识）引入新领域和社区的巨大机会。如果我们能通过将自己塑造成低代码专家以获得更多的资金 / 曝光 / 用户 / 反馈，我完全赞成。这正是许多知名的所谓的低代码公司所采用的方法（你可以随意使用互联网时光机，看看他们的网站在过去几年中是如何从可视化建模、敏捷开发、CASE 工具和类似关键字转变为低代码的）。让我们也借此机会更好地理解使类似建模技术在广泛的软件社区中引起共鸣的因素，并从中学习。
在我们这么做的同时，让我们关注一下未来的市场趋势。一些低代码供应商正在（再一次）改变他们的营销工作。也许用不了多久，我们就会开始高呼：低代码已死，多体验开发万岁！ Low-code vs Model-Driven Engineering 来自 Jordi Cabot
原文链接： https:///low-code-vs-model-driven/ 你也「在看」吗？👇 |
|
|
