【转】架构师害怕程序员知道的十项技能

原文：http://developer.51cto.com/developer/top10Architect/

卓越的程序员

每个好架构师都是一位出色的程序员

架构师，听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中，架构师都是高手，都是牛人，都是如此高高在上的存在。

不过，在搞了四、五年编程之后，程序员们往往早已失去了当年对这些“高级”职位的神秘感，甚至会对自己所在项目的架构师抱怨不已，背后里称他们是一群水王。所以有江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”

这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。

这句话按照Fred George先生的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。

而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（Fred George）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。

不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师Randy Shoup先生是如何总结架构师在项目中的职责的：

1. 产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。

2. 技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。

3. 与开发团队一起，完成设计与实施的细节

4. 与开发团队和运维团队一起，完成部署的过程

5. 与运维团队一起，进行部署之后的维护和故障排除

在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。

只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！

然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”

 

综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。

让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”

是的，每个好架构师都是一位出色的程序员。

独家专访Fred George：架构师是使用代码作画的大师

架构师是什么？什么样的人可以成为架构师？架构师的成长过程中会遇到什么困难？这是51CTO开发频道年终活动《架构师最怕程序员知道的十件事》的主旨。虽然并非每一个程序员都希望能成为一个架构师，但潜意识里他们是尊敬架构师的——而一个优秀的架构师往往在举手投足中显示出一个编程大师的风范。

         为了深入的了解这些问题的答案，51CTO开发频道展开了对国内外几个著名架构师的一系列邮件访谈。本次访谈的对象是一位资深的程序员、咨询师和架构师，Fred George先生。

架构师个人简历

Fred George先生在敏捷开发领域颇有声望，在业界有将近40年的开发经验。早年他在IBM工作。退出IBM之后，以独立咨询师的身份在美国工作了十多年。后来他加盟了ThoughtWorks，成为早期致力于推动敏捷开发的一批开发者。现在他离开了ThoughtWorks，在英国的TrafficBroker公司就任解决方案架构师一职。51CTO编辑曾在2009年敏捷中国大会上与Fred先生进行过一次面对面的交流，编者对Fred先生充满生趣的演讲和对编程如同小孩子一般的热情印象颇深。

以下是此次访谈的具体内容。

51CTO编辑：不同的企业和项目经理对架构师往往定义不完全相同。在您的团队中，对架构师是如何定义的？对于招聘的架构师会有怎样的技能要求？

Fred：首先澄清一下，我的这个头衔：“解决方案架构师(Solutions Architect)”，其实只是为了签证弄的一个头衔。我其实是没有头衔的。不过呢，我确实自诩为一个架构师。

基本上，架构师是使用代码作画的大师。最近在那些顶级的软件思想者中刮起了一股讨论系统之“优美”以及“简约”之风。一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。

在我看来，系统是一个个有机的生命。跟企业一样，系统也需要施肥浇水，需要健康的成长。与企业一样，一个系统可能会在短期内被滥用（比如在需要短期内快速盈利的驱使下），不过如果滥用的时间过长，系统最终将会无法支持。与CEO一样，一个架构师对系统的这个特性了如指掌。他们能够识别什么是滥用，系统能够承受的限度，并将系统引回到健康的道路上。

51CTO编辑：假设有三名优秀的程序员，A尤其擅长沟通与团队管理；B的编程功底深厚，且对新技术能快速掌握；C在逻辑思维和抽象能力方面表现优秀。您会重点培养哪位程序员成为架构师？

Fred：不是每个人都能够具有一个架构师的能力。在你提供的选项中，C的成功几率是最高的。驾驭概念的技能，在我看来是每一个人最高的潜力。对于其他的需求，如语言、经验等，我可以通过培训来建立。

B有可能会成为一个好架构师：她显示出了概念理解能力的一些苗头。如果她开始领悟一个好系统的模式(pattern)是怎么一回事，那么她便能够完成转型。

对于A我不作考虑。把他放在架构师的位子上，就相当于把“架构师”当做“设计师”的升级版。这就好像把你的祖父扔到F1赛车场上，仅仅因为他开车的时间最长。这个绝对不对头。

领导能力是重要的，但并不是一个好架构师的组成因素。

51CTO编辑：对于一个刚刚从程序员转型过来的架构师，通常有哪些问题是他最难把握的？

Fred：如果你从程序员的职位转型，决定自己不再是程序员了，那么你的架构师生涯将是短暂的。最好的架构师都在写代码。Kent Beck曾经写道：“代码就是设计与残酷现实之黄昏的交汇(Code is when design meets the harsh reality of dawn.)”。他的意思是，我们画出来的设计都是美好的，但最好的设计仅仅是被翻译为优雅代码的那些。一个无法将愿景带入代码的架构师将永远无法了解我们这个急速变化的行业所展示的深度。

所以说，不编程的架构师的职业生涯是短暂的。

做为一个架构师，我需要实现（这个过程是结对编程，我会有一个搭档）一个系统最难实现的一部分。我将其称之为“先锋”，因为这是我检验我脑中的主意是否真的是一个好主意的过程。我在第一次实施中会细化这个主意。然后我才会放心的让编程团队的其他成员按照这个模式来走。这就是“架构”。

有点跑题了。对于一个菜鸟架构师而言，最大的障碍就在于承认你并不知道详细的答案，但你信心满满的认为可以和程序员和设计师一起找到这个答案。

另一个新手架构师经常遇到的问题是“优美”以及“简约”。每次当进行决策的过程中出现这些概念的时候，项目经理往往对这样的理由不置可否。项目经理通常有短期目标要实现，而对优美还是简约这样的概念并不感冒。但事实上，他们这是对系统未来健康状况的不重视。

