标签：
看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的.
这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。
这句话按照Fred George先生 的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉 也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。
而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（Fred George）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。
我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员
不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师Randy Shoup先生 是如何总结架构师在项目中的职责的：
1. 产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。
2. 技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。
3. 与开发团队一起，完成设计与实施的细节
4. 与开发团队和运维团队一起，完成部署的过程
5. 与运维团队一起，进行部署之后的维护和故障排除
在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。
只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！
然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”
综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。
让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”
是的，每个好架构师都是一位出色的程序员。
本文为《架构师害怕程序员知道的十项技能》中的优秀程序员篇。
对高级架构师王翔先生的访谈 似乎能在一定程度上解答这个现象的由来。在访谈中，王翔先生说到自己在特定情况下会优先培养女性做为架构师，因为“架构师在创造性、知识汇总方面 根据个人经验似乎女性更适合。”
无论王翔先生的个人经历是否常态，既然说男人来自火星而女人来自金星，那么这至少表明是否适合架构师一职与人的思维模式有很大关系。在这一系列的访谈中，所有接受采访的架构师们都一致的表示逻辑思维和抽象思维能力是一个架构师最重要的素质。eBay的Randy Shoup先生 称拥有条理清晰的逻辑思维能力的人“就像稀有动物那样难找”。Fred George 则表示“驾驭概念的技能 ，在我看来是每一个人最高的潜力”，并表示自己不太介意这样一个苗子在其他方面的技能和经验的匮乏，因为在他看来除了思维之外的其他因素都是可以培养的。
逻辑思维，抽象思维，这些干巴巴的名词并不比高举某某旗帜、将某某贯彻到底的口号说明了更多问题。架构师们习惯了思考“虚”飘飘的概念，但如果不能让非IT人员明白这个或那个概念到底是在说什么，那么这个架构师也注定是失败的（详见架构师技能之沟通技术篇 ）。所以首先有必要解释一下这些架构师们说的这两个概念是什么意思。
程序员对逻辑思维是再熟悉不过了，因为程序员写的代码都是逻辑。如果怎样怎样就做什么什么，如果什么什么就触发这个或停止那个。编写条件这样的逻辑构成了代码中的绝大部分，因此缺乏逻辑思维能力基本等同于不可能成为程序员 。架构师必须要有很好的逻辑思维的理由，事实上和架构师必须先是个出色程序员的理由是一样的（详见架构师技能之优秀程序员篇 ）。
因此本文的关键在于抽象思维能力。这个能力常常被与物理成绩或数学能力等同起来，但它事实上并不是计算能力。比如说小学常见的数学题，两个城之间的铁路长度500公里，一辆火车平均时速100公里，问这辆火车从这个城到那个城需要多少时间。学生们往往会陷在于500公里、100公里/小时和5小时这些数字中，但是这道题的抽象因素其实是在“长度”、“时速”和“时间”这三个概念当中。
这其中其实又有两个概念，一个是将实在的事物概念化，一个是将模糊的感觉数量化 。看到一个苹果，能够将其抽象为质量、大小、颜色、形状、味道等概念的组合，就是概念化，而量化则是在概念化之上，将苹果用多少克、多少立方厘米来定义；至于颜色、形状、味道等概念，则是还没有完善量化标准的概念。如果在没有彻底理解概念的前提下过分拘泥于数字，那么到头来只是活跃了头脑的计算功能而无助于抽象思维的锻炼。
人们往往发现优秀的数学家、物理学家以及软件架构师有着很多相似的素质，甚至往往能够一人精通这好几个领域（比如UML之父James Rumbaugh ），其中很重要的原因就是这个抽象思维的能力。架构师在接到商业需求之后，最主要的工作就是将其转化为技术需求 。这个过程的完成与架构师抽象思维的能力密不可分。好比说这个项目是eBay那样的电子商务平台，那么eBay的主架构师第一个闪过的念头多半就是：这个系统，将会有“买、卖、搜索、付款等功能。”而负责每一个功能的架构师，又需要对这些部分进行进一步的抽象化。
很难想象一个缺乏抽象思维能力的人，要如何担负起架构师的工作。
而抽象思维和之前所讲的逻辑思维能力，并非是同一个东西，这也是为什么并非所有优秀的程序员都能够成为一个好的架构师。不过编辑在这里并不是想说难以成为架构师的程序员都是缺乏天赋，事实上抽象思维并非是一个不能培养的能力，只是它需要你主动地去思考 。正如支付宝的冯大辉 所说，程序员要想成为架构师，必须“有意识的开拓技术视野，深入理解公司业务”，这其实就是一个扩展视野的同时，培养抽象思维能力的过程。架构师在项目中处于位置较高的地方，工作的问题很难说找到谁来学习、借鉴一下，更多的是摸索、琢磨。如果你有这样的决心和毅力，那么相信抽象思维的能力也是不会难倒你的。
以上就是《架构师害怕程序员知道的十项技能》中的抽象思维篇。
有人谈到技术高手与架构师的区别就在于，架构师不光是着眼于现在，不仅仅局限于开发细节，比如如何调用，如何并发等等。而是跳出三界外，考虑一下面向未来问题和潜在风险的应对之道。
那程序员该如何培养自己的技术前瞻性呢？很大程度上来说还是要学好英语，国外的新东西，老东西的新特性肯定都是用英文写的。即使国内有很多网站也在做外电翻译，但面对海量的信息肯定是杯水车薪。而且有不少程序员所面对的领域本身关注度就不高，靠外部翻译似乎很难实时跟进。这时就需要有良好的外语水平，能看懂国外的技术文章和文档，能与国外相关人士进行交流。
外功是从外部获得最新技术信息，那么内功就是自己的逻辑思维能力和接受能力。再新的技术，其实也与以前的技术有结合。这也是为什么我们说架构师首先是卓越的程序员，也就是这个道理。
但是架构师并不是将前沿技术的名词天天挂在嘴上之人，整天只知道在程序员面前大谈“云计算，SaaS”这些东西的架构师注定成不了好的架构师。新的技术虽好，但是程序员接受和再培训还需要时间，还要考虑到系统的兼容性问题。因此，夸夸其谈的名词专家，并不是我们努力的方向。好的架构师，应该提前想到如何为程序员尽可能减轻负担，比如数据库软件新的特性可以提高性能，简化查询步骤，那架构师是不是第一时间要引导程序员去适应新的特性，提高开发效率。
被技术潮流抛弃的架构师是可悲的
技术前瞻性还体现在对新技术的选择上，哪些东西适合自己团队，哪些不适合肯定要自己心中有本帐。工具选好了再返工的人力成本和时间成本是很多公司没法负担的，利润就那么多，经不起瞎折腾。程序员在自己的学习过程中，也可以适当培训一下自己，比如新的IDE中有新的功能，但是要安装这新版本的IDE需要更新系统，更新硬件，还要更新和数据库的接口。这一套下来花费的时间成本是多少，换算成工资是多少？我想事事都这样过一遍，我们在做选择的时候就不会盲目。
架构师在自己所处的领域肯定了解颇深，未来本领域技术该如何发展，应该有自己的理解。也会对未来技术的发展有所期盼，有自己的见解。当然这属于比较发散的想法，个人有个人的目标。
51CTO总结： 技术人生如逆水行舟，不进则退。
本文为《架构师害怕程序员知道的十项技能》中的技术前瞻能力篇。
可能他一开始会满腔抱负、意气风发的按照自己的方式完成小头目交给自己的一些练手任务，然后懊恼的发现小头目对这些看似能够完成任务的代码大摇其头，指指点点；然后在真正进入项目之后，又会被各种不知道从哪里冒出来的bug和漏洞搞得晕头转向……
这些问题一方面和这位菜鸟程序员缺乏经验有关，但是在过来者看来，造成这些问题的一个主要原因正是在于，这位程序员没能看到问题的本质。
而看到问题的本质，也是架构师所必须具备的素质。
所谓看到问题的本质，实际上是一个思考的层面问题。比如说，你现在看到的这篇文章，从表面上看，就是你的显示屏显示出来了一些文字，但这明显不是它的本质。从内容而言，这篇文章是一篇有关架构师技能的文章，它是对一个职业的某一项能力的描述；从技术而言，这篇文章是在世界上某台服务器上的数据库中提取出来的某些信息，经过漫长光缆和层层协议的传递，经过你的网线插口（或无线接收器）进入了你的机器，通过浏览器解读并最终呈现出来。
听起来，这个和另一篇文章介绍的同样是架构师所需要的“抽象思维 ”有点像，只是方向不同：抽象思维是往高层次的升华，透过问题看本质则是往深层次的挖掘 。
让我们看看文章一开始的那位菜鸟程序员为什么总是失败。如果你是一位PHP程序员，那么可以参考这篇文章 ，里面总结了一些常见的问题。最简单的一个（有时被用作面试题）可能出现在这样的情况下——小头目说：“显示用户提交的ID名”，然后菜鸟程序员大笔一挥：
- 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开发频道邀请到了一位有些特别的嘉宾。他的大学专业是生物，毕业后开始从事IT。技术起点是Oracle数据库，数年的工作经验也主要围绕Oracle数据库的管理与性能优化。而他同时又是个技术杂家，对Oracle/MySQL关系型数据库、Unix / Linux、网站架构 / 安全、用户体验、电子支付都有所涉及。活跃于各个技术社区，是国内IT业界最受欢迎的技术博主之一。自认为是个Evangelist（编者注：这个称号由于其文化背景和意境，在国外的很多IT从业者都很愿意使用这个称号。直译过来应为“技术布道者”）。
他就是支付宝的数据架构师冯大辉先生。
冯大辉的Twitter头像 @Fenng
数据架构师（DB Architect）主要是从数据库管理员（DBA）成长而来的，正如软件架构师原本都是程序员一样。数据库管理员的工作是数据库具体的维护工作，而架构师的工作则在一个更高的抽象层面上。因此大辉也曾说到，自己是从做一些比较“实”的维护工作的DBA转变到一个相对比较“虚”的DBA岗位上。当然这样的转变并不轻松，架构师必须要有看得更远、更全面的能力，成长的过程需要学习很多知识并积累经验。对于自己的学习经历，大辉在此次访谈中是这样总结的：
“学习主要是通过网络进行，比如仔细研读和架构有关的经典论文，订阅一些技术架构师的BLOG。当然，不可或缺的是线下、线上的积极交流，我自己也会写一些文章和大家分享，从分享中我也能再次学到很多。”
听起来是一些挺平常的事情，但是如果你去大辉的博客（dbanotes.net ），观看他几年间撰写的博文，看到他那个长长的网志关注列表，你会发现这是个绝佳的建议。互联网发展到今天的程度，像网志、社区这样的平台已经成为技术人自我提高的一个绝好的工具——而且几乎没有门槛。无论你是一个程序员还是DBA，维护一个技术博客，与其他博主互相交流，绝对会令你受益良多——无论你是否希望成为一个架构师。
不过另一方面，视野和经验的积累如果没有实际的业务是很难获得的。因此，如果你在一个公司平台环境之上，那么也要争取“有意识的开拓技术视野，深入理解公司业务”，因为这些也是不可或缺的。大辉介绍说，数据架构师这个岗位很少有公司设置，很多时候没有可供参考的案例，更多是摸索、琢磨。
一个架构师有哪些必备的素质？在之前的访谈中，几位架构师谈到了在培养一位软件架构师时最看重其抽象思维的能力，因为这是架构师的工作中最需要的能力，往往也是很多程序员所不具备的。正如Randy Shoup所介绍的那样，像eBay这样的大型系统，从项目启动到最后的维护都有工作要做，但是第一步就是需要将整体需求抽象为垂直的买、卖、搜索、付款，还有水平的数据库、事件与消息系统、服务基础设施、展示框架等功能。而想法在落实的过程，也是对架构师抽象思维和逻辑思维能力的最大挑战。大辉分享自己数据架构师经历的挫折经验，大多都是在想法的落实过程中。他说，一个比较新而且“虚”的岗位，一般"落地"会遇到一些问题，需要自己去摸索。这是个很难做到的事情。
同时，大辉也谈了谈自己对架构师这个群体的整体感受。他觉得他认识的架构师有一个共同点，那就是都“具备出色的交流能力，能够推动大家就某些方向达成一致”。
为了深入的了解这些问题的答案，51CTO开发频道展开了对国内外几个著名架构师的一系列邮件访谈。本次访谈的对象是eBay的杰出架构师Randy Shoup先生。
架构师个人简历
eBay杰出架构师Randy Shoup
Randy Shoup是eBay市场架构团队的杰出架构师(Distinguished Architect)。他从2004年开始成为eBay搜索基础设施的主要架构师。在eBay之前，他是Tumbleweed Communications的首席架构师，并在甲骨文以及Informatica公司担任数职。他是斯坦福大学的数学与计算机系以及政治科学系的本科毕业生。
以下是此次访谈的具体内容。
Randy Shoup：在eBay，一个架构师的任务就是设计一系列的技术方案，这些方案必须满足商业上的要求，同时还要能够维持高标准的功能，性能，可伸缩性，可管理性，安全性，以及可用性。一个架构师与开发团队、产品团队和运维团队通过紧密的合作来实现上述的这些目标。
在产品团队开始酝酿一个新的主意的时候，架构师是产品团队第一个接触的人：架构师会帮助他们把可行性、技术需求以及权衡取舍等因素一一剖析清楚。一个架构师之后的工作可总结为以下几条：
◆设计整体的技术实现步骤
◆与开发团队一起，完成设计与实施的细节
◆与开发团队和运维团队一起，完成部署的过程
◆与运维团队一起，进行部署之后的维护和故障排除
一个架构师设立好技术风向标，并确保整个项目的进展按照这些方向进行。一个架构师不爱下达命令，他往往通过影响力来领导团队。一个架构师考虑“大的”和“长期的”，并在各个因素之间做出权衡。
由于eBay是一个大站，每一个架构师都要为这个站的不同方面负责。有些对垂直功能负责，如买、卖、搜索、付款等功能。有些对水平功能负责，如数据库、事件与消息系统、服务基础设施、展示框架等功能。
我们在招聘架构师时有如下要求：
◆在设计与开发大型系统方面有10年以上做为开发者和技术管理者的经验
◆技术领导能力
◆出色的交流和处理人际关系的技能，尤其是向开发者和非开发者解释高级技术话题的能力
◆出色的分析和解决问题的能力
◆对我们的技术堆栈有相当程度的经验
◆对于商业需求和客户需求有着很强的理解能力，尤其是对权衡取舍方面有着出色的把控能力
Randy Shoup：一个优秀的架构师需要同时兼有A，B和C的能力。我们希望我们招聘的架构师拥有以上所有这些能力，这也是为什么并非每一个顶级开发者都能够成为一个优秀架构师的原因:-)
如果一定要排序，那么我会按照C、B、A的顺序。条理清晰的逻辑思维能力可能是一个架构师最重要的技能了，而我们往往发现拥有这种技能的人就像稀有动物那样难找。不过，这个能力仅仅在和大量的实际开发经验、丰富的理论背景和好的领导能力相结合的时候才能体现出它的价值。
Randy Shoup：做为一个从菜鸟成长起来的架构师，我还真记得几次挑战：
◆习惯了思考细小的方面：有时候，一个新手架构师很容易在具体的代码编写和实施上花费太多的精力。一个架构师最基本的职能是往广处思考，把系统看做一个完整的个体来思考，以维护并增强可伸缩性和可用性这些系统级的特性为目标。一个架构师不能将实施细节抛之脑后，但她最大的价值在更高的层次。
◆习惯了单独工作：有时候，一个新手架构师会觉得她的工作就是独自开发出一个项目的架构和设计，并将这一整个成品交给一个团队来完成实施的部分。不过据我所知，大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作。这不仅对架构本身有利，而且会令实施过程进展的更加平滑。
架构师个人简历
王翔
软件架构师，主要从事Java EE/.NET企业应用、XML、公钥基础设施的开发。专注于数据（尤其是 XML）的生产、加工、交换、提炼等过程。此外，参与了一系列有关应用密码技术和 PKI环境保护信息系统数据安全的项目。
最喜欢数学,项目间隙经常到各海滨城市徒步旅行、野外露营、出海航行、极限运动。
所著图书
《设计模式——基于C#的工程化实现及扩展》
《Google API大全——编程?开发?实例》（合著）
我们的问题主要为以下三个：
1)首先是经验和技术基础，以其昏昏做不到以人昭昭。
2)创造性和知识汇总能力，两者互承
3)领导力和信心，架构师做事情要有格局
4)基于2、3语言(含母语)的沟通学习能力，不管做的是什么项目，要有国际化视野
5)市场嗅觉
6)最后，好的A还有有些艺术气质(毕竟软件是给人用的，艺术正好是提供良好体验的桥梁)和冒险精神（架构师要有烹小鲜的危机感，但要做业内创新更要有冒险精神)
仅从技能角度我一般总结为9个方面：
1、架构理论和方法学
2、对象理论
3、JEE/.NET/动态，技术领域技术能力。而且作为A最好保证钻自己平台基础上，对其他平台有个客观、与时俱进的了解。
4、模式
5、遗留系统互联
6、中间件
7、消息机制和协议
8、本地化和国际化
9、安全性和性能
存在捷径，主要是机遇问题。
对国内而言，如果一个人一直从事M(RMB)级以下项目，那么做10年或者做100个项目还是不能很快成长，如果他从事100M(RMB)、 B(RMB)、10B(RMB)项目，并且在其中负责全局性的技术工作，那么一两个项目就可以快速成长，可能4、5年就能成为不错的架构设计人员(不过还要看她/他交付成果的质量)。
普通程序员成为A最重要的是他自己有信念和行动，其他的都是其次的。
哪怕是Assistant Programmer，只要有信念和行动，应该可以承担各种压力和困难，逐步走上Programmer、S. Programmer、Developer、S. Developer、Designer、S. Desinger、A、S. A、D. A、C. A。
C(后面依次递减是B、A。A更适合做项目经理、产品经理)
而且根据个人的经验，虽然女性程序员开发阶段显得不如男性那么快深入和入手(Programmer)，但能坚持到Developer、S. Developer、 Designer、S. Desinger阶段她们的思维能力优势就显示出来。如果B是女性Desinger级别的人员，我宁愿选择培养她，因为架构师在创造性、知识汇总方面根据个人经验似乎女性更适合。
架构师个人简历
聚聚呀项目总监梁远华先生
梁远华先生有十年的IT工作经验，在铁克司雷公司负责了整个聚聚呀项目的架构与实施。梁先生接触过各种各样的工作，做过的工种也是多种多样，服务过的公司也是类型多样，并且曾经和朋友一起两次创业。曾经从事计算机教学，网管，程序员，网站项目管理等工作，并曾在信息产业部第五电子科研所及地球村计算机科技公司积累了不少宝贵经验。
以下是此次访谈的具体内容。
梁远华：就我的经验，下面三点是十分重要的。
１、整合分析能力
就拿聚聚呀来说吧，我们的宗旨是“让大家结识共同兴趣爱好人群的平台，可以方便让每个人创建和管理自己社区的平台”，这个是我们现在的核心，对于一个架构师应该有很强的分析能力，能够根据产品的宗旨，目标，分析产品的定位和产品业务，整合现有的技术领域用最佳的方式来实现产品的概念。
２、产品实现规划能力
对于任何一个互联网产品如何实现是架构师的重要责任之一，需要保证产品功能的现实，产品功能的可持续性，产品的稳定性及产品的可用性等。产品的这些需求都依懒于架构师对产品技术的规划。我们团队在产品的现实规划上有自己明确的目标和具体的可行性实施方案，以满足产品在升级，改版的需要。
３、横向沟通能力
一个产品它会分成多个部门的合作，各部门沟通的有效性直接会影响到产品的质量和产品的进度。聚聚呀产品现在有7个部门的同事协同工作，对于架构师的溝通要求是需要去同各个部门间进行沟通，交流，获得更多的产品信息，业务数据，运营指标，产品需求等各种信息的汇集才能作为产品架构决策的基础数据。
梁远华：成为架构师严格上来说是没有什么捷径的，架构师从产品的生命周期上来看，他所涉及的层面很广，而且他所需要的知识面也会很广，需要过程更需要时间的学习和磨练。
我们的团队也会有一个培训机制，会挑选出一些比较有发展潜力的开发人员通过引导培训方式让他们走上架构之路。
我们的经验是从以下几个方面着手：
１、 扩大知识面：提升对互联网行业的认知度，对互联网产品的分析，并且通过小团队分享方式对互联网“热门现象”进行案例分析。
２、 专业度训练：提升横向和纵向的技能培训，特别是对专业态度的培训很重要，要求开发人员对自己的做的工作有强烈的责任心。
３、 分析思维训练：提升开发人员对产品功能需求的分析以及对产品业务需求的分析整合能力。
梁远华：我会选择C在逻辑思维和抽象能力方面表现优秀，架构师需要很强的抽象能力。
梁远华：我感觉有下面两点——
１、 对问题的定位，分析
２、 权衡取舍
以上二点在做聚聚呀产品过程中有深刻的体会，特别是第二点，一个产品会有很多的东西要做，什么是可做的，什么是重要的，什么是将来能做的，每天都做做选择题。
在过去的一周间，51CTO开发频道陆续对国内外数位软件架构师进行了邮件访谈，询问他们一个程序员要成长为一个架构师需要学习哪些知识和技能，在工作上需要注意哪些问题。其中，王翔先生提到坚持不懈是架构师人生第一课，Fred George先生描述了架构师应该是有艺术追求的使用代码作画的大师，而eBay的Randy Shoup先生则主要强调了架构师在项目需求、系统和团队之间进行权衡取舍的重要能力。
这一次，51CTO开发频道邀请到了一位有些特别的嘉宾。他的大学专业是生物，毕业后开始从事IT。技术起点是Oracle数据库，数年的工作经验也主要围绕Oracle数据库的管理与性能优化。而他同时又是个技术杂家，对Oracle/MySQL关系型数据库、Unix / Linux、网站架构 / 安全、用户体验、电子支付都有所涉及。活跃于各个技术社区，是国内IT业界最受欢迎的技术博主之一。自认为是个Evangelist（编者注：这个称号由于其文化背景和意境，在国外的很多IT从业者都很愿意使用这个称号。直译过来应为“技术布道者”）。
他就是支付宝的数据架构师冯大辉先生。
冯大辉的Twitter头像 @Fenng
学习篇
数据架构师（DB Architect）主要是从数据库管理员（DBA）成长而来的，正如软件架构师原本都是程序员一样。数据库管理员的工作是数据库具体的维护工作，而架构师的工作则在一个更高的抽象层面上。因此大辉也曾说到，自己是从做一些比较“实”的维护工作的DBA转变到一个相对比较“虚”的DBA岗位上。当然这样的转变并不轻松，架构师必须要有看得更远、更全面的能力，成长的过程需要学习很多知识并积累经验。对于自己的学习经历，大辉在此次访谈中是这样总结的：
“学习主要是通过网络进行，比如仔细研读和架构有关的经典论文，订阅一些技术架构师的BLOG。当然，不可或缺的是线下、线上的积极交流，我自己也会写一些文章和大家分享，从分享中我也能再次学到很多。”
听起来是一些挺平常的事情，但是如果你去大辉的博客（dbanotes.net），观看他几年间撰写的博文，看到他那个长长的网志关注列表，你会发现这是个绝佳的建议。互联网发展到今天的程度，像网志、社区这样的平台已经成为技术人自我提高的一个绝好的工具——而且几乎没有门槛。无论你是一个程序员还是DBA，维护一个技术博客，与其他博主互相交流，绝对会令你受益良多——无论你是否希望成为一个架构师。
不过另一方面，视野和经验的积累如果没有实际的业务是很难获得的。因此，如果你在一个公司平台环境之上，那么也要争取“有意识的开拓技术视野，深入理解公司业务”，因为这些也是不可或缺的。大辉介绍说，数据架构师这个岗位很少有公司设置，很多时候没有可供参考的案例，更多是摸索、琢磨。
能力篇
一个架构师有哪些必备的素质？在之前的访谈中，几位架构师谈到了在培养一位软件架构师时最看重其抽象思维的能力，因为这是架构师的工作中最需要的能力，往往也是很多程序员所不具备的。正如Randy Shoup所介绍的那样，像eBay这样的大型系统，从项目启动到最后的维护都有工作要做，但是第一步就是需要将整体需求抽象为垂直的买、卖、搜索、付款，还有水平的数据库、事件与消息系统、服务基础设施、展示框架等功能。而想法在落实的过程，也是对架构师抽象思维和逻辑思维能力的最大挑战。大辉分享自己数据架构师经历的挫折经验，大多都是在想法的落实过程中。他说，一个比较新而且“虚”的岗位，一般"落地"会遇到一些问题，需要自己去摸索。这是个很难做到的事情。
同时，大辉也谈了谈自己对架构师这个群体的整体感受。他觉得他认识的架构师有一个共同点，那就是都“具备出色的交流能力，能够推动大家就某些方向达成一致”。
标签：
原文地址：http://blog.csdn.net/qq1175421841/article/details/51813229
