搜索
软件工程师成长为架构师必备的十项技能一、卓越的程序员1.每个好架构师都是一位出色的程序员架构师，听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中，架构师都是高手，都是牛人，都是如此高高在上的存在。不过，在搞了四、五年编程之后，程序员们往往早已失去了当年对这些“高级”职位的神秘感，甚至会对自己所在项目的架构师抱怨不已，背后里称他们是一群水王。所以有江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。这句话按照FredGeorge先生的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（FredGeorge）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师RandyShoup先生是如何总结架构师在项目中的职责的：1.产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。2.技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。3.与开发团队一起，完成设计与实施的细节4.与开发团队和运维团队一起，完成部署的过程5.与运维团队一起，进行部署之后的维护和故障排除在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”是的，每个好架构师都是一位出色的程序员。2、FredGeorge：架构师是使用代码作画的大师为了深入的了解这些问题的答案，51CTO开发频道展开了对国内外几个著名架构师的一系列邮件访谈。本次访谈的对象是一位资深的程序员、咨询师和架构师，FredGeorge先生。FredGeorge先生在敏捷开发领域颇有声望，在业界有将近40年的开发经验。早年他在IBM工作。退出IBM之后，以独立咨询师的身份在美国工作了十多年。后来他加盟了ThoughtWorks，成为早期致力于推动敏捷开发的一批开发者。现在他离开了ThoughtWorks，在英国的TrafficBroker公司就任解决方案架构师一职。51CTO编辑曾在2009年敏捷中国大会上与Fred先生进行过一次面对面的交流，编者对Fred先生充满生趣的演讲和对编程如同小孩子一般的热情印象颇深。以下是此次访谈的具体内容。编辑：不同的企业和项目经理对架构师往往定义不完全相同。在您的团队中，对架构师是如何定义的？对于招聘的架构师会有怎样的技能要求？Fred：首先澄清一下，我的这个头衔：“解决方案架构师(SolutionsArchitect)”，其实只是为了签证弄的一个头衔。我其实是没有头衔的。不过呢，我确实自诩为一个架构师。基本上，架构师是使用代码作画的大师。最近在那些顶级的软件思想者中刮起了一股讨论系统之“优美”以及“简约”之风。一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。在我看来，系统是一个个有机的生命。跟企业一样，系统也需要施肥浇水，需要健康的成长。与企业一样，一个系统可能会在短期内被滥用（比如在需要短期内快速盈利的驱使下），不过如果滥用的时间过长，系统最终将会无法支持。与CEO一样，一个架构师对系统的这个特性了如指掌。他们能够识别什么是滥用，系统能够承受的限度，并将系统引回到健康的道路上。编辑：假设有三名优秀的程序员，A尤其擅长沟通与团队管理；B的编程功底深厚，且对新技术能快速掌握；C在逻辑思维和抽象能力方面表现优秀。您会重点培养哪位程序员成为架构师？Fred：不是每个人都能够具有一个架构师的能力。在你提供的选项中，C的成功几率是最高的。驾驭概念的技能，在我看来是每一个人最高的潜力。对于其他的需求，如语言、经验等，我可以通过培训来建立。B有可能会成为一个好架构师：她显示出了概念理解能力的一些苗头。如果她开始领悟一个好系统的模式(pattern)是怎么一回事，那么她便能够完成转型。对于A我不作考虑。把他放在架构师的位子上，就相当于把“架构师”当做“设计师”的升级版。这就好像把你的祖父扔到F1赛车场上，仅仅因为他开车的时间最长。这个绝对不对头。领导能力是重要的，但并不是一个好架构师的组成因素。编辑：对于一个刚刚从程序员转型过来的架构师，通常有哪些问题是他最难把握的？Fred：如果你从程序员的职位转型，决定自己不再是程序员了，那么你的架构师生涯将是短暂的。最好的架构师都在写代码。KentBeck曾经写道：“代码就是设计与残酷现实之黄昏的交汇(Codeiswhendesignmeetstheharshrealityofdawn.)”。他的意思是，我们画出来的设计都是美好的，但最好的设计仅仅是被翻译为优雅代码的那些。一个无法将愿景带入代码的架构师将永远无法了解我们这个急速变化的行业所展示的深度。所以说，不编程的架构师的职业生涯是短暂的。做为一个架构师，我需要实现（这个过程是结对编程，我会有一个搭档）一个系统最难实现的一部分。我将其称之为“先锋”，因为这是我检验我脑中的主意是否真的是一个好主意的过程。我在第一次实施中会细化这个主意。然后我才会放心的让编程团队的其他成员按照这个模式来走。这就是“架构”。有点跑题了。对于一个菜鸟架构师而言，最大的障碍就在于承认你并不知道详细的答案，但你信心满满的认为可以和程序员和设计师一起找到这个答案。另一个新手架构师经常遇到的问题是“优美”以及“简约”。每次当进行决策的过程中出现这些概念的时候，项目经理往往对这样的理由不置可否。项目经理通常有短期目标要实现，而对优美还是简约这样的概念并不感冒。但事实上，他们这是对系统未来健康状况的不重视。最后，菜鸟架构师往往是出色的程序员。而他会发现团队中的其他程序员贡献的代码看起来不太美。菜鸟架构师必须要学会界定哪些丑陋的代码是可以接受的，哪些是不能接受的。架构师是艺术家，他们的成就往往不会在他们活着的时候被赞赏。二、抽象思维驾驭概念的技能是最高潜力在近日开发频道对数位架构师进行采访的时候，编辑观察到一个很有意思的现象，那就是他们在提起一个假想架构师的时候会下意识的使用“she”或者“她”来指代。然而我们这次采访到的的架构师们却全都是男士，这似乎是一个比较难以理解的现象。对高级架构师王翔先生的访谈似乎能在一定程度上解答这个现象的由来。在访谈中，王翔先生说到自己在特定情况下会优先培养女性做为架构师，因为“架构师在创造性、知识汇总方面根据个人经验似乎女性更适合。”无论王翔先生的个人经历是否常态，既然说男人来自火星而女人来自金星，那么这至少表明是否适合架构师一职与人的思维模式有很大关系。在这一系列的访谈中，所有接受采访的架构师们都一致的表示逻辑思维和抽象思维能力是一个架构师最重要的素质。eBay的RandyShoup先生称拥有条理清晰的逻辑思维能力的人“就像稀有动物那样难找”。FredGeorge则表示“驾驭概念的技能，在我看来是每一个人最高的潜力”，并表示自己不太介意这样一个苗子在其他方面的技能和经验的匮乏，因为在他看来除了思维之外的其他因素都是可以培养的。逻辑思维，抽象思维，这些干巴巴的名词并不比高举某某旗帜、将某某贯彻到底的口号说明了更多问题。架构师们习惯了思考“虚”飘飘的概念，但如果不能让非IT人员明白这个或那个概念到底是在说什么，那么这个架构师也注定是失败的（详见架构师技能之沟通技术篇）。所以首先有必要解释一下这些架构师们说的这两个概念是什么意思。程序员对逻辑思维是再熟悉不过了，因为程序员写的代码都是逻辑。如果怎样怎样就做什么什么，如果什么什么就触发这个或停止那个。编写条件这样的逻辑构成了代码中的绝大部分，因此缺乏逻辑思维能力基本等同于不可能成为程序员。架构师必须要有很好的逻辑思维的理由，事实上和架构师必须先是个出色程序员的理由是一样的（详见架构师技能之优秀程序员篇）。因此本文的关键在于抽象思维能力。这个能力常常被与物理成绩或数学能力等同起来，但它事实上并不是计算能力。比如说小学常见的数学题，两个城之间的铁路长度500公里，一辆火车平均时速100公里，问这辆火车从这个城到那个城需要多少时间。学生们往往会陷在于500公里、100公里/小时和5小时这些数字中，但是这道题的抽象因素其实是在“长度”、“时速”和“时间”这三个概念当中。这其中其实又有两个概念，一个是将实在的事物概念化，一个是将模糊的感觉数量化。看到一个苹果，能够将其抽象为质量、大小、颜色、形状、味道等概念的组合，就是概念化，而量化则是在概念化之上，将苹果用多少克、多少立方厘米来定义；至于颜色、形状、味道等概念，则是还没有完善量化标准的概念。如果在没有彻底理解概念的前提下过分拘泥于数字，那么到头来只是活跃了头脑的计算功能而无助于抽象思维的锻炼。人们往往发现优秀的数学家、物理学家以及软件架构师有着很多相似的素质，甚至往往能够一人精通这好几个领域（比如UML之父JamesRumbaugh），其中很重要的原因就是这个抽象思维的能力。架构师在接到商业需求之后，最主要的工作就是将其转化为技术需求。这个过程的完成与架构师抽象思维的能力密不可分。好比说这个项目是eBay那样的电子商务平台，那么eBay的主架构师第一个闪过的念头多半就是：这个系统，将会有“买、卖、搜索、付款等功能。”而负责每一个功能的架构师，又需要对这些部分进行进一步的抽象化。很难想象一个缺乏抽象思维能力的人，要如何担负起架构师的工作。而抽象思维和之前所讲的逻辑思维能力，并非是同一个东西，这也是为什么并非所有优秀的程序员都能够成为一个好的架构师。不过编辑在这里并不是想说难以成为架