最后，菜鸟架构师往往是出色的程序员。而他会发现团队中的其他程序员贡献的代码看起来不太美。菜鸟架构师必须要学会界定哪些丑陋的代码是可以接受的，哪些是不能接受的。

架构师是艺术家，他们的成就往往不会在他们活着的时候被赞赏。

附录：问题与Fred George邮件答复内容的英文原文

1. How to define Architect

Usually, different project managers in different teams have somewhat different definitions for the term Architect. In Amazon team, what does an architect do, and what's your recruiting criteria for an architect?

-----------------

A: Effect architects are master painters of code. Recently, leading software thinkers talk about the "beauty" and "elegance" of systems. An architect is one who not only sees that beauty, but is able to create it in the systems being built. I think of systems as living organisms. Much like corporations, they need to be nurtured to grow and be healthy. Much like corporations, a system can be abused for a while (for short term gains like quick profits), but will ultimately fail if abuse lasts too long. The architect, like the CEO, understands this about their systems. They recognize abuse, understand how long the system can sustain the abuse, and guides the path back to health.

----------------------

2. Choosing the potential architect

Suppose you have 3 good programmers in your team. Programmer A tops in communication skills and team management. Programmer B tops in coding practices and theories, as well as coping with new technical skills. Programmer C tops in logical thinking and explaining abstract concepts. If you'd like one architect to come out from the three, which one would you prefer?

---------------

A: Not everyone is capable of being an architect. Of your choices, Programmer C has the best chance of success. The conceptual skills are what I judge when seeing the ultimate potential of an individual. The rest of the needs (languages, experience, and the like) I can train. Programmer B might become a good architect; she seems to be showing the signs of conceptual understanding. If she begins to discern the patterns (beauty, elegance) that good systems have, she can make the transition. Programmer A is not a candidate. Making him an architect is treating "architect" as the promotion after "designer". That is like putting your grandfather in Formula 1 racing just because he has driven the longest. It just doesn't work. Leadership skills are important, but it is not a factor in being a good architect.

-----------------

3. From an experienced architect's point of view, what do you think are the main obstacles faced by those novice architects who just transformed from a programmer's role?

----------------

A: If you have transformed out of a programmer role, you will have a short career as an architect. The best architects still write code. Kent Beck once wrote, "Code is when design meets the harsh reality of dawn." He was saying that all designs look pretty when we draw them, but the best design translates into elegant code. The architect that doesn't carry his vision into code will never gain the insights that our changing industry exhibits. That is why the career is short for the non-programming architect. As an architect, I will implement (with a partner for pair programming) the most difficult parts of a system. I call it "pioneering", the process where I see if an idea in my head actually is a good idea. I will always refine the idea in that first implementation. Then I feel comfortable letting the rest of the programming team follow that pattern. That is the "architecture".

I drifted from your question. The main obstacle faced by a novice architect is admitting that you don't have the detail answer, but that you are confident that you will work with the programmers and designers to find it. Another problem a new architect faces is over "beauty" and "elegance". When making choices that involve these concepts, managers are particularly skeptical of that reasoning. Managers often have short term goals, and are indifferent to beauty and elegance. Actually, they don't value keeping the system healthy for tomorrow's changes. Finally, the novice architect was probably a superior programmer. Now other programmers are contributing code that is not as pretty. The novice architect must learn what degree that ugly code can be accepted and at what point to reject it.

Architects are artists, and often their work is not appreciated during their lifetimes.

抽象思维

架构师驾驭概念的技能是最高潜力

在近日51CTO开发频道对数位架构师进行采访的时候，编辑观察到一个很有意思的现象，那就是他们在提起一个假想架构师的时候会下意识的使用“she”或者“她”来指代。然而我们这次采访到的的架构师们却全都是男士，这似乎是一个比较难以理解的现象。

对高级架构师王翔先生的访谈似乎能在一定程度上解答这个现象的由来。在访谈中，王翔先生说到自己在特定情况下会优先培养女性做为架构师，因为“架构师在创造性、知识汇总方面根据个人经验似乎女性更适合。”

无论王翔先生的个人经历是否常态，既然说男人来自火星而女人来自金星，那么这至少表明是否适合架构师一职与人的思维模式有很大关系。在这一系列的访谈中，所有接受采访的架构师们都一致的表示逻辑思维和抽象思维能力是一个架构师最重要的素质。eBay的Randy Shoup先生称拥有条理清晰的逻辑思维能力的人“就像稀有动物那样难找”。Fred George则表示“驾驭概念的技能，在我看来是每一个人最高的潜力”，并表示自己不太介意这样一个苗子在其他方面的技能和经验的匮乏，因为在他看来除了思维之外的其他因素都是可以培养的。

逻辑思维，抽象思维，这些干巴巴的名词并不比高举某某旗帜、将某某贯彻到底的口号说明了更多问题。架构师们习惯了思考“虚”飘飘的概念，但如果不能让非IT人员明白这个或那个概念到底是在说什么，那么这个架构师也注定是失败的（详见架构师技能之沟通技术篇）。所以首先有必要解释一下这些架构师们说的这两个概念是什么意思。

程序员对逻辑思维是再熟悉不过了，因为程序员写的代码都是逻辑。如果怎样怎样就做什么什么，如果什么什么就触发这个或停止那个。编写条件这样的逻辑构成了代码中的绝大部分，因此缺乏逻辑思维能力基本等同于不可能成为程序员。架构师必须要有很好的逻辑思维的理由，事实上和架构师必须先是个出色程序员的理由是一样的（详见架构师技能之优秀程序员篇）。

