从程序员到架构师转变

     微软的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.对应用系统整体业务的关注