架构修练二：架构师成长之路（整理网络查到的资料）

在网上（51CTO里）看到的资料转至我个人的博定，给勉励自己：

架构师成长之路：

（1）、 每一个好架构师都是好程序员

江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”，优秀的编码水平，是成为一个架构师的基础。

（2）、 抽象思维：驾驭概念的技能是最高潜力
这其中其实又有两个概念，一个是将实在的事物概念化，一个是将模糊的感觉数量化。看到一个苹果，能够将其抽象为质量、大小、颜色、形状、味道等概念的组合，就是概念化，而量化则是在概念化之上，将苹果用多少克、多少立方厘米来定义；至于颜色、形状、味道等概念，则是还没有完善量化标准的概念。如果在没有彻底理解概念的前提下过分拘泥于数字，那么到头来只是活跃了头脑的计算功能而无助于抽象思维的锻炼。抽象思维是可以锻炼的。程序员要想成为架构师，必须“有意识的开拓技术视野，深入理解公司业务”，这其实就是一个扩展视野的同时，培养抽象思维能力的过程。架构师在项目中处于位置较高的地方，工作的问题很难说找到谁来学习、借鉴一下，更多的是摸索、琢磨。如果你有这样的决心和毅力，那么相信抽象思维的能力也是不会难倒你的。

（3）、技术前瞻性：站在技术的山顶向前眺望

有人谈到技术高手与架构师的区别就在于，架构师不光是着眼于现在，不仅仅局限于开发细节，比如如何调用，如何并发等等。而是跳出三界外，考虑一下面向未来问题和潜在风险的应对之道。

那程序员该如何培养自己的技术前瞻性呢？很大程度上来说还是要学好英语，国外的新东西，老东西的新特性肯定都是用英文写的。即使国内有很多网站也在做外电翻译，但面对海量的信息肯定是杯水车薪。而且有不少程序员所面对的领域本身关注度就不高，靠外部翻译似乎很难实时跟进。这时就需要有良好的外语水平，能看懂国外的技术文章和文档，能与国外相关人士进行交流。

外功是从外部获得最新技术信息，那么内功就是自己的逻辑思维能力和接受能力。再新的技术，其实也与以前的技术有结合。这也是为什么我们说架构师首先是卓越的程序员，也就是这个道理。

（4）、问题解决大师：架构师修练课程-透过问题看本质

什么是本质？将世界万物理解为原子，将整个互联网理解成0和1，这倒的确是非常本质了，不过并不能解答任何问题。从问题看本质，实质上是一个从表层逐步深入的过程。在架构师面对一个用户需求时，这个“用户需求”是非常表层的——比如说，一个自动远程备份数据库的功能。而架构师的主要工作，就是把这样的“业务需求”翻译成“技术需求”。这个过程一方面需要通过抽象思维将用户需求提炼为启动、读取、存储、中断处理等模块，而另一方面则需要看到更深层次的网络、操作系统、硬件等方面，以及其可靠性、稳定性、适用性、安全性等问题。

以eBay为例，按照其架构师Randy Shoup的介绍，电子商务站这样大型的系统有两个层面的功能：“垂直功能，如买、卖、搜索、付款等。水平功能，如数据库、事件与消息系统、服务基础设施、展示框架等。”按照编者的理解，如果说垂直功能是抽象思维的产物，那么其中的水平功能的划分则是一个架构师“透过问题看本质”能力的体现——这些划分体现了架构师看到了表层的功能是建造在哪些因素之上的。同时，架构师要看到“电子商务站”这样一个服务的本质，就是要提供一个多人同时在线进行交易的平台，因此系统的本质也必须包括“功能，性能，可伸缩性，可管理性，安全性，以及可用性”这些因素。否则，即使搭了个架子，没有上述特性的系统是完全无法满足客户需求的。

（5）、多领域知识：架构师-要成为百科全书式的智者

通常来说我们将架构师分为系统架构师、软件架构师等等。虽然有分工不同，各自所处的层次也有不同，但是究其核心能力，跨领域知识的学习能力，是架构师的强项所在。