因此本文的关键在于抽象思维能力。这个能力常常被与物理成绩或数学能力等同起来，但它事实上并不是计算能力。比如说小学常见的数学题，两个城之间的铁路长度500公里，一辆火车平均时速100公里，问这辆火车从这个城到那个城需要多少时间。学生们往往会陷在于500公里、100公里/小时和5小时这些数字中，但是这道题的抽象因素其实是在“长度”、“时速”和“时间”这三个概念当中。

这其中其实又有两个概念，一个是将实在的事物概念化，一个是将模糊的感觉数量化。看到一个苹果，能够将其抽象为质量、大小、颜色、形状、味道等概念的组合，就是概念化，而量化则是在概念化之上，将苹果用多少克、多少立方厘米来定义；至于颜色、形状、味道等概念，则是还没有完善量化标准的概念。如果在没有彻底理解概念的前提下过分拘泥于数字，那么到头来只是活跃了头脑的计算功能而无助于抽象思维的锻炼。

人们往往发现优秀的数学家、物理学家以及软件架构师有着很多相似的素质，甚至往往能够一人精通这好几个领域（比如UML之父James Rumbaugh），其中很重要的原因就是这个抽象思维的能力。架构师在接到商业需求之后，最主要的工作就是将其转化为技术需求。这个过程的完成与架构师抽象思维的能力密不可分。好比说这个项目是eBay那样的电子商务平台，那么eBay的主架构师第一个闪过的念头多半就是：这个系统，将会有“买、卖、搜索、付款等功能。”而负责每一个功能的架构师，又需要对这些部分进行进一步的抽象化。

很难想象一个缺乏抽象思维能力的人，要如何担负起架构师的工作。

而抽象思维和之前所讲的逻辑思维能力，并非是同一个东西，这也是为什么并非所有优秀的程序员都能够成为一个好的架构师。不过编辑在这里并不是想说难以成为架构师的程序员都是缺乏天赋，事实上抽象思维并非是一个不能培养的能力，只是它需要你主动地去思考。正如支付宝的冯大辉所说，程序员要想成为架构师，必须“有意识的开拓技术视野，深入理解公司业务”，这其实就是一个扩展视野的同时，培养抽象思维能力的过程。架构师在项目中处于位置较高的地方，工作的问题很难说找到谁来学习、借鉴一下，更多的是摸索、琢磨。如果你有这样的决心和毅力，那么相信抽象思维的能力也是不会难倒你的。

技术前瞻性

架构师：站在技术的山顶向前眺望

铁打的程序员，流水的技术。程序员的开发生涯可能长达几十年，但一门技术的平均寿命却不长。因此作为程序员们的技术领袖，架构师必须有很好的技术前瞻性，要先于大家了解到最新的技术

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

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

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

但是架构师并不是将前沿技术的名词天天挂在嘴上之人，整天只知道在程序员面前大谈“云计算，SaaS”这些东西的架构师注定成不了好的架构师。新的技术虽好，但是程序员接受和再培训还需要时间，还要考虑到系统的兼容性问题。因此，夸夸其谈的名词专家，并不是我们努力的方向。好的架构师，应该提前想到如何为程序员尽可能减轻负担，比如数据库软件新的特性可以提高性能，简化查询步骤，那架构师是不是第一时间要引导程序员去适应新的特性，提高开发效率。

 

被技术潮流抛弃的架构师是可悲的

技术前瞻性还体现在对新技术的选择上，哪些东西适合自己团队，哪些不适合肯定要自己心中有本帐。工具选好了再返工的人力成本和时间成本是很多公司没法负担的，利润就那么多，经不起瞎折腾。程序员在自己的学习过程中，也可以适当培训一下自己，比如新的IDE中有新的功能，但是要安装这新版本的IDE需要更新系统，更新硬件，还要更新和数据库的接口。这一套下来花费的时间成本是多少，换算成工资是多少？我想事事都这样过一遍，我们在做选择的时候就不会盲目。

架构师在自己所处的领域肯定了解颇深，未来本领域技术该如何发展，应该有自己的理解。也会对未来技术的发展有所期盼，有自己的见解。当然这属于比较发散的想法，个人有个人的目标。

51CTO总结：技术人生如逆水行舟，不进则退。

问题解决大师

架构师修炼课程：透过问题看本质

         一个刚刚从学校毕业的、致力于投身编程事业的年轻人，在投递了n封简历之后，终于如愿以偿得到了第一份编程的工作。如果他在求学期间没有积累过项目经验，那么可以说这就是他职业的起点，他青涩的编程之路开始了。

         可能他一开始会满腔抱负、意气风发的按照自己的方式完成小头目交给自己的一些练手任务，然后懊恼的发现小头目对这些看似能够完成任务的代码大摇其头，指指点点；然后在真正进入项目之后，又会被各种不知道从哪里冒出来的bug和漏洞搞得晕头转向……

这些问题一方面和这位菜鸟程序员缺乏经验有关，但是在过来者看来，造成这些问题的一个主要原因正是在于，这位程序员没能看到问题的本质。

而看到问题的本质，也是架构师所必须具备的素质。

