（原创）谈谈架构师的职责（一）

　　很早就想写一篇文章来谈谈架构师的职责了，由于本身作架构设计也有几年了，有得有失，想以此文来谈谈本身对架构师职责的认识。架构师这个话题很大，在这里不打算深刻详谈，只是简要的谈谈，想到哪里说到哪里。在谈架构师以前我想谈谈什么是架构，关于架构有不少种专业的定义，我这里就用最好理解的一种定义来介绍架构是什么，架构就是决策。从技术选型，到架构选型，从业务建模到系统建模，无一不是在作着决策。

要成为一个好的架构师，首先要掌握一些基本理论和技能：

• 面向对象设计的理论。若是连面向对象的基本理论都不知道就开始作设计，那是很糟糕的，为何要这样设计，这样设计有什么好处，不是凭空瞎想的，都是有理论依据的，若是设计连一点依据都没有，那确定是拙劣的设计。
• 设计模式。设计模式是架构师的基本功，设计模式用来解耦组件内对象之间的关系，用好了，后期的开发阶段将很顺利，用很差则会致使过多的复杂性，下降架构质量，甚至致使开发计划延期。设计模式每每和业务联系得很紧密，若是连设计模式都不懂就作设计，那早晚要栽跟头。
• UML理论及其工具。这个是作设计最基本的要求了，若是UML理论都不懂，UML视图都不会画，又怎么完成得了设计？曾看到有人用excell画的几个框图就说这是架构，而后吐沫横飞的讲解所谓的架构，其实这种所谓的设计连玩具都称不上。一个完整的设计至少要包含五种UML图，业务流程图、用例图、活动图、组件图、类图。
• 架构模式。架构设计的时候经常须要参考借鉴一些经典的架构模式，由于这些架构模式就是前人总结的用来解决实际问题的，有很是重要的借鉴意义，能够避免少走不少弯路，尤为是在系统设计的时候，参考一些架构模式经常能事半功倍。
• 重构。架构也是须要不断重构的，没有完美的架构，只有不断折中、不断切合实际需求的架构，这是一个不断完善的过程，完善的一个重要手段就是重构。
• 代码质量理论。架构师不只仅是画几个图而已，架构师须要参与技术攻关和核心模块的开发，并关注开发过程当中的代码质量，高质量的代码会让架构的实现锦上添花。

　　上面说到的这些基本理论和技能也不是一朝一夕就能掌握的，须要一个不断学习、实践和思考的过程，当你某一天掌握了这些基本理论和技能以后，相信你作架构设计的时候天然也是胸有成竹。不过，即便你具有了上面提到的这些理论和技能、技术很不错的状况下，依然不能保证能作出一个成功的设计，由于还有一些要求你须要达到，不然，同样作不出成功的架构，而这些要求并不是都是技术上的要求。

　　架构师除了是一个优秀的技术工程师以外还应该如下下角色：

• 应该是好的产品工程师

　　若是觉得本身掌握了上面提到那些基本技能，就必定能设计出牛X的架构，那是至关错误的想法，包括我曾经都这么认为。这也是搞技术的人的通病，只对技术感兴趣，认为作出一些牛X的技术就很牛了，就能搞定一切了。其实技术只是手段，关键是要能作出好的产品，而要作出好的产品就须要对产品、对业务很精通，若是对于产品和业务的理解不深刻，作出的东西极可能就不是用户想要的，甚至是失败的产品，这种例子现实中太多了，不要认为技术是万能的，要清楚的意识到，技术是服务于产品的。架构师应该是好的产品工程师的另一个理由是，不懂业务就不能作架构，若是不懂业务，那么设计出来的东西必定是失败的，由于业务流程、业务规则、业务细节等等都是变化点，若是设计之初都无论不顾，甚至不深刻挖掘，那么到最后，甚至在快完工以前，一个细小的业务规就是压死骆驼的最后一根稻草了。这个我是吃过亏的，之前作的一个项目，最开始我只是粗略的了解了业务就开始作设计，等到设计开发快完了，发现有一个业务规则没有处理，而这个业务规则致使以前的抽象变得支离破碎，而接着是其它的业务规则又致使原来的设计被破坏，并且还难于修改，几乎陷于泥潭，最终费很大力气修改完成，却发现和本身设计之初的理念相去甚远，连我本身都惊讶我怎么精心设计出这么一个丑陋的东西出来，最后不得不推倒重来。这些教训让我深入的体会到好的架构师必定要先成为一个优秀的产品工程师。

• 架构师还应该是一名好的推销员。