架构师身为一名技术领袖，需要通过发散知识的光芒来统御开发团队的。如果只是对本行业知识做到烂熟于心，那还仅仅是一名熟练工的水平。要想晋升更高的层次，还需要跳出“只缘身在此山中”的困惑。例如在目前国内架构师，至少有网络领域为依托，物流金融证券等熟知越多越好，这个是应用级别。比如南天的金融平台研发部门，但是这个成不了底层平台架构师。再往上走，很多公司的研发人员不是精通计算机，可能是物理极为精通，比如中软研发声纳软件部门很多人对数据信号极有研究。

谈到跨领域学习，知识面广似乎是最好实现的目标，只要博览群书，加上高中之前各学科扎实的基础，相信大多数程序员本身就具备一定的跨领域学习的能力。但想成为真正的百科全书式的智者，恐怕不光是简单觉得眼熟就行。在条件允许的情况下，程序员其实可以去参加一些其他领域的专业考试。比如参加会计资格证的考试，抑或其他专业中较初级的考试。这样的经历，主要还是在于“以学促考”，通过一定的压力让自己能钻进去学习。

（6）、沟通能力：架构师-善于沟通的技术领袖。

究竟怎样才能是一名合格的架构师，成为一名真正能说会道的程序员呢？首先自然是沟通要清晰明了，平和待人。架构师不能将自己锁在自己的象牙塔上，颐指气使的对程序员发号施令。这样的态度必然遭到程序员的愤恨，大家都是一样的技术人员，只是分工的不同，为什么要受气呢？

（7）、内力：架构师要努力成为内功深厚的高手

讲到内功深厚，大家心想“那我就往死里钻研技术，不就完了？”。确实，很多人理解的内力就是开发技术，包括语言的掌握、对框架的掌握、数据库管理能力、安全管理能力等等。但是我们看到，架构更多的内力体现在对技术的综合运用上，光会编程的程序员，最多就能做到高级程序员，也就是技术实现上的高手。

内功的修炼第一层，自然是开发技术的培养。从写第一行代码开始，就多想为什么，有没有什么其他的路径能实现同样的功能。当我们写了很长时间代码了，是不是就该考虑更多的问题，比如优化、预期未来。其次是对架构的熟悉，下面是大家比较熟悉的Struts 2架构图。要做一名优秀的架构师，就得对各种架构做到了熟于心。

更高层次的修炼，就在于不同技术的学习。要懂得数据库知识，懂得安全监控方面的知识，还要懂得网络构建方面的知识。这是比较高层次的内功修炼，很有可能与程序员目前所处的开发环境关系不大，对程序员来说并不是什么有用的东西。但一个优秀的架构师必须懂得这些，才能更好地抽象软件的使用环境，选择符合需要的架构以及开发模式。

（8）、权衡取舍：架构师-每天要在鱼和熊掌之间做选择

你听说过软件架构师的职业培训中有一个叫做ATAM的课程么？ATAM，全称Architecture Tradeoff Analysis Method，意为架构权衡分析方法。虽然这样的培训并非必要，但是值得我们去学习了解一下。

没有一个人可以建造一个没有缺陷的架构。这个项目可能缺乏时间，缺乏金钱，缺乏人手，或者缺乏合适的技术。在项目从开始到进行中的每时每刻，架构师都需要对这些架构的“缺陷”有明确的了解。

在架构师的艺术气质篇我们提到了“基于需求考虑问题”和“基于系统考虑问题”的不同，并提到这中间会存在一些矛盾，需要架构师来做权衡决策。站在系统的角度上，架构师可能觉得自己手头的资源不够，他需要更多的时间、人以及新技术，但是项目经理和其他团队成员很可能会拒绝，而他们也有自己的理由。

所以Fred George先生提出了“短期滥用”的说法，即在系统能够承受的范围内做出一些妥协。在ATAM方法中，分析的思路是基于“情景”的：你需要提出各种可能的情景，然后来证明在每一个用户使用场景中，系统的哪一些内容是必要的、不可丢弃的——从而确定哪些部分是暂时可以不予考虑的。