所谓看到问题的本质，实际上是一个思考的层面问题。比如说，你现在看到的这篇文章，从表面上看，就是你的显示屏显示出来了一些文字，但这明显不是它的本质。从内容而言，这篇文章是一篇有关架构师技能的文章，它是对一个职业的某一项能力的描述；从技术而言，这篇文章是在世界上某台服务器上的数据库中提取出来的某些信息，经过漫长光缆和层层协议的传递，经过你的网线插口（或无线接收器）进入了你的机器，通过浏览器解读并最终呈现出来。

听起来，这个和另一篇文章介绍的同样是架构师所需要的“抽象思维”有点像，只是方向不同：抽象思维是往高层次的升华，透过问题看本质则是往深层次的挖掘。

让我们看看文章一开始的那位菜鸟程序员为什么总是失败。如果你是一位PHP程序员，那么可以参考这篇文章，里面总结了一些常见的问题。最简单的一个（有时被用作面试题）可能出现在这样的情况下——小头目说：“显示用户提交的ID名”，然后菜鸟程序员大笔一挥：

 

1.  echo $_GET['username'];  

 

小头目阅毕自然抓狂不已，因为这是一个再明显不过的安全隐患。菜鸟程序员被小头目训了一顿，然后知道这样做是有问题的。

这个事情如何与通过问题看本质有关？这个就取决于这位菜鸟程序员是如何改正这个错误的。如果这位程序员只是把下面的那段“合格”代码抄袭过来并死记硬背，那么，以后等待这位程序员的大概是比较悲惨的结局——因为漫长的代码生涯中有极多类似的问题，而等到他进入真正的项目之后，犯错误是有成本的。他的学习方式表示他没有主动避免这样类似问题的能力，那么他可能将会造成极大的损失，从而最终失去在这个行业的竞争力。

但是，如果他了解到代码之下，更深层次的那些机制，比如echo是如何执行的？在什么时候执行的？哪些字符可能导致安全问题？htmlspecialchars为什么能解决这个问题？它真的解决这个问题了么？那么他将会一点一点的进步，逐渐成为一个合格的程序员。

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

         上面述说的是个小型需求，按照某些行业标准，这顶多只能算是一个资深程序员的工作，而没有达到“架构”的规模——即，非大型项目中不存在真正的架构师（按照王翔先生的描述，大型项目差不多是“100M(RMB)、B(RMB)、10B(RMB)”这些数量级）。那么，让我们看看大型系统的情况。以eBay为例，按照其架构师Randy Shoup的介绍，电子商务站这样大型的系统有两个层面的功能：“垂直功能，如买、卖、搜索、付款等。水平功能，如数据库、事件与消息系统、服务基础设施、展示框架等。”按照编者的理解，如果说垂直功能是抽象思维的产物，那么其中的水平功能的划分则是一个架构师“透过问题看本质”能力的体现——这些划分体现了架构师看到了表层的功能是建造在哪些因素之上的。同时，架构师要看到“电子商务站”这样一个服务的本质，就是要提供一个多人同时在线进行交易的平台，因此系统的本质也必须包括“功能，性能，可伸缩性，可管理性，安全性，以及可用性”这些因素。否则，即使搭了个架子，没有上述特性的系统是完全无法满足客户需求的。

看到这里我们应该明白了，“透过问题看本质”并不是什么神秘的能力，而是有一定经验能力的程序员都具备的能力。如果你在编写Java代码时考虑到了JVM的性能，在编写PHP代码时想到了潜在的安全问题，甚至于在编写HTML+CSS页面时考虑到了不同浏览器的兼容性，这些都体现了“透过问题看本质”的素质。只是，架构师之所以为架构师，是在于他们在面对庞大系统之时，仍然能够敏锐的发现其底层之真实。这不仅需要此哲学层面的“内功”，还需要架构师具有多领域知识和经验的积淀。

“透过问题看本质”，这也是程序员往往需要修炼十余年才有资格晋升为架构师的主要原因之一。程序员们，好好努力吧！

 

多领域知识

要成为百科全书式的智者

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

         首先，作为一名卓越的程序员，架构师肯定不欠缺开发方面的知识。从架构到方法论，从数据处理到安全监控。可以说IT开发层面上，架构师可以做到炉火纯青的地步。但是这仅仅是一名卓越程序员的能力级别，离架构师那还有很大的一段距离。

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

很多程序员对架构师似乎存在偏见

这里就会出现一个常见的问题“架构师是不是一个只会夸夸其谈，只会忽悠下面人而对软件开发了解不多的人？”更尖酸的问题还在于架构师连一段代码都不会写。相信这是一定的误解，就好像银行的高层管理人员，要更多的从宏观的角度考虑问题，尽管他们点钞的能力肯定不及下面的柜台人员。事必躬亲的诸葛亮，最后的结局还是国破家亡，过多的干预细节忽视整体，绝对是要打败仗的。架构师学习更多跨领域知识，也是为了在接受一个项目时，能更快更准确的找到解决问题的“命门”。

有的程序员也会说，如果多学习跨领域、跨学科的东西，会不会成为什么都懂，但什么都不精的人？其实在这里的跨领域，并不是要求大家都成为每个领域的专家。最重要的是有一门敲门砖，学习的引子。如果开发一套金融系统，对于财务结算以及处理方法都不了解，那别说是胜任架构师的任务，连普通程序员的工作也不可能做好。假设大家工作一段时间后，对某领域很了解，但由于工作变动的缘故，到其他公司后，开发的领域完全不会。这里就要用到跨领域知识学习的能力了，需要大家样样都要知晓。

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

还有一种跨领域学习的目标，就是多语种的学习。学习除英文之外的语言，既能开拓国际视野，也能在平时的工作中有所建树。

