(本文是我给温昱先生新书写的读后感节选。）

我最早听说“软件架构”这个概念以及UML的名字，是在1999年的水木清华BBS上。当时有一篇文章介绍了软件架构作为一个相对独立的领域的发展情况，顺便提到在此前一年被接纳为OMG标准的UML。该文作者断言，UML的出现将能“彻底”改变软件开发的工作方式，甚至“若干年之后，不通UML者无法染指软件开发”。三年之后，《程序员》杂志专访Ivar Jacobson时，UML已经是尽人皆知。记得Jacobson在那次采访中劝告中国的开发者，赶快去学习RUP。从那时候起，越来越多的人顶上了“软件架构师”的头衔，张口模式闭口架构，一时间好不风光。然而最初的热乎劲过去之后，人们发现，“不通UML者无法染指软件开发”的预言似乎落了空，而一些软件架构师们似乎也并不那么神乎其技，很多时候反而不如那些实实在在写代码的人管用。他们所宣传的那些架床迭屋的抽象层，那些复杂精致的模式设计，看上去精美无比，柔性十足，然而实践当中一个出乎意料的小变更，便常常能把这一切打得粉碎。他们乐谈的松耦合，小接口，往往只是说起来好听，实际很难落实，或者代价过高，有的时候，反而是反其道而行之，才更“管用”。

为什么会出现这种情况？我想这里有客观和主观的原因。

就客观原因来说，软件开发毕竟还是年轻的行业，各方面还在剧烈发展和变化中。如果把软件技术做一个层次划分的话，软件架构及设计属于上层建筑，而像程序设计语言、技术平台、数据管理技术、网络体系结构等，均在其之下，属于基础。这几年随着互联网的飞速发展，基础尚且在剧烈变化当中，上层建筑自然会摇摇晃晃，甚至赶不上趟。具体来说，当今的软件体系结构设计总体上是基于面向对象思想，而且是强类型语言时代的面向对象思想，而动态语言的出现和流行，实际上很大程度上颠覆了传统面向对象思想的一些原则。例如，人们曾经认为封装非常重要，对象成员能够隐藏便应当尽量隐藏，但是Python和Ruby中public是常态，private反而是变态，实践当中也工作的很好，甚至更好。再例如，几年来人们津津乐道的设计模式，其中有很多在动态语言里毫无必要。而很多在关系数据库时代被视为秘笈的数据存储与访问模式，比如层次关系的表达，反规范化的经验，放到后关系性数据库里就没有多大意义了。再诸如应用的Web化、RIA、SOA等基本思想的变迁，都是能引起整个软件技术格局强烈震荡的大事件，所有这些进行中的剧烈变化，不可能不对软件架构的设计产生影响，从而使得很多关于架构设计的思想迅速过时或者必须调整。如果架构师们不能够充分重视实践，与时俱进，那么就很有可能做出不合时宜的设计。

 就主观原因来说，很多软件架构师走入了一个误区，即一旦升级为架构师，就可以脱离具体的代码实践，可以阳春白雪了。事实上，由于下层技术的变化迅速，架构师一旦脱离代码实践，脱离现实应用，很快就会与实实在在的软件开发工作产生距离感，忘却一线开发者需要面对的现实问题，做出一些不切实际的设计决策。这样的设计，或者执行不下去，或者执行下去也代价巨大，该解决的问题没解决，却在无关紧要的问题上大做文章。毫无疑问，这样的设计得不到一线开发者的衷心支持，得不到好的结果。架构设计跟开发发生矛盾，谁有问题？多半是架构设计出了问题。因为开发直接面对实践，直接从事实践，开发出了问题，那就是实践在向自以为是的伪真理宣战了。然而，一部分架构师不去检讨自己脱离实践的设计，却搞起本本主义，硬拿书本教条死扣实际。另一方面，如果开发者对于架构设计的原则和尝试缺乏了解，不愿意提高对于软件架构设计的认识和理解，不愿意付出对长远有利的代价，也不理解，不支持，甚至消极抵制架构师的决定，那么同样会引起架构设计与开发之间的矛盾。结果往往是，两个必要的角色之间产生矛盾。开发者抱怨架构设计华而不实，架构师抱怨开发者不严格按设计行事，进而相互质疑对方角色的必要性。开发者认为架构师就是吃干饭的文人，根本应该人间蒸发，没有存在的必要，而架构师则觉得开发者是一群无组织无纪律的骄傲的野猫，幻想有朝一日自动代码生成器能把这帮不听话的开发者赶出山门。

事实上，开发者和架构师都是软件开发中必不可少的角色，即使在单人开发的项目中，开发者本人也需要经常在这两个角色之间切换。两个角色的相互理解，和谐协作，才能够共同克服现实困难，开发成功的软件。在促进这种和谐的过程中，开发者应当积极学习架构设计的理论并充分实践，而架构师则需要本着务实的态度贴近一线。

因为从事技术媒体工作，我也确实结识了几个优秀的架构设计师，他们身上的共同特点就是务实。这些架构师都具有多年的软件开发经验，对软件本质的理解相当深入，本身就是开发高手。与一般开发高手不同的是，他们充分实践，但不宥于实践，而是积极地学习软件架构的理论，尝试用理论来指导实践。而与整天高谈阔论的理论架构师不同的是，他们掌握了理论之后，一定要亲自落实，用实践来检验。当理论与实践产生矛盾的时候，他们既不会轻易否定理论，更不会教条主义般地削足适履，而是认真分析矛盾产生的原因，研究可能的对策。在反复思考和实践之下，他们敢于做出“离经叛道”的结论，敢于质疑大师偶像的论断，更能够在错综复杂的实际做出简单、可靠、灵活而便于实现的设计，并且向开发者传达意图，答疑解惑，实现整个团队的思想一致。他们做出的设计，开发者看得懂，做得出，自然会得到衷心的拥护。

来自：http://blog.csdn.net/myan/archive/2007/04/19/1569938.aspx

评论

#   ouhua 发表于2007-04-19 09:39:33  IP: 222.181.251.*

写得好。 看来你是很青睐动态语言，走火入魔了，不过现实的business software开发中不会用动态语言，web site可能会用。

#   bookong 发表于2007-04-19 10:43:57  IP: 202.106.149.*

好文

#   summersnowgieno 发表于2007-04-19 12:51:57  IP: 131.107.0.*

谁说商用软件不会用动态语言开发？都会用～只是目前商用软件开发公司（开发人员）对动态语言的掌握程度还不够而已。偶觉得ruby可以作为非常好的开发语言。

#   gameboy999 发表于2007-04-19 14:21:09  IP: 170.148.96.*

很多架构师都是站在技术的最前沿，用理论总结指导实践。 反过来倒是IT媒体工作者们摇摆不定，疯狂追碰一切可以超作的题材。 越是大家没太注意的东西，越是可以狂吹，等大家明白不过如此的时候，又开始吹别的技术。

#   flygoldfish 发表于2007-04-19 15:37:34  IP: 202.106.86.*

现在的人吹的多，实践的少。每个软件公司，很多程序员，都说自己有什么特别的技术。我看，实用的就是最好的。

#   IUSR 发表于2007-04-19 17:54:51  IP: 218.67.240.*

影响动态语言推广到商用软件的因素大部分是因为语言惯性和代码保密问题，对动态语言的掌握程度相比之下根本不算是个问题。

#   FeiSan 发表于2007-04-19 18:03:30  IP: 219.142.181.*

动态语言对事务管理，尤其是分布式事务管理有成熟的支持吗？ 不要告诉我自己写啊。 基于这一点，像交易系统这样的领域，还就是C++和JAVA的天下。

#   lexchou 发表于2007-04-20 07:45:58  IP: 219.140.125.*

https://creditsuisse.taleo.net/servlets/CareerSection?art_ip_action=FlowDispatcher&flowTypeNo=13&pageSeq=2&reqNo=53820&art_servlet_language=en&selected_language=en&csNo=10020#topOfCsPage 楼上的，看看这个招人的链接，就知道了。

#   bbbg 发表于2007-04-20 08:47:09  IP: 220.167.29.*

看来我是很落后,感觉不到啊

#   eigo 发表于2007-04-20 11:36:46  IP: 218.249.115.*

从实现和维护的角度考虑当然贵在务实，但眼下如果你从商务角度谈项目没有点新鲜玩意是唬不住客户的。架构师还是会承受应用新技术的压力的

#   lishu1980 发表于2007-04-20 15:13:58  IP: 218.5.3.*

基础技术很重要，但不能只限于基础技术，基础技术和上层理论是相辅相成的

#   marising 发表于2007-04-20 21:39:15  IP: 218.56.197.*

老孟的文章看的多，以前看呢觉得说的很有道理，现在看呢觉得很可笑。动态语言，后数据库时代，恐怕管理软件不可能用。架构是技上层，语言，技术平台，数据库，网络是底层，底层变了，架构不稳定，太可笑了，我认为架构是稳定的，语言技术数据库网络是不稳定的，想想吧。

#   operfume 发表于2007-04-21 21:36:09  IP: 222.183.86.*

所谓架构师95%是吹出来的。

#   Anthony88 发表于2007-04-21 22:12:03  IP: 58.34.22.*

架构到底是什么呢？ 包括那些内容呢？

#   GoodType 发表于2007-04-21 22:46:53  IP: 222.216.6.*

一部分架构师不去检讨自己脱离实践的设计，却搞起本本主义，硬拿书本教条死扣实际。 写得好

#   aspcn 发表于2007-04-22 00:40:03  IP: 121.34.60.*

其实务实还有一个意思是简单。 搞个很复杂，自已相当满意的设计，结果开发人员看不懂，解释半天都听不懂，那个设计只能是个艺术品。

#   julong88 发表于2007-04-22 13:26:09  IP: 219.150.172.*

所谓架构师95%是吹出来的。 同意！

#   quchunyu 发表于2007-04-22 21:09:18  IP: 218.10.235.*

好文! 文中客观原因部分,有些部分稍显武断值得商榷.

#   Klaus19800331 发表于2007-04-23 06:37:51  IP: 220.173.7.*

我认为，架构应该是凌驾于具体技术实现上的，只和现实中的对象和业务有关，因此架构应该能够稳定。如果设计的架构不稳定，那就是架构师的问题了，不应该怪什么技术变了这些因素。

#   pt_caddy 发表于2007-04-24 23:26:25  IP: 221.122.37.*

我认为架构是系统是核心支柱，如果架构站不住脚那么对系统后继的改进还不如重新开发

#   nan3265531983 发表于2007-04-25 11:18:32  IP: 211.94.236.*

一个好的设计和软件生命长短直接相关。 现在企业级开发必竞要面对商业规则的快速变化，这就是软件变化的原动力，人们崇尚敏捷、快速开发不都是商业利润失然吗？ 一成不变者必会被淘汰！

#   snowindz 发表于2007-04-27 14:25:55  IP: 219.239.98.*

做这个太需要经验了

#   lgx522 发表于2007-06-22 17:58:38  IP: 220.163.39.*

烦透了对新技术的过分吹捧！ 一门语言、一种技术，想要充分掌握，都要花好多年的时间和实践。那些所谓过时的技术：从汇编、C到C++，真正精通者哪一个不值钱。而Java，从吹捧C#之始，许多牛人就说快完蛋了，结果如果？ 每天玩猴子掰玉米的游戏，只会一事无成。

#   n6002 发表于2007-07-02 10:34:58  IP: 202.108.60.*

“贵”在务实言过其实。架构师的“基”础在务实，“贵”在于创新。

分类： 系统架构 设计模式