架构师养成记

那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就(or打造)企业需要的软件架构师(or程序员or人才)。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事... 
  架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：

  1、架构师胚胎(程序员)学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信(通信协议)——学习搭建应用系统所必须的原材料。

  2、架构师萌芽(高级程序员)学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice(研究生可以研究网络计算机、高性能并发处理等内容)

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

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

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

  如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。

提问者评价

　最容易被忽略的可能是重要约束。在说明重要约束的重要性前看看这样一个例子：C/S软件系统需要实现信息量不大的高并发实时网络通讯，对于大多数有经验的软件架构工程师都会摒弃SELECT方式的无论是同步还是异步、阻塞还是非阻塞SOCKET通讯模式，而会选择IOCP。但如果软件系统有一条运行约束：系统必须运行在LINUX下，整个软件系统的架构都面临巨大冲击：LINUX下根本不支持IOCP！必须使用EPOLL。所以，许多约束之中其实隐藏着一些隐含的需求，它通过以下三种路径影响软件系统：一、直接制约设计决策。如上面的例子，架构工程师必须直接遵循，并影响关键决策。二、引申并转化为功能需求。这种情况下可能会增加软件系统的元素，如果在软件架构中不进行必要的说明，软件项目的涉众人员可能会对这些“无缘无故突然冒出来的”元素表示疑惑。三、引申并转化为非功能需求。这种情况下也可能会影响关键决策。

　　可以这样讲：软件架构的每一个过程中的每一步工作都是一系列的重要设计决策。可是最难让人理解是软件架构如何包含决策？这里有两个误解：一是认为软件架构就是RUP的4+1视图与软件架构文档，所以无法说明这些决策。二是在软件架构中引入的每一个设计模式、框架，其实就表现了一系列决策。所以虽然人们不理解软件架构如何包含决策，但其实每一位架构工程师都在不自觉的包含决策。我之所以提出是希望在架构过程中应主动有意识的包含这些关键决策。

　　主要元素、重要约束与关键决策从局部静态孤立的说明了软件系统的组成成份，而它们之间的关系则是说明它们是如何静态组成一个有机的软件系统整体的；如何进行协作交互则是从动态的角度说明软件系统是能进行怎样的行为、怎样满足软件系统的不同涉众需求。

　　我之所以决定采用博客的方式来进行软件架构的学习，就是知识自己的认识还是有片面性的一面，希望将自己的学习体会写出来，一来可以交流、共享、保存；二来希望有不吝赐教的同会能有建设性的拍砖，帮助我提高。