架构师

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

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

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

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

 

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

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

 

架构师（Architecture）是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢？这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。
     所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。
    在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。
     与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然！
     由于国内合格、胜任的软件架构师极为少见，直接导致了我国民族软件产业水平的落后。在未来以信息产业为主导的社会，信息产业水平的低下将直接影响国家核心竞争力。究其原因，无企业非急功近利、个人缺乏引导。
      企业的急功近利是有无法克服的原因的，那就是社会发展总体水平。“生存是第一位的，赚钱是第一位的”，多年来许多客户抱怨国内的软件公司无法信任、系统项目累做累败、公司越换越差，但因国外不可能给中国做应用系统项目还不得不找国内软件公司做。由于人月费用低、公司开发成本高，软件企业对于应用只能草草了事，拿钱走人（很多公司拿不到后期尾款）。这样的环境下，企业几乎无法投入更多资源培养自己的架构师，加上眼花缭乱的跳槽风气企业更是不愿投入……
      那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就（or打造）企业需要的软件架构师（or程序员or人才）。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事...
     架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：
     1、架构师胚胎（程序员）学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信（通信协议）——学习搭建应用系统所必须的原材料。
    
     2、架构师萌芽（高级程序员）学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice（研究生可以研究网络计算机、高性能并发处理等内容）
   

     3、架构师幼苗（设计师）应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式（c++版本、java版本）、ejb设计模式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。

     4、软件架构师的正式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼……

     然而学海无涯，精力有限，个人如何能够很快将这些所谓的架构师知识掌握？这是秘密，每个人都有自己的独门家传秘笈就不敢一一暴露了。不过有一点就是广泛学习的基础之上一定要根据个人兴趣、从事领域确定一条自己的主线来努力。

     如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。所以我们希望在软件系统构建过程中，人和机器发挥各自的长处，也就是说，让人来扮演架构师的角色，而让机器来扮演程序施工者的角色。事实上，目前已经有了成功的模式了，那就是KCOM 商业工程（http://www.kcomsoft.com）企业应用平台所采用的基于设计的全自动化软件工厂模式，采用这种模式，架构师在工具平台所提供的模型图设计环境里做软件系统的设计，设计结果由工具平台自身所带的“软件工厂”自动加工成最终企业应用软件系统。这样的开发模式，能使企业应用软件系统的开发在效率、质量上有了质的提升，从根本上区别于传统的设计模式，因为这里的设计模式已经包含在软件工厂编译器之中了。

 

应用软件人才体系图