技术专家的恐惧症

专家的恐惧与专家的“反恐”<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

孟岩

人民邮电出版社最近出版了一本书，叫做《应用MDA》。据我所知，它是国内第一本介绍MDA概念的图书。目前，MDA还处在“油漆未干”的状态，对于我来说，亟需通过阅读一些资料对此项技术建立初步印象。因此，我阅读这本书时，目的是十分明确的。我想知道，如果MDA是一个答案，那么问题是什么？我本以为这个问题应当是很简单的，略读过这本书之后，我感到，事情其实并不简单。 　　原著作者David Frankel先生是OMG中MDA运动的活跃分子，对<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><personname style="BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x" tabindex="0" productid="于这位" w:st="on">于这位</personname>先生，我并不了解，书中也没有进一步的详细介绍。从这本书整体布局看来，作者在大局把握上似乎经验不足。当然任何一个理智健全的人也不会指望通过一本328页的小书真正掌握MDA的应用技术，此书不过应证了这一点而已。不过Frankel先生在叙述中夹杂了很多背景资料和个人议论，这恰恰是我喜欢捕捉的东西。个人作品较之冰冷而懦弱的官方技术文档，最大的优点便在于文字背后的感情，这种感情不仅能够让读者更顺利地接受书中所描述的技术，而且时不时泄漏出一些小秘密甚至是大秘密。对于我来说，这些秘密或许是真正有价值的、值得讨论的东西。Frankel先生看起来是个比较谨慎的人，尽管如此，他还是给了我很有意思的暗示。不妨看看这段： 　　“我们不得不得出这样的结论：我们对于平台的未来所能做出的唯一预测是，我们无法预测到的事情将会发生。哪怕IT经理人对于平台下了正确的赌注，平台也不太可能保持原样，而是会随着时间的流逝而演变成几乎完全不同的新平台。即使经理的猜测是正确的，依赖于该平台的代码也可能会很快过时，快得令人心碎。” 　　真有意思，不是吗？Frankel先生不够坦白，因为他在这里用“IT经理人”当幌子，可是谁都看得出来，其实他在说“IT技术专家”。尽管如此，抛开这点小小的不坦白，Frankel先生在这里说出了当今软件技术领域的一个大秘密，那就是，整个软件开发领域中的“专家阶层”已经在心理上陷入深深的恐惧中。 　　作者既然没有明说，那么这个结论当然只能是我的印象。而印象之所以为印象，就在于解释起来并不容易。首先的一个难题就是要论证在软件开发领域存在一个所谓的“专家阶层”。“阶层”这个名词实在不好听，我甚至很难解释它与更难听的“阶级”之间的区别何在，因此也不想陷入这个问题的争论之中。但是软件开发领域中确实存在一批所谓的专家，那些通过文章和书籍以及演讲表达他们自认为高人一筹的技术思想的人，那些因为之前的成功而拥有表面自信的人，那些敢于“文人相轻”而且的确有一点点“相轻”资本的人，如果你承认这些人与刚刚入行的战战兢兢的coder确实有所不同，那么就请暂且接受我的这一前提。 　　在软件开发这个圈子里，专家们是让人仰视的。然而这些让人仰视的专家，今天其实正陷入一种深深的集体焦躁和恐惧之中。是的！这些衣食无忧、态度傲慢、言之皇皇、著作等身的专家们，他们正在恐惧！ 　　上世纪90年代以来，软件产业的一个基本现象，就是基础平台和工具技术的更迭和变革愈演愈烈，超出任何人的预期和意愿，也完全超出个人所能够应付的范围。在短短十多年间，基础技术经历了从面向过程到基于对象，从基于对象到面向对象，从面向对象到面向组件三次大的变迁，其间还夹杂有GUI革命，32位革命，关系型数据库革命，Web革命，向C＋＋和Java的大迁移，Design Patterns运动，开放源代码运动，面向对象方法学之战，分布式中间件之战，J2EE之战，COM＋和Windows DNA的昙花一现，VB开发者面临的.NET之乱等等无以计数的事件。软件工业的发展进步，基本上处于被平台技术的快速变革所驱动的境地。这种快速的变革，使得今天专家阶层，往往会被明天遗弃。一些人今天还在为上一次选择的成功而沾沾自喜，明天就将面临被抛弃的命运。软件平台技术的每一次变革，每一场工具大战，背后都有着千万悲情故事。多少人从荣誉的峰顶跌落？有多少人要吞下苦涩的心情，抛却数年的心血，一切推翻重来？又有多少人故作轻松地说着“必须努力跟上时代”的废话，鼓起越来越贫弱的勇气再战江湖？平台技术的迅速变化，超过所有人预料，而其革命性和颠覆性，使得在这个行业中知识和经验的老化速度之快，技术积累之艰难，达到了让业内人士感到羞辱的地步。整个产业的从业者就好像站在格陵兰岛夏季的浮冰上，对于脚下肆虐断裂的冰层充满着恐惧，他们四处寻找看上去更坚实的浮冰，吃力地跳跃挪移。然而，如果说连MFC、VB6和CORBA这样的巨型浮冰，现在都面临解体崩塌的危险，那么你还能信任什么呢？ 　　在书中，Frankel说： 　　“荷马在他的史诗中描述了西西弗斯的故事，他必须将一块巨石推上海蒂斯的一座小山，但每当接近山顶时，巨石又会滚下来，因此西西弗斯的苦役永无止境。而当今的IT经理人正是现代版的西西弗斯。” 　　对，这就是事实！ 　　你以为软件开发领域内的那些“高手”、“专家”们，对于大公司一波又一波的新平台革命真的热烈欢迎吗？你以为那些关于“提高开发效率”、“让你的工作更轻松”之类的宣传口号真的让专家们山呼万岁吗？他们只不过是强颜欢笑！其内心的焦躁和恐惧，才是基本的真相。不错，确实有一小部分涉世未深的新锐们津津乐道，激情澎湃，但这只不过是下一个悲剧故事的开始而已。任何一个专业领域，只有保持变与不变的对立统一，有所积累，有所扬弃，才能够稳步前进。而软件技术领域，已经习惯于在平台技术这样的基础层面上快速震荡，而且到目前为止，都没有任何有效的方法隔离这种震荡，从而使这种震荡严重波及整个产业和专家阶层。 　　这种情况不是一开始就有的，Frankel在书中第一章回顾了70年代COBOL语言在商用主机系统上的统治地位，以及长达十几年的DOS时代，这都是软件发展历史上的黄金期。然而最近几年来，平台技术的震荡过于频繁和剧烈，技术人员疲于奔命，拼上全部精力来掌握平台技术特性，完全成为文档的奴隶，根本没有余力来考虑真正重要的技术问题。这是多么严重的局面！ 　　在软件开发专家作为一个群体，数量还比较少的时代，这个问题即使严重，对于他们来说也只能采取“人为刀俎，我为鱼肉”的被动态度。大多数人采用两种办法，一是深深地钻入某一个细分领域，甚至干脆改行，以其他行业（而非软件技术）的稳定性来保护自己。另一种方法则是勇者之选，就是不断跟风赶潮，争当所有时代的弄潮儿，或者换一个角度说，甘愿被各个时代反复蹂躏。 　　然而随着专家群体数量之多，足以形成一个阶层的时候，逃避和被动的姿态就显得过于懦弱。至少在软件开发过程和方法这个领域，既得利益的专家们开始尝试主动的出击。与其屈从于技术浪潮，被玩弄于股掌之中，不如主动制定游戏规则，建立防波堤，稳定软件技术行业的专业阶层。 　　这就是MDA的关键目的之一。看上去很不错，可是怎么做呢？ 　　基本思路很简单，Andrew Koenig曾经引述一个英文作家的话：“增加一个间接层，这是解决任何问题的办法，”并指出这句原来或许是讽刺不断自我膨胀的官僚体制的言论，放在软件领域倒的确是箴言。遵循这个箴言，专家们准备打造一个间接层，把浮冰隔离在该层之下，从而可以脚踏实地，高枕无忧。 　　“MDA就是把建模语言当成编程语言来用，而不只是当作设计语言来用。” 　　当然！如果建模语言可以当成编程语言来用，主要通过编程语言来体现的基础平台的变化将很大程度上被隔离在建模语言之下。 　　“MDA无意独领风骚而令其他方法黯然失色，相反，它同其他方法相辅相成。” 　　当然！MDA要让其他方法成为它下面的浮冰，你们尽管去崩塌断裂，彼此搏杀吧，我自岿然不动。 　　“用建模语言编程可以提高生产率，改善质量，并使软件产品生存期更长。” 　　当然！只有提供更高的生产力，才能够获得更强大的整个业界的名正言顺的支持。只有在这种支持的庇护之下，专家阶层的利益才能得到维系。 　　可以说，MDA的目标已经十分明确——通过建立新的理念、技术和工具，将“软件设计”这件事情变成一门与编写代码相分离、真正独立的专业，通过专业化，防止下层平台技术不断震荡波及甚至颠覆专家阶层在技术上的积累。因此，这是一场专家们用专业化手段实现专业分工，以维系专家利益，对抗专业恐惧心态的运动。 　　当然这个定义不是严格的、正式的。在面对听众的时候，我们需要一个更加冠冕堂皇的理由，比如推进软件工程进步，提高效率、改善质量之类。但是我认为“对抗恐惧”这个心理层面的因素也没有什么不好意思表达的，至少在我看来，这算是光明正大的理由，无须掩盖。而且，从Frank e l先生这样的著作来看，也掩饰不了。 　　MDA并不是凭空捏造的，它是传统软件工程的必然发展。传统软件工程（对应于目前流行的敏捷方法）在本质上一直模仿土木建筑工程。土木建筑工程，与很多人设想的相反，一直不断涌现着大量的创新技术，然而，对于这个领域内的专家阶层——建筑师和结构工程师——来说，新技术的出现几乎总是一种好事，他们从来不需要担心新技术的出现会颠覆自己的专业地位。这一点令软件工程领域的专家们羡慕不已。他们付出了很多努力，试图通过对开发过程的研究解决这样的问题，然而对于跟技术结合更加紧密的软件设计者来说，软件过程无异于隔靴搔痒，解决不了问题。 　　MDA要把属于软件设计本质的东西用专有工具表达成为专有的成果，就好像建筑师只需画出建筑图纸，结构师只需画出结构图纸，在软件工程中，工程师凭借MDA，只需要构造出模型。有了模型，软件设计者们梦寐以求的依赖倒置出现了：不再是软件的架构和设计依赖于下层平台，而是下层平台被迫不断完善以满足表达模型的需求。在这种情形下，软件专家们将能够逐渐摆脱平台厂商歇斯底里的斗争带来的剧烈震荡，集中精力研究软件结构问题和设计问题，甚至可能开发出量化的工具来衡量软件结构的优劣，预测软件的可用性，建立真正的工程科学。唯有如此，软件构造这件事情才能够成为一件专业，专家们才能有时间架构起高高的壁垒，防止那些凭借《21天学会XXX》闯进软件开发领域的毛头小子利用一些新技术细节羞辱他们，让这个专业进入分工清晰、阶层分明的成熟阶段。 　　在MDA层面的专家看来，如今爆发在J2EE和.NET阵营之间的论战实在可怜。今天那些意气风发的论战者，那些把宝押在某一个千秋万代、唯我不败的平台上的幼稚的人，迟早会发现，要么是脚下的浮冰崩溃，要么是各个平台趋同，毫无区别可言。已经重复了无数次的悲剧，还将重演，只不过瑟瑟发抖的主体有所不同而已。 　　MDA将是打破这一悲剧性宿命的一次尝试，它能成功吗？现在下结论还为时过早。 　　反恐尚未成功，专家仍在努力。