程序员成长为架构师必备的五项技能,c# Java!!!!!!!

一、卓越的程序员

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、Fred George：架构师是使用代码作画的大师

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、抽象思维 驾驭概念的技能是最高潜力

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

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

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

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

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

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

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

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

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

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

三、技术前瞻性 架构师：站在技术的山顶向前眺望

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

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

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

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

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

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

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

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

四、问题解决大师 架构师修炼课程：透过问题看本质

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

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

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

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

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

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

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

echo $_GET['username'];  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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