作为一名优秀的架构师，比较迫切的管理任务可能就是开发成本与收益平衡的问题。举例说，采用MySQL做数据库与采用Oracle做数据库，价格肯定有很大差距。但是究竟该采用何种技术，架构师需要仔细权衡用户的报价与本公司收益率的问题。又比如说采取甲技术开发出的软件，界面大方性能一般，但是需要耗费程序员更多的劳动时间，那在有些场景下就不如采用乙技术快速开发后节约的大量人力成本，尽管界面有些难看。

（9）、管控能力：架构师-要善于管理整个开发团队

下面是泰勒的相关理论：工作定额原理、挑选头等工人、标准化原理、计件工资制、劳资双方的密切合作、建立专门计划层、职能工长制、例外原则。仔细思考过后，这些东西有很多与现在的工作相似。就拿工作定额和挑选头等工人来说，每位程序员的工作量都是订好的，工资标准也是按照技术最好的“大拿”来做对比。至于人性化管理，满足更高层次的需要，很多项目经理现在还考虑不到程序员的要求，项目经理就是泰勒理论中的职能工长而已。
作为一名优秀的架构师，比较迫切的管理任务可能就是开发成本与收益平衡的问题。举例说，采用MySQL做数据库与采用Oracle做数据库，价格肯定有很大差距。但是究竟该采用何种技术，架构师需要仔细权衡用户的报价与本公司收益率的问题。又比如说采取甲技术开发出的软件，界面大方性能一般，但是需要耗费程序员更多的劳动时间，那在有些场景下就不如采用乙技术快速开发后节约的大量人力成本，尽管界面有些难看。
因此，架构师在管理和控制的能力上，需要有自己独到的见解，而不是简单的认为这是项目经理或者财务部门的事情。身为技术专家的架构师，随不需要处理那些烦杂的日常管理。奇虎架构师李钊在一次接受采访时道出过架构师们的心声，技术人才转向管理就是莫大的浪费。对，如果架构师只是一味的去进行项目管理，那就和其他市场人员没有任何区别了。在这里架构师所需要的管理与控制，其实是从技术的角度，对一些问题的控制，特别是开发过程中的监控，而不是普通意义上的纯粹管理。

（10）、艺术气质：优美的系统与架构师的艺术气质

商业软件项目的首要目标是实现来自客户或公司的商业需求。然而，在架构过程中仅仅考虑到实现商业需求而建立的系统往往缺乏伸缩性、安全性、可维护性、可靠性、可移植性等等，导致其在短短数年内便因无法与时俱进而被抛弃。这一点几乎每一位维护过项目的程序员应该都能够体会到：面对着缺乏文档、不知所云的代码，想要修改或添加一个功能却无从下手。

而一个优美的系统则是可以像有机的生命一样成长的，这是因为从系统开始架构的那一刻起，架构师就考虑到这个系统以后将会面临的挑战，为系统的成长预留好空间。项目经理经常会对这位架构师提出的看似理想化的要求不置可否——项目经理只想着能够尽快以比较低的成本实现客户的需求，然而这些充满艺术美感的想法其实是打造健康——因而优美——的系统的根本因素。

视图模型是业内在20世纪90年代开始逐步建立起来的一套规范（IEEE 1471），不同的视图从不同的角度对系统的不同方面进行关注。之前所提到的项目经理注重商业需求而架构师注重系统健康的矛盾，其实在这个视图模型中都有相应的描述，为架构师开展思路提供了很好的指引。过去的十多年间出现了很多指引性的视图以及框架，一些常见的 包括：

用例视图（Use-Case View）：这是业务需求的角度。

逻辑视图（Logical View）：这是功能实现的角度，用例执行的流程图。

上面两个视图是必需的，也往往是项目经理最关注的部分。如果只考虑这两个角度，系统可以被建立，但正如之前所描述的那样，是不可能优美的。架构师还需要视情况考 虑下面这些视图：

进程视图（Process View）：如果系统是多线程的，高并发的，则需要考虑线程的角度。

部署视图（Deployment View）：如果系统分布在多节点，则需要考虑服务器端和客户端节点等硬件映射的角度。

数据视图（Data View）：如果持久层在系统中很重要，则需要考虑数据的角度。