架构师害怕程序员知道的技能，其实就是他们自己“独门绝技”。虽然他们自己不说，但是我们自己还是能总结出来，在一定深度之内成为一个“杂家”并没有什么不好。其关键在于所学的跨领域知识，能否成功的运用到工作中去。51CTO在独家采访王翔高级架构师时，他曾提到，一个致力于成为架构师的程序员。需要尽可能的参加大的项目开发，尽管积累1000个小项目的经验也是很好的程序员，但好的架构师必须参与更大的项目，哪怕数量不多。从中我们能解读到一个信息，大的项目意味着学科跨度的增大，所需要学习的跨领域知识必然也足够大，也就更有利于程序员向架构师晋级。

沟通能力

一群善于沟通的技术领袖

         架构师的沟通方向与项目经理相比，还是有一定的区别。比如项目经理有很大一部分时间需要与客户进行沟通，进一步弄清需求。而架构师的沟通主要在于开发团队内部，一种纯技术上的沟通。这也是作为技术领路人的架构师，最日常的工作。

         当架构师对整个系统分析完毕，有一些架构师喜欢昏天黑地的奋斗几天，然后写出一本厚厚的架构书扔给程序员。在此之后就不做过多的交流与沟通，“具体实现？那是程序员的事情，我怎么能去干涉他们呢？”其实在这里，这位架构师就犯了错误，他并没有将自己真正融入开发团队中，而是以一种高高在上的救世主姿态出现。其实架构师未必就是神人，很多错误还是要大家一起来研究来解决的。

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

做到人性化的沟通，需要我们在平时就进行培养。写出大部头的架构书，有的时候并没有用VISIO画出的简单架构图好理解。人对图形理解远远大于对文字的理解，直观简单的UML图可以极大的方便程序员理解架构师的意图。其次，可以召开小范围的技术人员会议，大家一起来讨论，一起理解架构师真正的意图。甚至就是一块小白板，几支笔就能把问题摆清楚，讲明白，统一意见后的团队必然干劲十足，再不会出现互相推诿的情况。

架构师就相当于一支球队的主教练，如何将自己布置的战术交到执行的球员，也就是开发人员的脑袋里，是关乎胜利的关键。那么怎样才能成为一名能说会道的程序员呢？

在一般人的印象里，程序员都是一群略显呆滞，沟通能力不强的技术狂人。逻辑思维非同常人，但就是倒不出来。有些人通过找女朋友作为旁证，连经济适用男中的定义原型都是IT人士，月薪4000以上，不善言谈，最后娶一剩女为妻。看来我等程序员，真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语，但是也看到沟通能力上，程序员还有很大的发展空间。

 

其实很多程序员都是善于谈吐的，木讷的形象只是人们的误解。但是如何来改变呢？首先我们需要更多的感性思考，说话时也要注重别人的感受，尊重对方才能更好的交流。微软MVP陈广琛在与51CTO编辑谈到程序员沟通能力时，曾说道：“很多程序员总能列出一堆的理由来，说明为什么自己不适合学习或者不需要掌握某项与程序无关的技能，例如说演讲、英语、设计等等。但其实问题并没有那么复杂，你需要考虑的只是多学一项技能是否对你的职业发展更有利，只要你愿意，没什么是不能改变的。”

51CTO总结：架构师不是油腔滑调的程序员，但是一句话都憋不出来的程序员，是做不好架构师的。

内力

架构师要努力成为内功深厚的高手

一听到架构师，首先便想到的是在一间宽敞的房间中间坐着一位衣着得体的中年男人，望着落地窗外的风景凝思，万千思绪在脑海里翻腾，颇有运筹帷幄千里外的气势。程序员究竟是做架构师还是项目经理，最近看到微软潘正磊女士的一篇博文，给出了一些启示。

“当时我们团队来了一位刚被提拔的开发经理，每次当我陈述完一个问题，他都会迫不及待地提出他的解决方案。在这之后很长的一段时间，他还是一直习惯性地建议我如何如何处理问题。通过平日的观察，我也发现他更喜欢花时间对技术和产品进行深度探讨，而非团队管理。于是几个月后，我找了一个机会跟他说，“我觉得你做软件架构师说不定会更有意思。”而他自己也觉得这个建议不错。几个星期后，他真的转去做架构师的工作，我们团队也迎来了一个新的开发经理。”

这个例子中体现出来的正是架构师深厚的技术底蕴，或许很多程序员更向往项目经理的职位。从上面我们可以看出，程序员在平时的培养过程中还是过于看重技术处理细节，而不喜欢管理。这样看来，成为架构师还是更多程序员的最终归属，尽管项目经理的头衔看起来是更吸引人，但是架构师作为一个纯技术性岗位，更适合广大的程序员。

修炼内功不等于死钻开发技术

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

51CTO编辑在对高级架构师王翔先生的采访中，曾提到这样一个问题“假设有三名优秀的程序员，A尤其擅长沟通与团队管理；B的编程功底深厚，且对新技术能快速掌握；C在逻辑思维和抽象能力方面表现优秀。您会重点培养哪位程序员成为架构师？”

王翔的回答是这样的“C，后面依次递减是B、A。A更适合做项目经理、产品经理。而且根据个人的经验，虽然女性程序员开发阶段显得不如男性那么快深入和入手（Programmer），但能坚持到Developer、S. Developer、 Designer、S. Desinger阶段她们的思维能力优势就显示出来。如果B是女性Desinger级别的人员，我宁愿选择培养她，因为架构师在创造性、知识汇总方面根据个人经验似乎女性更适合。”这里我们看到，内力更多的是一种思考能力，结合技术的思考能力。光有程序开发的能力，不会思考，那只能做个代码狂人。只思考而没有脚踏实地的技术开发能力，那就是忽悠人的表现，更不招人喜欢。

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

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

