图片65
低代码虽然在技术层面上并没有给开发带来新东西，却大受欢迎的原因如下：
首先，我认为低代码所传达的信息比模型驱动/基于模型的信息要清晰得多。模型是一个非常模糊的词，因此模型驱动的概念比低代码更难解释（每个人都清楚地理解什么是代码，低代码变得不言而喻）。
其次，我们知道建模会吓跑开发人员。相反，低代码听起来更熟悉。他们已经在做同样的事情(编码)，但更少。
此外，低代码的应用场景也更清晰。低代码并不意味着你可以用MDD做任何事情（这最终会导致不信任），而是通过特定类型的应用程序（即行业中最需要的应用程序）来提高可信度。
低代码也是一种典型的一次性建模方法，这意味着你有模型和生成的代码，没有复杂的细化链，没有模型转换，没有其他任何东西。
平均而言，低代码工具比我们传统的重型建模工具要好。例如，它们大多基于网络，而不依赖EMF。
总之，在低代码工具中，我还没有看到任何在模型驱动领域找不到的符号、概念、模型类型或生成技术。然而，可以肯定的是，这些相同的技术以不同的方式呈现、配置、调整和销售，这最终会使人们对低代码的新颖性和实用性有很大的认知差异。MDE项目的成功通常更多地取决于社会和管理，而不是纯技术。这不是免费的（缺乏相互操作、供应商锁定、昂贵的商业模式等），但这似乎并没有阻止社区的发展。
低代码吸引了许多人的注意，包括那些从未参与过建模的人。从这个意义上说，低代码是降低进入建模技术领域的门槛。因此，对我来说，低代码是将建模（以及我们的建模专业知识）引入新领域和社区的巨大机会。如果我们能通过将自己塑造成低代码专家来获得更多的资金/曝光/用户/反馈，我完全同意。这是许多知名所谓的低代码公司采用的方法（您可以随意使用互联网时间机，看看他们的网站在过去几年中是如何从可视化建模、快速开发、CASE工具和类似关键词转变为低代码的）。让我们借此机会更好地了解在广泛的软件社区中引起共鸣的因素，并从中学习类似的建模技术。低代码是将建模(以及我们的建模专业知识)带到新领域和社区的巨大机会。