　　是的，你没看错，架构师就应该是一名出色的推销员，当你开始设计的时候，首先你须要向你的领导推销你的设计理念，要向领导描绘出设计蓝图，得到领导的认同很重要，每每一个项目的方向都是领导决定的，领导不认同，项目是无法作下去的。可是这里有一个问题，每每领导都不懂技术，他们可能很精于产品，而对技术不感兴趣，因此架构师要从产品的角度向领导来介绍架构设计，而不能从技术的角度去介绍，这才是大家沟通的基础。

　　向领导推销完设计以后还须要向产品人员推销你的设计，为何要向产品人员推销设计呢？这很重要，由于需求很大一部分来自于产品工程师，向产品工程师推销你的设计，目的是让产品工程师了解你的设计细节，及时发现设计的错误，甚至还会发现你没有考虑的问题、细节和需求，越早发现这些问题越有助于后面的设计和开发，避免在后期大改或者推倒重来。向产品工程师推销你的设计的时候一样不要从技术的角度来推销。更多的是从业务的角度来告诉他们，好比我这样设计是为了处理某种复杂的业务，经过这种设计咱们能很方便的处理这些复杂的逻辑，还容易扩展。业务才是你和产品工程师的共同语言。

　　向产品工程师推销完你的设计以后，就应该向项目组的开发人员推销的设计了，这一样很重要，由于架构设计最终是须要他们完成的，架构的实现，最重要的是开发人员，若是开发人员不理解你的设计，甚至有抵触情绪，那么破坏架构的事情常常就会发生，士气低落，不能团结一致，最终会致使项目的失败，因此架构师必定要向开发人员推销设计。开发人员理解并认同设计是项目成功的关键因素之一。如和向开发人员推销设计呢？从纯技术的角度来推销。从面向对象的基本理论开始介绍你为何要这样设计，这样设计的好处在哪里，而开发人员是如何从中受益等等，我相信有理有据的技术交流是最容易博得开发人员的认同。并且一个优秀的架构一定是一个受开发人员欢迎与支持的架构，只要你们都认同的架构才是好的架构。

　　怎么样，如今知道架构师为何还必须是一个好的推销员了吧，只有你们认同了你的设计理念，你才可能设计一个成功的架构。

• 架构师还应该是好的培训师

　　开发人员不像产品工程师那样不懂技术，开发人员是懂技术的，都会有本身的想法，若是遇到某个值得商榷的地方时，开发人员会提出本身的看法，这时就须要作折中了，从开发人员的角度去考虑，是否须要修改，若是要修改，则尽可能在不改变大的设计原则基础上作小幅改动，让你们达成共识。最终的目标是让开发人员认同设计，并乐于在这个架构上开发，这是很是重要的，也是保证一个架构成功实现的重要因素。若是开发工程师受限本身知识水平，不理解架构设计的思想，这时，架构师就须要作些技术培训了，经过这些技术培训来让开发工程师明白设计的理念，最终认同设计。我一直在强调沟通和认同，由于这真的很重要，kent beck曾提出，程序员的编程价值观是：沟通、简单和灵活。这是很是重要的概念，为何咱们须要编程价值观，由于价值观决定了行为，有什么样的价值观就有什么样的行为，若是程序员认为程序的可理解性、简单性很重要，那么他的代码风格确定是易读易懂的，而这些偏偏是软件的品质属性，若是你们都认同这些理念，自觉按照这些思想去写代码，软件的质量天然就提升了。相反，若是你们不认同这些理念，都按照本身的想法去作，那么最终获得是一个混乱的混合体，会致使软件项目的失败。只有你们都有一个共同的编程价值观，共同的理念，才可能高质量的完成一个软件项目，所以架构开发的第一步是要达成共识，让你们认同设计。

• 应该是好的QA和救火队员

　　项目开发过程当中，应该常常审查代码，架构师要确保你们是按照一个方向前进，要确保没有人在破坏架构，破坏架构是很危险的，不只仅会致使代码慢慢腐化，还会造成破窗效应，危害很大。当开发过程当中发现设计考虑不周甚至有问题，要有勇气去重构，而不是缝缝补补，要记住架构的一个重要目的是让开发人员的日子变得美好，若是开发人员用起来都以为别扭，那这个架构又怎么能成为一个成功的架构呢。开发过程当中，若是遇到技术难题，架构师应该充当救火队员的角色，一马当先主动去解决，由于这是技术调研和技术选型时，考虑不周致使的，一马当先的去解决技术难题问题还可让你们对架构更有信心。

 

未完待续...

后面还会继续谈到架构师份内的一些事情和架构设计的目标。