权衡取舍

每天要在鱼和熊掌之间选择

         在访问聚聚呀项目总监梁远华先生时，梁先生说到“权衡取舍”是一个架构师在项目中最难把握的。“一个产品会有很多的东西要做，什么是可做的，什么是重要的，什么是将来能做的，每天都做做选择题。”

         eBay的杰出架构师Randy Shoup先生也表示“对权衡取舍方面有着出色的把控能力”是自己团队招聘架构师的一个重要要求。

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

ATAM概念流程图

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

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

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

到了这一步，便已经是一个技术性问题；但是这个问题的解决过程却是对架构师“软”技能的一个考验：即架构师有没有看到各方面诉求的差异，以及有没有意愿为了这些差异而做出妥协。

案例分析1

让我们看一个案例，这是现任微软Visual Studio Business Applications总经理潘正磊女士在博客上分享的一段经历：

“分享一件去年发生在上海Visual Studio团队和印度SQL Server团队之间的故事。两个团队邮件往来10个回合后仍无法在某个问题上达成一致，因此上海团队把我拉进了邮件讨论。于是我从头开始读邮件，读到第四封我大致了解到，分歧的根源在于，两个团队所沟通的，根本不是同一件事。

印度团队认为自己开发了一个特别棒的SQL Compact工具，能满足客户的重要需求，所以要求把这个功能加入Visual Studio 2010 Beta 1 (Visual Studio 2010 的第一个公开测试版)；上海团队认为当时已接近测试版的发布日期，考虑到功能加入产品前必须遵循的一系列发布流程，时间上恐怕来不及了。之后的邮件里，印度团队一直强调这个功能是多么棒，应该让它在测试版中发布（也就是一个解决方案），却从没有解释他们要解决什么问题；上海团队则不断重申功能加入必须按流程来，可见他们之间的交流完全错位了。在这个典型的案例中，印度团队努力推动一个解决方案，却没有想清楚所要解决的问题为什么会对上海团队也非常重要。之后，我们发现的确有一个用户使用场景需要用到SQL Compact工具，于是我们询问新工具对这个使用场景有何帮助，是否能与其他新功能兼容 … …一旦我们能明确这个问题的本质，我们就不难找出双方都接受的解决方案，例如，立即加入第一个测试版，或稍后加入第二个测试版，甚至是加入Service Pack等等。”

如果说架构师的艺术气质体现在其把系统当做生命、站在系统本身的角度思考问题，那么架构师出于对客户、项目经理、开发者和测试者不同视角的理解而做出权衡妥协则充分体现了其职业性。上面潘女士提到的案例，是一个大型项目中的两个开发团队之间的理解冲突所引起的。

A：一个特别棒的功能应该被加入到产品发布中。

B：一个功能加入到产品发布中应该要谨慎并经过充分的审核。

这是“把一个功能加入到产品发布”从两个角度的解读，两个解读都有自己的道理。而在潘女士参与之前，双方的论点没有交集，“交流错位”了。而要实现权衡与妥协的前提，则是让B了解“这个功能是很棒”，并且让A了解“新功能必须在谨慎考量之后才能加入产品发布”。在潘女士的努力下，双方最后都理解了对方，并找到了都能接受的解决方案。而这个过程正是通过设计和描述“场景(scenario)”来推动的。

案例分析2

上面是开发工具项目中的一个小案例，下面让我们看看另一个案例。Amazon.com的CTO，Werner Vogels在08年的12月底发过一篇很有参考价值的博文：Eventually Consistent（最终一致），讨论对象是Amazon的S3，SimpleDB，EC2等大型云计算服务。Werner对这些服务的描述直达本质，一针见血：“这些服务需要在安全、伸缩性、可用性、性能以及性价比方面获得高分，同时必须维持全球上百位客户不间断的使用需求。”

文中讲述了不少深入的架构知识，对于广大程序员而言或许有些难以理解；但是有一句话是一句很直白的经验总结，充分的解释了“权衡妥协”的意思：“在一个理想的世界中，只存在唯一一个一致模型：在实施一次升级之后，所有观察者都能够看到这个升级。”言外之意就是，对于系统而言，在某一个地方或某一个层面发生的改变，势必将影响到系统的其他地方和层面，乃至整个系统。正因为系统的各个部分是互相关联的，因此为每一个变动考虑权衡（trade-off）是必要的，有意义的。

Werner提到的一个正面案例就是在90年代中期的时候，人们只知道可用性(availability)很重要，但对于追求可用性需要牺牲什么浑然不知。出于对可用性权衡的研究，加州大学的Eric Brewer教授提出了CAP理论，认为对于一个共享数据的系统而言，数据持续性、系统可用性、对网络划分的耐受性这三个属性（property）是不可调和的，任何时候只能同时达成两个。

虽然理论只是理论，但理论并非凭空而来，Eric的理论是总结了90年代大型互联网系统建设的经验研究成果。对于Amazon云计算服务的架构师而言，这些经验总结自然是无法忽视的；在知道了鱼和熊掌不可兼得的情况下，要深刻理解各个方面不同角度的诉求，并找出各方都可以接受妥协的制衡点，自然是必不可少的。

         总结

