【51CTO独家特稿】架构师是什么？什么样的人可以成为架构师？架构师的成长过程中会遇到什么困难？这是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编辑：对于一个刚刚从程序员转型过来的架构师，通常有哪些问题是他最难把握的？
#T#Fred：如果你从程序员的职位转型，决定自己不再是程序员了，那么你的架构师生涯将是短暂的。最好的架构师都在写代码。Kent Beck曾经写道：“代码就是设计与残酷现实之黄昏的交汇(Code is when design meets the harsh reality of dawn.)”。他的意思是，我们画出来的设计都是美好的，但最好的设计仅仅是被翻译为优雅代码的那些。一个无法将愿景带入代码的架构师将永远无法了解我们这个急速变化的行业所展示的深度。
所以说，不编程的架构师的职业生涯是短暂的。
做为一个架构师，我需要实现（这个过程是结对编程，我会有一个搭档）一个系统最难实现的一部分。我将其称之为“先锋”，因为这是我检验我脑中的主意是否真的是一个好主意的过程。我在第一次实施中会细化这个主意。然后我才会放心的让编程团队的其他成员按照这个模式来走。这就是“架构”。
有点跑题了。对于一个菜鸟架构师而言，最大的障碍就在于承认你并不知道详细的答案，但你信心满满的认为可以和程序员和设计师一起找到这个答案。
另一个新手架构师经常遇到的问题是“优美”以及“简约”。每次当进行决策的过程中出现这些概念的时候，项目经理往往对这样的理由不置可否。项目经理通常有短期目标要实现，而对优美还是简约这样的概念并不感冒。但事实上，他们这是对系统未来健康状况的不重视。
最后，菜鸟架构师往往是出色的程序员。而他会发现团队中的其他程序员贡献的代码看起来不太美。菜鸟架构师必须要学会界定哪些丑陋的代码是可以接受的，哪些是不能接受的。
架构师是艺术家，他们的成就往往不会在他们活着的时候被赞赏。
#p#
附录：问题与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.
