架构师害怕程序员知道的十项技能.doc

卓越的程序员每个好架构师都是一位出色的程序员架构师，听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中，架构师都是高手，都是牛人，都是如此高高在上的存在。不过，在搞了四、五年编程之后，程序员们往往早已失去了当年对这些“高级”职位的神秘感，甚至会对自己所在项目的架构师抱怨不已，背后里称他们是一群水王。所以有江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。这句话按照Fred George先生的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（Fred George）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师Randy Shoup先生是如何总结架构师在项目中的职责的：1. 产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。2. 技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。3. 与开发团队一起，完成设计与实施的细节4. 与开发团队和运维团队一起，完成部署的过程5. 与运维团队一起，进行部署之后的维护和故障排除在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。 只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”是的，每个好架构师都是一位出色的程序员。独家专访Fred George：架构师是使用代码作画的大师架构师是什么？什么样的人可以成为架构师？架构师的成长过程中会遇到什么困难？这是51CTO开发频道年终活动架构师最怕程序员知道的十件事的主旨。虽然并非每一个程序员都希望能成为一个架构师，但潜意识里他们是尊敬架构师的而一个优秀的架构师往往在举手投足中显示出一个编程大师的风范。为了深入的了解这些问题的答案，51CTO开发频道展开了对国内外几个著名架构师的一系列邮件访谈。本次访谈的对象是一位资深的程序员、咨询师和架构师，Fred George先生。架构师个人简历Fred GeorgeFred 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 ArchitectUsually, different project managers in different teams have somewhat different definitions for the term Architect. In Amazon team, what does an architect do, and whats 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 architectSuppose 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 youd 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 doesnt work. Leadership skills are important, but it is not a factor in being a good architect.-3. From an experienced architects point of view, what do you think are the main obstacles faced by those novice architects who just transformed from a programmers 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 doesnt 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 dont 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 dont value keeping the system healthy for tomorrows 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$_GETusername;小头目阅毕自然抓狂不已，因为这是一个再明显不过的安全隐患。菜鸟程序员被小头目训了一顿，然后知道这样做是有问题的。这个事情如何与通过问题看本质有关？这个就取决于这位菜鸟程序员是如何改正这个错误的。如果这位程序员只是把下面的那段“合格”代码抄袭过来并死记硬背，那么，以后等待这位程序员的大概是比较悲惨的结局因为漫长的代码生涯中有极多类似的问题，而等到他进入真正的项目之后，犯错误是有成本的。他的学习方式表示他没有主动避免这样类似问题的能力，那么他可能将会造成极大的损失，从而最终失去在这个行业的竞争力。但是，如果他了解到代码之下，更深层次的那些机制，比如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 的第一个公开测试版)；上海团