具体要如何制衡是一个很大的话题，甚至于每个系统都会有不同的情况。很多人在各个方面都做过很多研究，指导架构师们一些方向。对于架构师而言，仅仅有权衡妥协的意识还远远不够：这个意识只是前提之一，如果缺乏了对技术扎实的了解，那么这个意识则毫无意义。同时在分析权衡的过程中会有很多抽象的概念（这些概念可能还需要被量化），并且深入到系统的各个层面，因此架构师的抽象思维能力和看到问题本质的素质也是必须的。

抽象能力，深入本质，权衡意识——这三点都是十分珍贵的思想素质。这三种能力配合丰富而扎实的“硬”技能（技术）、合格的“软”技能（沟通）以及敏锐的眼光，无论在哪个行业都能成功。而由于架构师这个职业本身就是IT界的高级职业，这所有的能力和素质就都成了架构师的入门必备敲门砖。不过每个人的时间、精力以及天生素质都是不同的，本次介绍的架构师十大技能全部修炼是很困难的。想要成为架构师的程序员们，首先要自己权衡决策一下，看看自己应该如何修炼才能达到最好的效果——这也是权衡能力的一次练习吧。

管控能力

架构师要善于管理整个开发团队

管理被很多开发人视作“虚”的东西，平时程序员也不会去钻研管理的学问。身为程序员中的领路人，架构师一般也被认为依靠人格力量进行管控，更多的是以理服人。可以说在现阶段的中国，很大程度上还处于泰勒的科学管理阶段，员工只需要机械，高效的完成工作即可。

下面是泰勒的相关理论：工作定额原理、挑选头等工人、标准化原理、计件工资制、劳资双方的密切合作、建立专门计划层、职能工长制、例外原则。仔细思考过后，这些东西有很多与现在的工作相似。就拿工作定额和挑选头等工人来说，每位程序员的工作量都是订好的，工资标准也是按照技术最好的“大拿”来做对比。至于人性化管理，满足更高层次的需要，很多项目经理现在还考虑不到程序员的要求，项目经理就是泰勒理论中的职能工长而已。

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

因此，架构师在管理和控制的能力上，需要有自己独到的见解，而不是简单的认为这是项目经理或者财务部门的事情。身为技术专家的架构师，随不需要处理那些烦杂的日常管理。奇虎架构师李钊在一次接受采访时道出过架构师们的心声，技术人才转向管理就是莫大的浪费。对，如果架构师只是一味的去进行项目管理，那就和其他市场人员没有任何区别了。在这里架构师所需要的管理与控制，其实是从技术的角度，对一些问题的控制，特别是开发过程中的监控，而不是普通意义上的纯粹管理。

在51CTO架构师系列选题文章中，有一篇是讲沟通能力的文章，其实这就是一种“管理”。通过这样的管理，能增强技术团队内部的团结。安全监控也是架构师的重要职责，负责监督整个开发过程中可能出现的问题，在出现问题后还要牵头及时解决问题。这里我们讲到的管控能力，就是这种内部团结的实现，是一种对于程序员人格尊重的实现。马斯洛的五种需求理论中，就有“被尊重的需求”，程序员在一个感觉轻松，被尊重的环境中，其潜在的创造力是难以预料的。

马斯洛五种需求是良好管理的根基

良好的驾驭管理开发团队的能力，能够让架构师在开发项目中游刃有余，不会出现意料之外的干扰。而对于程序员来说，愉悦的开发环境，不光是一个好心情，更能写出优美的代码。当然要做到这一点，架构师自己要有良好的人格修养，能从内散发出人格魅力。另外良好的技术内功也是必备条件，要能让程序员们心悦诚服的接受架构师的领导，而不是发出“架构师一行代码都不会写！”的质疑。

艺术气质

优美的系统与架构师的艺术气质

 “系统是一个个有机的生命。跟企业一样，系统也需要施肥浇水，需要健康的成长。与企业一样，一个系统可能会在短期内被滥用（比如在需要短期内快速盈利的驱使下），不过如果滥用的时间过长，系统最终将会无法支持。与CEO一样，一个架构师对系统的这个特性了如指掌。他们能够识别什么是滥用，系统能够承受的限度，并将系统引回到健康的道路上。”

上面是一段架构师对于构建优美系统的描述。这段话的主人说，“架构师是使用代码作画的大师。”——在他看来，架构师最大的价值在于艺术。这并非是Fred George自家的看法，高级架构师王翔先生也表示“好的A（编者注：A即Architect，架构师的简称）需要有些艺术气质”。

什么是优美的系统？

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

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

架构师的艺术气质使其站在了与项目经理不同的立场上：项目经理从商业需求的方向考虑，而架构师则从系统本身的方向考虑。在商业气息很浓的项目中这会引发一些冲突，这也是为什么最出色的系统往往出自学院，而商业项目中的架构师必须具备权衡取舍及妥协能力的原因（参考架构师十大技能之权衡取舍篇）。

艺术气质的另一体现就是对简约的追求，这在Google或Apple的大部分产品上有很好的体现。看起来是两回事，不过系统的简约与系统的健康往往是相辅相成的。

架构师的艺术气质

在软件开发产业发展的过程中逐渐建立起了一些行业准则和参考标准，这些将有助于架构师在面对复杂需求时仍然能够保持清晰地头脑来思考问题。学习前人总结的软件与架构方面的知识，遵循既定的指导标准——比如，按照模版编写软件架构文档——看似死板，却是必要的修炼。这些架构师的基本功是全面的、抽象的、深层次的。没有这些基础，那么架构师连实现商业需求都会感到吃力，更不要说去顾及需求之外的东西。另外我们提到过架构师需要有前瞻性：超前的眼光是架构师实现其艺术追求的弹药。

