谈谈架构师的职责

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

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

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

　 　上面说到的这些基本技能也不是一朝一夕就能掌握的，需要一个不断学习、实践和思考的过程，当你某一天掌握了这些基本技能之后，相信你做架构设计的时候自 然也是成竹在胸。不过，即使你具备了上面提到的这些技能、技术很不错的情况下，你依然不能保证你会作出一个成功的设计，因为还有一些求你需要达到，否则， 一样做不出成功的架构，而这些要求并非都是技术上的要求。

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

• 应该是好的产品工程师

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

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

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

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

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

　　怎么样，现在知道架构师为什么还必须是一个好的推销员了吧，只有这些人认同了你的设计理念，你才可能设计一个成功的架构。

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

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

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

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

 

在谈架构师分内的事情之前想先谈谈为什么要做架构，这个问题其实挺有意思的，一种是被动的一种是主动的。被动的做架构设计是因为设计者内心并不太愿 意去做设计，不愿意做设计的原因挺多的，比如，项目开发周期短，觉得没有足够时间去做设计。或者，认为设计很麻烦，除了UML设计、设计文档之类的还有设 计评审什么的。或者，觉得设计没什么作用，属于浪费时间。或者，不懂设计，不知道如何下手等原因，不一而足。虽然内心不情愿，但由于一些外部原因，却又不 得不去做设计，比如，是公司规范要求，有些公司是按照CMMI规范的，必须要有设计文档，或者，是领导要求做设计等等原因。总之，这种被动的设计会带来很 多问题。

1. 走形式，只是为了应付检查或者为了完成任务。这样可能出现一些比较奇怪的事情，先开发后补设计文档，往往是开发完成之后 才写设计文档，我曾经就看到过这样的事情，这样导致的结果是，没有设计，设计只是为了生成一个设计文档。还有一种情况就是东拼西凑几个图和几段文字组成一 个所谓的设计文档，这其实只是仅仅是形式上的设计文档，因为很多公司都找了一个所谓的标准的设计文档模板，设计者只要填充其中的内容即可，填充完了就是设 计完了，这种设计文档模板和八股文非常相似。设计者或许都不太清楚为什么要这样设计，只知道按照八股文的作法去填充，只是因为文档要这些东西。这样导致的 后果是，设计者迷迷糊糊，开发者更是不知所云，这样导致的结果是，设计是设计，开发是开发，二者没有任何关系，仅仅是为了完成任务。
2. 本末倒置，设计的目的是为了梳理业务逻辑、解决开发过程中可能遇到的问题，使我们的开发工作变得容易，目的是指导开发，提高软件产品的品质。设计不是为了生成文档，不是为了应付检查或者完成任务，否则就是本末倒置，也失去了设计的意义。

　 　不愿意做设计的原因很多，但是最重要的原因是没有体会到设计的重要性，不知道为什么要做设计，以为设计就是几个图和设计文档，繁琐而无大用，心底是有些 排斥的。为什么要做设计？这个问题很重要，很多人说我很少或者几乎不做设计，但是我一样完成了项目的开发，以此证明设计或者不设计都可以，是无所谓的。是 的，不设计一样完成开发项目，这种事情很普遍，我看到不少项目，没有任何设计文档，因为根本就没有设计过，内部的对象关系如同蜘蛛网一样，而且随着新需求 的增加，代码就变得更加混乱了，这样带来的后果是修改或者扩展都很困难，不能快速响应新需求。另外，别人维护时，很难看懂代码的意图，如果要了解其含义， 不得不查看大量的代码，还不能确保一定理解了原来的思路，这样带来的问题是可维护性非常差，而且修改很容易破坏原有结构，使代码变得越来越难以理解和难以 维护。这样的软件产品，表面上看似乎还在运行，但是内部遍布着坑，bug难以查找和解决，改了这里就错了那里，改一个地方还不行，还要改一系列的地方，直 到某一天，发现这样做下去太痛苦了，不仅不能快速响应市场，原来的维护还很费劲，最后不得不推倒重来。我这里并不是说不做设计的项目一定会糟糕到这个地 步，如果你的项目，虽然没有经过设计，却仍然运行得很好，那我可以说你的运气很好，也许是没有遇到需求的变更，也许没有遇到挑剔的用户。如果你做的好几个 项目都没有设计仍然运行得很好，那我就只能说你对产品和业务真的很精通，开发即设计乃神人，我等凡人可望不可即也。但我仍然想说的是，如果你是凡人且继续 根据经验主义不做设计就去开发的话，那迟早要栽跟头！

　　为什么要做设计，关于这个问题我想以我的一点经历来说说，以前做过一个项目，这个 项目比较小，正常情况下，两个人大概两周多就能做完，也许以为项目很小，能很快完成，就没有做设计，我觉得业务逻辑不复杂，能够在开发的时候设计好，于是 直接就开始做了。项目是做一个统计库给前端使用，统计库主要是根据一些统计类型来统计，根据这个特点，开发时将每个统计类型抽象成一个统计类，这是个比较 典型的策略模式，第一周做得还比较顺利，完成了60%，第二周的时候发现有个有个特殊的业务类型需要处理，这个业务类型可以嵌套多个其它的业务类型，这 时，已经感觉策略模式就显得不那么合适了，但想着只是一个特殊情况，就特殊处理吧，在策略模式中再增加一些条件判断些用来处理嵌套统计类型，随着后面开发 和测试不断的深入，又发现有几种特殊情况要处理，看着开发时间都过半了，也不愿意大改了，想尽快完成任务，于是，又是在一些策略类中加判断，导致本来可以 复用的嵌套统计代码都不方便复用，调试起来也很不方便，最后回头来看，程序结构显得混乱，还有不少重复代码，没有美感可言，显得很丑陋，随着后面新需求的 不断加入，代码已经变得难以扩展和修改了。

