为什么我们还没有做模型驱动的开发呢？

Question

我是真正相信模型驱动的开发，我认为它有可能提高生产力，质量和可预见性。当看MetaEdit时，结果是惊人的。荷兰的孟迪克斯增长非常快，并且取得了很好的效果。

我也知道有很多问题

• 生成器、模板和框架的版本控制
• 不适合模型驱动开发的项目(没有足够的重复)
• 更高的风险(当第一个项目失败时，与传统开发相比，您的结果会更少)
• 等

但是，这些问题似乎是可以解决的，好处应该超过所需的努力。

问:您认为最大的问题是什么使您甚至不考虑模型驱动的开发？

我想使用这些答案不仅是为了我自己的理解，也是作为一个可能的来源的一系列内部文章，我打算写。

Answer 1

没有金锤。在一个领域中工作得好的东西在另一个领域里是非常无用的。在软件开发中有一些固有的复杂性，没有任何神奇的工具可以消除它。

人们可能还会说，只有当语言本身(或框架)不够高到允许强大的抽象而使MDD相对没有意义时，代码的生成才是有用的。

Answer 2

有趣的问题！我承认，我不是一个粉丝，但后来我尝试在符合您刚才提出的一些问题的项目中多次使用模型驱动的开发。

这是我的理由清单：

• 学习曲线-建模工具发展得如此之快，以至于我很难找到深入理解该工具的工程师。我仍然发现你只是和你的建模工具一样好。诚然，下面的许多问题可以追溯到这个问题--每当你认为一个工具太有限时，你就有可能不太了解它。
• 过于结构化--就我个人而言，我发现建模工具过于结构化，无法让我描述我需要描述的一切。一旦我转到工具外画一些模型的小插曲，当人们开始在工具外漂流寻找信息时，事情就会迅速恶化。
• 优化工具的成本--每次我尝试自动生成代码时，一旦我看到工具的想法是正确的，我就会手动地重新处理代码。我知道，经过几次周旋后，这个问题就会减少，但这意味着你必须在前几轮比赛中生存下来。我通常觉得我们在玩->生成代码、->修复代码、->更新模型、->修复模型、漂洗和重复模型。
• 模型配置管理()--由于模型描述了项目的大部分，在某种程度上，模型CM将比构建的代码更具有横切性。划分建模文件本身就是一门艺术--如果做错了它，您通常会陷入开发人员死锁，或者是当人们放弃并继续使用代码时过时的模型。
• 市场时间-我经历了明确的问题，当一个情况下，需要工作软件是紧迫的。如果项目和团队足够小，我认为没有理由浪费时间在建模工具上，因为时间可以花在编码和测试上。并不是每个项目都足够大，需要这样的投资。
• 失败的成本--当我看到项目逃离建模工具时，这是因为失败的高成本--要使用这些工具，需要每个开发人员都参与进来。这是对培训和学习的大量投资，如果有人做得不好，那将是一个非常昂贵的错误。我的经验是，可能需要两到三个版本才能得到正确的模型--因此许多项目无法在建模错误中存活足够长的时间来实现这些好处。

Answer 3

因为并非所有的编程都是面向对象的，这似乎是所有MDD工具所期望的。UML本身基于对象的假设。当然，您可以使用序列图来建模函数，但很多时候，这是笨拙的。

因为像我这样的程序员比MDD从TDD中获得更多的进展和结果。

因为建模=编程。

因为成本方面的成本/效益太高，而在效益方面则不够。这可能已经改变了，因为我上次看MDD，那时你将需要支付>6000美元/座位(美元)的工具，将是中等能力的MDD。

因为足够描述函数以生成代码的模型作为模型不再有用。

因为像我这样的程序员只在高层次上使用模型，然后用代码计算出细节。您在代码中的看法与在建模软件中的不同。

这些是我个人不做MDD的原因之一。我曾接触过它，但没有什么能使我皈依。也许我太老了。也许我太新了(不管那是什么)。但这不是我能为自己付出代价的工具。