编程语言在其历史中有几个(r)进化步骤.有些人认为模型驱动的方法将是"下一件大事".有一些工具,如openArchitectureWare,AndroMDA,Sculptor/Fornax平台等,可以带来令人难以置信的生产力提升.然而,我的经验是,它在开始时要么相当容易,但是当你尝试一些意想不到的东西或者很难找到足够的信息来告诉你如何开始你的项目时,也会陷入困境.可能有很多事情需要考虑.
我认为从模型驱动的东西中获取任何东西的重要见解是理解模型不一定是一组漂亮的图片或树模型或UML,但也可能是文本描述(例如状态机,业务规则)等等.).
您如何看待,您的经历告诉您什么？是否存在模型驱动开发的未来(或者您可能想要称之为的任何东西)？
更新:这个主题似乎没有太多兴趣.如果您对模型驱动方法有任何(好的或坏的)经验,或者您认为它根本没有意义,请告诉我.
免责声明:我是业务应用程序的开发人员.以下观点肯定是由我在企业IT战略中的经验所塑造的.我知道,还有其他软件开发领域.特别是在工业和/或嵌入式系统开发中,世界可能看起来不同.
我认为MDSD仍然与代码生成过于紧密相关.
代码生成仅在您的代码包含大量噪声和/或非常重复时才有用.换句话说,当你的代码不能主要关注基本的复杂性时,却会被意外的复杂性所污染.
在我看来,当前平台和框架的趋势正是为了消除意外的复杂性,让应用程序代码专注于基本的复杂性.
因此,这些新的平台/框架从MDSD运动的风帆中汲取了很多风.
DSL(文本的)是另一种趋势,试图使唯一的重点放在基本的复杂性上.虽然DSL可以用作代码生成的源,但它们并不主要与代码生成相关联.DSL(特别是内部DSL)基本上允许它在运行时被解释/执行.[运行时代码生成介于两者之间].
因此,即使经常与MDSD一起提及DSL,我认为它们实际上是MDSD的替代品.鉴于目前的炒作,他们也从MDSD运动中获取动力.
如果您已达到最终消除代码中的意外复杂性的目标(我知道这是虚构的),那么您已经达到了业务问题的文本模型.这无法进一步简化!
漂亮的盒子和图表不提供抽象级别的另一个简化或提升!它们可能对可视化有益,但即便如此也是值得怀疑的.掌握复杂性的图片并不总是最好的表现形式!
更进一步,参与MDSD的工具的当前状态,增加了意外复杂另一个层面(认为:同步,版本比较/合并,重构......),基本上勾销简化的终极目标!
看看下面的ActiveRecord模型,作为我理论的一个例子:
class Firm < ActiveRecord::Base has_many :clients has_one :account belongs_to :conglomorate end
我不认为这可以更简化.另外随着框和线的任何图形表示就没有简化,并不会提供任何更多的便利(想想布点,重构,搜索,版本比较......).
模型驱动开发已经存在了很长时间.
早期尝试中最成功的是詹姆斯·马丁斯综合工程设施",它仍然由CA以严重不冷的"Coolgen"品牌名称进行销售.
那么,如果它如此美好,它为什么不接管世界呢？
这些工具很擅长简化这些简单的东西,但是,它们不会让硬件变得更容易,而且在许多情况下会使硬件变得更难!
当您知道在Java/C/SQL中编写正确的东西或其他任何微不足道的东西时,您可以花费数小时试图说服图形4GL建模语言"做正确的事".
京公网安备 11010802040832号 | 京ICP备19059560号-6 