架构是活的

    前天加班，无意中看到王兄写的一篇架构师的文章。其中大部分都赞同，只是感觉王兄有几点说的不明确。

   1、架构师要写代码吗？

只要有必要，必须写。所以架构师就算不写代码，也要了解你所构建的平台的技术特征。这一特性在Web开发时体现最明显，为什么呢？调优啊。一个架构师不了解技术能做到怎么样，有哪些技术能提高性能，你能做架构吗？

   2、架构师要做需求分析吗？

要，而且是必须的，试问一个不了解需求的架构师，能设计出符合用户需求的架构吗？即使有专业的需求分析师，但需求到架构师那还得分析，这就是反刍，确认需求。

    我不是很关注架构师的职责，因为实际操作中，架构师不可能严格按照其规定的职责范围行事。其实架构师除了做自己的本质工作外，还得做些看起来不是其的职责，我认为这些是必须的，因为这些任务是和别的角色工作职责的边界之处，而这边界之处有时是很难分清的。

    我想动态的理解架构，至于架构师之所谓职责，就由大家自己理解吧。

     架构得从各个方面来理解，现在大家都从结果来理解一个架构，是静态的。展现在大家面前的都是最终的结果，这对学习架构来说毫无意义。下面我将从以下几方面向大家展示一个真实的架构，让新人真实地了解架构的过程，以抛砖引玉。下面是大纲。

   1、需求阶段：确认需求，明确风险，规避风险

   2、分析阶段：反刍需求，建立初步业务模型，初步划分模块，明确风险，规避风险

   3、设计阶段：具体化关键对象模型，横向划分模块层次,确认迭代边界，明确风险，规避风险

   4、开发阶段：

        （1）不断根据实际情况变更或新增接口

        （2）根据人员专长，分配人员参与开发的具体层次，对单一迭代纵向并行开发，降低各层开发人员的代码编写难度

        （3）明确风险，规避风险

   5、总结，提高。

    目前大部分架构类的文章都只是说明设计阶段的最终结果，但对开发阶段并未做更多介绍，以我的经验，架构对开发阶段的指导意义非常大，好的架构能充分发挥每个人的专长，降低各人的开发难度。对质量的把握和进度的控制有着决定性的作用。