从程序员到构架师转变的要求

 微软的DotNet开发绝对是属于那种入门容易提高难的技术。而要能够成为DotNet架构师没有三年或更长时间的编码积累基本上是不可能的。特别是在大 型软件项目中，架构师是项目核心成员，承上启下，因此 RUP{Rational Unified Process,强调软件开发是一个叠代模型Interative Model），RUP定义了四个阶段（Phase）：开端（Inception），阐述（Elaboration），建造（Construction）， 过渡（Transition）}方法论也认同以架构为核心，体现4+1视图在整个软件开发过程中的重要作用。架构人员既要精通技术，又要熟悉业务，而且基 本对软件生命周期各阶段的相关技术都需要有相关的积累和知识储备，而这些不经过多年的磨练是很难达到这个高度的。
    
      要成为一个合格的架构师首先必须是一个合格或优秀的编码人员，对于开发来讲编码始终都是最重要的一项技能，在编码过程中只要自己善于去思考和 分析问题，就可以多学到很多相关的知识和技术。所以我们在开发过程中一定要注意新知识和新技术的学习，前人经验和成果的学习。编码过程中应该去思考的一些 问题有：
    
      1.在编码过程中自己是否做单元测试，是否使用相关工具做单元测试，如果没有的话是什么原因无法把单元测试做起来？
      2.自己编码的泄露率情况，编码泄露的BUG的原因分析
      3.是否有意识的对代码进行重构，重构过程中是否引入了相关设计模式的思想？
      4.是否对C#语言的一些高级特性进行学习，如反射调用，异步处理等。
      5.是否对Remoting和WebService两种分布式技术做过研究和对比分析？
      6.是否经常研究开源项目和开源代码，如Duwamish，PetShop，NUnit,Enterprise Library，Nant等
      7.是否对对象持久化机制和O/R Mapping等相关技术做过相关的研究
      8.平时在编码过程中是否注重公用组件和公用类的复用和抽取
      9.自己在平时工作和学习中是否经常开发些小工具提高工作效率，巩固学习知识
    
      设计和编码其实是密切而不可分的，对于严格将设计和编码分开的瀑布模型一般也仅仅在大型项目中应用。而及时编码和设计分离，也不是将编码人员 不需要思考，编码活动始终是一项创造性的劳动，如果否定这个观点那就代表编码过程完全不需要人员介入而可以完全自动化。因此在这里谈设计主要还是指设计人 员的系统化思维能力，设计人员应该比开发人员站高一个层次来分析和思考问题。设计人员最重要的一个技能就是现实- >抽象的转换，而这个就需要谈到方法论的问题了，技术人员需要积累面对对象分析和设计或结构化分析知识的积累，需要有较强的数据库分析和设计能力。 一个设计能否成为很好的架构师关键就在这种积累的深度和广度上面了。
    
      因此在设计过程中应该考虑的问题有：
      1.你现在分析和设计能力能否胜任大中型的应用系统还是只是独立功能分析和设计？
      2.设计过程中是否有意识的考虑到组件的复用和相关接口设计准则。是否能够很自然的将分析模式，设计模式的相关内容应用到自己的设计过程中。
      3.是否对XP，RUP，面向对象，结构化等方法论都有过较系统化的学习和思考。
      4.是否真正理解系统功能需求和非功能需求对系统设计的不同的指导作用。
      5.对自己设计的功能是否会根据后期的变更来反思自己的设计为何不能很好的适应变更？
      6.是否在设计过程中经常自己开发些原型来对自己的设计思路进行验证？
      7.是否专注技术的同时开始专业业务流程的分析，关注业务建模？
    
      如果我们在设计和开发过程中经常关注这些知识和技能的话，成为一个合格的架构师是早晚的事情。平时能够胜任工作开发用到的知识和技能是微不足 道的，如果自己不是有意识的去学习这些知识的话，那技能是很难得到进一步提高的。我参加过两次微软的架构师培训，在北京的微软架构峰会上也有机会专门参加 了P&P Workshop的学习，培训老师是微软总部SmartClient Architecture and Design Guide一书的作者Edward A.Jezieski，让我感受最深是老外深刻的技术底蕴，对程序开发的执著。
    
      对于DotNet架构经常用到的知识和技能储备有
      1.RUP方法论，4+1视图。用例驱动业务建模- >分析模型- >设计模型
      2.用例模式- >分析模式- >设计模式
      3.常用的分布式技术
      4.对安全，异常，日志，性能等非功能性需求的关注
      5.对应用系统整体业务的关注

 

此外：

       架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：

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

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

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

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

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

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