架构师是对所有重要事情做出决定的人。但是行业内对于架构师的负面认识正越来越多，看来我们需要重新认识架构师的职责

成为一个优秀的架构师还有很长的路要走(软件架构案例分析和最佳实践培训收获)

2009-12-25到27日我们参加了某软件培训机构的的《软件架构案例分析和最佳实践》课程培训，开拓了眼界，收获很多，刘老师讲得不错，非常有实战经验，跟他学到了不少有关软件架构的知识，可惜的是3天的培训课程不可能完全掌握所有知识，师傅只是给我们打开了一扇门，指出了一个方向，成为一个优秀的架构师还有很长的路要走。

新视野 “软件架构”定义的决策因素

定义1：架构是一系列重要决策的集合

一直以来，学习架构，使用架构，关注点都仅限于技术层面，没有认识到架构和“决策”的关系，这说明架构是一个很重要的概念，从软件架构概念产生的背景可以得出：

——-其实，软件架构(Software Architecture，软件体系结构)一词早在20世纪60年代就被E.W.Dijkstra提出，但是直到20世纪90年代初才开始流行起来。为了提高软件需求和软件设计的质量，软件工程界提出了需求分析工程技术和各种软件建模技术。但是在需求和设计之间仍然存在一条很难逾越的鸿沟，即缺乏能够反映做决策的中间过程，从而很难有效地将需求转化为相应的设计。为此，软件架构的概念应运而生，并试图在软件需求与软件设计之间架起一座桥梁，着重解决软件系统的结构和需求向实现平坦过渡的问题。

定义2：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。

还有很多其它的定义方式，但从这两个定义可以看出，架构对于决策的重要性，架构师的工作对于项目的成功运作具有决定性的作用。

“架构师”不是空头衔

——不是项目经理，开发人员，测试人员的兼职角色

在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。Martin Fowler(著名软件架构和设计大师，软件设计模式创始人)指出：

架构师是对所有重要事情做出决定的人。

软件架构师在整个软件开发过程中都起着重要作用，并随着开发进程的推进而其职责或关注点不断地变化。

在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。此外，架构师还要经常审查客户和市场人员所提出的需求，确认开发团队所提出的设计;在需求越来越明确后，架构师的关注点开始转移到组织开发团队成员和开发过程的定义上。

在软件设计阶段，架构师负责对整个软件架构、关键构件、接口的设计。

在编码阶段，架构师则成为程序员的顾问，并且经常性地要举行一些技术研讨会、技术培训班等。

随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点。

在软件维护开始时，软件架构师就要开始为下一版本的产品是否应该增加新的功能模块进行决策。

软件架构视图

——软件架构是一种无法以简单的一维方式进行说明的复杂实体。

——多重软件架构之所以必不可少，是因为各类涉众(用户，客户，开发人员，测试人员，维护人员，内部操作人员，其他人员)需要从各自的角度理解和使用架构。

常用的软件架构视图：

功能视图

开发视图

进程视图

部署视图

场景视图

数据视图

实现视图

注：在我们的实际项目中，用的最多的是功能视图，其次是开发视图，没想到还有这么多的视图需要考虑。比如，在MB一期的设计中，我曾考虑过是否有必要作一个软件的部署形式图，最后犹豫中还是出了一个，现在看来是很有必要的了，至少让运维人员明白了MB的软件部署是怎么回事。

新观念

架构的质量属性

在现实的系统中，决定系统成功或者失败的关键因素中，满足非功能需求往往比满足功能性需求更为重要。从技术角度看，质量属性影响重要的架构和设计策略。

质量属性分为系统质量属性和商业质量属性，其中系统质量属性又分为运行时期的质量属性和开发时期的质量属性;商业质量属性包括政治因素，上市时间，成本和收益等。

我们虽然常常把性能，安全，可扩展等词挂在嘴边，但往往在实际开发中这些因素都忽略了，为了赶工期，功能实现是第一位的，最后软件做出来了，质量却不好，问题一堆。实际上，软件的质量不只是产品经理应该关注的，软件架构师也必须关注，给出建议，供管理层做出决策。MB的开发就是最明显的例子，上头规定了上线时间，满足必须的功能，及时上线是附在开发人员身上的魔咒，开发人员只得加班加点的工作，最后软件及时上线了，但后来在运行效率，易用性等方面成为诟病。

架构是有生命力的

运维人员说：软件运行这么慢，架构太烂了!

开发人员说：代码这么难写，架构太不灵活了!

客户说：软件太不稳定了，架构有没有问题啊?

XXX说：YYY架构师太差劲了，怎么就没有设计出一个好架构?

在所有人看来，架构必须是完美的，对所有人感觉都是良好的，能够适应未来的种种变化，能够一劳永逸!

起初我也是这么认为的，但是老师告诉了我们一个新观点：

架构是有生命力的!

“架构是有生命的，是不断变化的。因此，设计架构不能只想着要考虑到所有的问题，设计出一个能够包容所有可能问题的架构，这几乎是不可能完成的任务。因为变化是绝对的，架构总是会修改，关键问题是何时修改?一定不能在系统问题频出、已经来不及补救的时候才去考虑修改，而要在潜伏的问题逐渐露出端倪之前展开行动。”

——FreeWheel CTO和联合创始人 于晶纯

亚马逊，MySpace(进行了6次架构重构)，eBay，淘宝网，这些大型网站都是不断地对架构进行重构，对应用进行升级来应对业务发展的需要的。

所以，我们不能一味的去指责FT的架构如何差劲，MB的架构如何糟糕，公司的这些产品线都是逐渐发展起来的，功能是一点点增加起来的，在功能开发第一的市场战略下，架构成了次要考虑的问题，所以我们不能说当初的架构设计的不好，问题是在于功能增加了，应用变复杂了，而架构没有跟上变化。

架构的思维

全局观

首先，架构师要有全局观，不能瞎子摸象，要看到架构的多个层面，多个角度。如架构的多个视图，架构的质量属性，架构设计，架构模式等，都是从项目的全局视角来看待问题的。

设计的本质就是一种权衡，是各类相互制约的模块间的一种权衡。明白这一点，就要求架构设计上对各个模块应有灵活的控制，以保证用户期望目标为设计出发点，平衡各类资源的使用。

一个好的架构的概念是完整的，模块间的关系是清晰简洁，弱耦合的，模块的接口是抽象稳定的，模块的实现是强内聚和可扩展的。