浅谈MDA技术未来发展方向

核心提示：一段时间以来，MDA的概念似乎热起来了，浅谈MDA技术未来发展方向，以至于我们看到有人专门的招聘MDA的架构和开发人员，月薪还不错的，并会借鉴MDA的一些思路和想法，并且，我们也早就看到一些关于MDA的专业网站的成立，然而

　　一段时间以来，MDA的概念似乎热起来了，以至于我们看到有人专门的招聘MDA的架构和开发人员，月薪还不错的。我们也早就看到一些关于MDA的专业网站的成立。
　　
　　然而，MDA真的是无所不能的“银弹”吗？
　　
　　实际上，MDA的“野心”是如此的大，以至于初看起来如此让人害怕，让人担心成为MDA糟糕的牺牲品，然后失落的担忧或者极力的也想成为建模专家。
　　
　　然而对MDA简单的观察和思考后，我面带微笑可以丝毫不担心她可能带来的冲击，尽管潜在的很多打着MDA名号的也有类似概念的自动工具的出现会混淆和占领一些市场并带来影响，但丝毫不应该担心她会如她宣称的那么强大。有几个问题她无法做到完美，哪怕确实她可以做到一些。（实际上，X-Brave也是类似的工具，也会借鉴一些MDA概念）
　　
　　首先，建模技术尽管发展迅速并取得一定的成功，但还没有达到所期望的成功，毫无疑问的，MDA必要的建模技术至少短期内无法奢望取得更大的突破。不太可能MDA的出现会让建模技术马上上天，他也不可能超过她也需要的UML的成功。曾经，UML也是那么宣称会对软件开发带来何种的成功，但到今天，即便是我也使用UML2年多了，我也不赞同完全的依靠她，实际上，有时候简单的一个草图就是足够的，若非技术的“表演”，很多图形很多设计经常只是漂亮的衣服，但只是衣服而已。在中国这个设计实用化的问题更加突出，经常，我们的设计人员已经脱离了代码实现，而且无论如何很难想象一个设计可以“恰恰”那么恰当！而假设真的可以做到这一点，那么抱歉，我对实现者就会抱着强烈的怀疑。
　　
　　在软件设计上，同实现一样，我主张KISS，但KISS本身和技术高度和难度不矛盾。
　　
　　其次，业务建模式可能的，但是，标准和标准的推广是个问题，而且，毫无疑问的，复杂业务建模技术在可预见的将来都不太可能那么完善。而软件发展的将来复杂度会不断的增加，很大程度上就包含了业务复杂度的提升。
　　
　　再次，全面的自动软件是可能的，但是她不可能做得那么完善：自动化带来的必然是高度的耦合和固化，而软件项目根据项目的情况在软件结构/架构技术方面必然是灵活多变的，试图以不变应万变那只不过是甜美的梦想，要做到语言和平台的独立，基本上只是天真的梦想。实际上，即便抛开单个语言和平台的复杂度和潜在变化的深刻洞悉，也毫不可能在林立的语言和平台之林真正的完成----虽然在某种程度上这时候只是某种程度的技术实现的移植，但即便是这个移植都不太可能。在一个特定的语言和平台，我也难以想象她如何解决“面向业务”、“面向前台”的时候的灵活选择，更不用提在软件架构里面的“粘合”、“性能”、“分层”问题，而这些恰好体现了软件设计实现的技术实力和差异。即便可以通过建模技术来“设计”这些要害技术点，也不太可能让MDA为你完美的实现代码细节，这是不现实的：同样的软件设计，其代码实现的不同，其差异也是巨大的，而通常，设计也不应该被奢望非常的完备以至于不需要任何的调整。
　　
　　我想，就是上述的问题已经足够MDA面对的了，而考虑到这些问题还需要结合到一起，外加那么多新兴技术的溶合带来的技术难度的快速提升，这个时候显然“1+1>2”的。所以不用担心MDA对我的影响，尽管我已经是一个设计人员并且始终坚持保留技术路线，即便是旁的人，也丝毫不要担心所谓的风暴的来临。
　　
　　然而，自动化也会发展，并会借鉴MDA的一些思路和想法，并且，耦合和确定领域和边界的“类MDA”会出现和发展的。