阅读公开的软件架构文档（Software Architecture Document）是一个很好的学习途径（在Google上能够找到很多）。软件架构文档是架构师在项目早期阶段对于系统的一个描述性概览，这份文档提供了这个系统预计实现功能的概述，这个系统将会使用什么技术以及可能存在的技术局限，以及最重要的部分：视图模型。

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

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

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

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

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

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

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

还有很多其他的视图，在这里就不一一列举了。这些视图都是从系统的角度来看问题。有些视图框架有一定通用性，比如业内广为流传的4+1模型、RM-ODP模型等等；但是对于每一个系统需要考虑哪些视图，则需要架构师去摸索、去感觉、去研究；况且现在新技术层出不穷，一个比较前沿的项目需要从前人没有考虑过的角度看问题也不是没有可能。如果架构师没有一定的艺术气质来指引方向，那么一味的照搬现有的模式可能会水土不服而使系统变得臃肿复杂，而完全不考虑商业需求之外的因素则会让系统先天不足而夭折。

不过正如之前所提到的，如果没有扎实的技术基础，如果架构师缺乏全局观、抽象思维能力以及透过问题看本质的能力，那么他仅仅为了实现客户需求都会感到力不从心，更不用说发挥自己的艺术气质云云了。

从另一个角度来讲，做艺术的架构师们也都是行业里大师级别的人物了，这也是架构师们的终极目标吧！

 

梁远华：架构师需要广泛的知识面

         成为一个软件架构师往往需要具备十年以上的软件开发经验，入门的门槛是相当高的。而架构师的工作与实际项目经验密不可分，尤其是在互联网产品愈发重要的当下，一个软件架构师往往需要掌握多项技能。程序员如果想要修炼为一个架构师，究竟需要培养自己的哪些技能？近日，51CTO开发频道对广州铁克司雷网络科技有限公司（techsailor.cn）梁远华先生（Leung）进行了邮件专访。梁先生现在是网络社区平台聚聚呀（jujuya.com）项目的项目总监。

         架构师个人简历

聚聚呀项目总监梁远华先生

梁远华先生有十年的IT工作经验，在铁克司雷公司负责了整个聚聚呀项目的架构与实施。梁先生接触过各种各样的工作，做过的工种也是多种多样，服务过的公司也是类型多样，并且曾经和朋友一起两次创业。曾经从事计算机教学，网管，程序员，网站项目管理等工作，并曾在信息产业部第五电子科研所及地球村计算机科技公司积累了不少宝贵经验。

以下是此次访谈的具体内容。

51CTO编辑：软件架构师必须具备哪些技能或素质？哪项技能（素质）是您认为最重要的？

梁远华：就我的经验，下面三点是十分重要的。

１、整合分析能力

就拿聚聚呀来说吧，我们的宗旨是“让大家结识共同兴趣爱好人群的平台，可以方便让每个人创建和管理自己社区的平台”，这个是我们现在的核心，对于一个架构师应该有很强的分析能力，能够根据产品的宗旨，目标，分析产品的定位和产品业务，整合现有的技术领域用最佳的方式来实现产品的概念。

２、产品实现规划能力

对于任何一个互联网产品如何实现是架构师的重要责任之一，需要保证产品功能的现实，产品功能的可持续性，产品的稳定性及产品的可用性等。产品的这些需求都依懒于架构师对产品技术的规划。我们团队在产品的现实规划上有自己明确的目标和具体的可行性实施方案，以满足产品在升级，改版的需要。

３、横向沟通能力

一个产品它会分成多个部门的合作，各部门沟通的有效性直接会影响到产品的质量和产品的进度。聚聚呀产品现在有7个部门的同事协同工作，对于架构师的溝通要求是需要去同各个部门间进行沟通，交流，获得更多的产品信息，业务数据，运营指标，产品需求等各种信息的汇集才能作为产品架构决策的基础数据。 

51CTO编辑：要成为一个架构师，是否存在快速成长的捷径？普通程序员如何一步步向架构师的目标靠近?

梁远华：成为架构师严格上来说是没有什么捷径的，架构师从产品的生命周期上来看，他所涉及的层面很广，而且他所需要的知识面也会很广，需要过程更需要时间的学习和磨练。

我们的团队也会有一个培训机制，会挑选出一些比较有发展潜力的开发人员通过引导培训方式让他们走上架构之路。

我们的经验是从以下几个方面着手：

１、 扩大知识面：提升对互联网行业的认知度，对互联网产品的分析，并且通过小团队分享方式对互联网“热门现象”进行案例分析。

２、 专业度训练：提升横向和纵向的技能培训，特别是对专业态度的培训很重要，要求开发人员对自己的做的工作有强烈的责任心。

３、 分析思维训练：提升开发人员对产品功能需求的分析以及对产品业务需求的分析整合能力。

51CTO编辑：假设有三名优秀的程序员，A尤其擅长沟通与团队管理；B的编程功底深厚，且对新技术能快速掌握；C在逻辑思维和抽象能力方面表现优秀。您会重点培养哪位程序员成为架构师？

梁远华：我会选择C在逻辑思维和抽象能力方面表现优秀，架构师需要很强的抽象能力。

51CTO编辑：在一个软件项目中，通常有哪些问题是架构师最难把握的？

梁远华：我感觉有下面两点——

１、 对问题的定位，分析

２、 权衡取舍

以上二点在做聚聚呀产品过程中有深刻的体会，特别是第二点，一个产品会有很多的东西要做，什么是可做的，什么是重要的，什么是将来能做的，每天都做做选择题。