　　为了不使代码继续腐化下去，就不得不停止开发，从架构上重构了。重构的时候我不再直接开发， 而是先做设计，通过对业务流程进行分析，将业务的流程归类出来，充分的了解业务过程是什么样的，再结合业务流程图做用例分析，通过用例分析来确定我们的我 们的系统到底有多少用例，用例之间的关系是怎么样的，最终画出系统的用例图。业务建模结束之后邀请产品人员帮忙分析，业务流程的归纳是否合理，业务用例是 否涵盖了所有的用例。业务建模阶段使我完全明白了整个业务流程和细节，这为之后的设计带来非常大的便利。之后，我再根据前面的业务建模做系统分析，根据包 的设计原则和单一职责原则划分组件，将各个组件的耦合性降到最低，组件划分好之后再进行类的设计。类的设计时考虑到要解决嵌套统计的问题，就不能再用策略 模式了，改成桥接模式和组合模式，这两个模式结合起来可以完美的解决嵌套统计的问题，关于他们结合的细节可以参考我前面的介绍：composite模式和 bridge模式是天生的好朋友。这个设计大概花了将近一周时间，不过这个设计只是UML设计，不包括设计文档，因为时间比较紧，UML设计文档转换为 word设计文档的工作并没有做。在UML设计完成之后就开始开发了，开发阶段非常顺利，开发时间实际上只花了一周时间。重构后，整个架构非常清晰，由于 都是单一职责的，没有重复逻辑，修改起来也很方便，且完全可以灵活的应对新增需求，符合开闭原则。

　　也许有人要说，这是由于我没有深入了 解业务导致设计不合理的导致的结果。是的，是我没有深入的学习业务，在开发阶段草率的做出了不成熟的抽象和设计，导致后面特殊业务规则出现时，不能适应变 化。但是，这个问题其实完全可以在设计阶段就可以发现，从而可以避免在开发过半的时候发现问题而大改。如果一开始就做设计，然后将设计推销给产品工程师， 推销给开发者，很多问题就能及早发现，而不是边开发边设计，导致不能从整体上去把握。边开发边设计，往往还导致头痛医头脚痛医脚，结构混乱，使开发变得困 难，最后还受限于开发时间而不得不沿错误的方向走下去，最终做出一个失败的产品。

　　很多时候我们不可能一下子就了解全部的业务，这需要一 个学习和消化的过程，而设计阶段就是将业务变为软件实现的过程，这个过程是业务的充分消化吸收的过程，这个过程如果顺利通过，则后面的开发就会变得非常容 易，因为设计到类图了，而且在设计阶段将已经将绝大部分问题都解决了，剩下工作只是如何完成这些具体的类而已。这个经历给我很大的启示，哪怕是一个一两周 的小项目也要做架构设计，因为设计可以帮助我们梳理业务逻辑，避免因为业务逻辑的不熟悉而导致的不合理的抽象和归纳，不合理的抽象会导致架构不能应对正常 的变化，还难用，开发也变得不顺利，轻则导致开发延期，重则项目失败。

　　关于设计的目标，架构设计看似耽误时间，实际上为了将业务逻辑合 理的组织起来，解决开发阶段会遇到的问题，并最终指导开发顺利的完成。如果设计不是用来指导开发，或者对开发来说没有作用，甚至起反作用，那么设计对于开 发来说就是无用的，这个设计做得也是失败的，是浪费时间的。设计是为了解决开发过程中会遇到的问题，并最终指导开发的，如果没有达到这个目标，那么这个设 计就是失败的。

　　关于设计的时间，以我上面的那个重构项目为例，设计花了一周时间，本来按照正常的开发周期来说，一周时间肯定是不够的， 因为除了UML分析之外还要编写设计文档。但是由于项目很小，且开发周期很短，我就只做了UML设计，然后后面的开发都是依据UML设计去开发的，UML 设计转化为文档的工作就省掉了，这节省了不少时间，这样做是否合适呢？我觉得在一定程度上是没问题的，因为UML设计本质上就是已经完成了的架构设计，一 图胜千言，UML图本来就是程序员交流的介质，方便开发者交流和理解，也能方便的指导开发，仅仅做UML设计对于项目开发来说没问题，不过对非专业的技术 人员来说可能显得过于抽象和难懂，这时才需要将UML抓换为word文档，通过文档详细解释UML设计。架构设计看似慢，实则快，不管项目多小，都要做设 计，好的设计不仅可以指导开发还可以加快开发，是非常有必要的。

　　关于设计和文档，有很多人将二者混淆起来，认为设计就是文档，其实二者 不是密不可分的，关键是设计，文档是对设计的解释和描述，架构设计的精髓在于UML设计，通过几张UML图就能清晰而深刻的表达设计思想，一图胜千言，设 计不是为了生成文档，文档只是设计的结果而已，很多人本末倒置，以为像八股文一样填充好设计文档就是完成了设计，这是非常错误的想法。我更喜欢看UML图 而不是看文档，因为文档啰嗦半天都赶不上一张图直接。开发人员应该通过UML设计文档而不是word文档来开发，UML设计简短而直接，一来可以清楚的知 道自己所开发的东西是整体架构的哪一部分，该如何开发；二来可以更深入的理解架构，减少破坏架构的失误。