【51CTO獨家特稿】架構師是什么？什么樣的人可以成為架構師？架構師的成長過程中會遇到什么困難？這是51CTO開發頻道年終活動《架構師最怕程序員知道的十件事》的主旨。雖然并非每一個程序員都希望能成為一個架構師，但潛意識里他們是尊敬架構師的——而一個優秀的架構師往往在舉手投足中顯示出一個編程大師的風范。

51CTO開發頻道年終巨獻:架構師最怕程序員知道的十件事

為了深入的了解這些問題的答案，51CTO開發頻道展開了對國內外幾個著名架構師的一系列郵件訪談。本次訪談的對象是一位資深的程序員、咨詢師和架構師，Fred George先生。

架構師個人簡歷

[[7435]] 
Fred George

Fred George先生在敏捷開發領域頗有聲望，在業界有將近40年的開發經驗。早年他在IBM工作。退出IBM之后，以獨立咨詢師的身份在美國工作了十多年。后來他加盟了ThoughtWorks，成為早期致力于推動敏捷開發的一批開發者?，F在他離開了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.