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

51CTO開發(fā)頻道年終巨獻(xiàn):架構(gòu)師最怕程序員知道的十件事

為了深入的了解這些問題的答案，51CTO開發(fā)頻道展開了對國內(nèi)外幾個(gè)著名架構(gòu)師的一系列郵件訪談。本次訪談的對象是一位資深的程序員、咨詢師和架構(gòu)師，F(xiàn)red George先生。

架構(gòu)師個(gè)人簡歷

[[7435]] 
Fred George

Fred George先生在敏捷開發(fā)領(lǐng)域頗有聲望，在業(yè)界有將近40年的開發(fā)經(jīng)驗(yàn)。早年他在IBM工作。退出IBM之后，以獨(dú)立咨詢師的身份在美國工作了十多年。后來他加盟了ThoughtWorks，成為早期致力于推動(dòng)敏捷開發(fā)的一批開發(fā)者?，F(xiàn)在他離開了ThoughtWorks，在英國的TrafficBroker公司就任解決方案架構(gòu)師一職。51CTO編輯曾在2009年敏捷中國大會上與Fred先生進(jìn)行過一次面對面的交流，編者對Fred先生充滿生趣的演講和對編程如同小孩子一般的熱情印象頗深。

以下是此次訪談的具體內(nèi)容。

51CTO編輯：不同的企業(yè)和項(xiàng)目經(jīng)理對架構(gòu)師往往定義不完全相同。在您的團(tuán)隊(duì)中，對架構(gòu)師是如何定義的？對于招聘的架構(gòu)師會有怎樣的技能要求？

Fred：首先澄清一下，我的這個(gè)頭銜：“解決方案架構(gòu)師(Solutions Architect)”，其實(shí)只是為了簽證弄的一個(gè)頭銜。我其實(shí)是沒有頭銜的。不過呢，我確實(shí)自詡為一個(gè)架構(gòu)師。

基本上，架構(gòu)師是使用代碼作畫的大師。最近在那些頂級的軟件思想者中刮起了一股討論系統(tǒng)之“優(yōu)美”以及“簡約”之風(fēng)。一個(gè)架構(gòu)師的價(jià)值在于，他不僅能看到系統(tǒng)的美，而且能夠在建造系統(tǒng)的時(shí)候能夠把這些美創(chuàng)造出來。

在我看來，系統(tǒng)是一個(gè)個(gè)有機(jī)的生命。跟企業(yè)一樣，系統(tǒng)也需要施肥澆水，需要健康的成長。與企業(yè)一樣，一個(gè)系統(tǒng)可能會在短期內(nèi)被濫用（比如在需要短期內(nèi)快速盈利的驅(qū)使下），不過如果濫用的時(shí)間過長，系統(tǒng)最終將會無法支持。與CEO一樣，一個(gè)架構(gòu)師對系統(tǒng)的這個(gè)特性了如指掌。他們能夠識別什么是濫用，系統(tǒng)能夠承受的限度，并將系統(tǒng)引回到健康的道路上。

51CTO編輯：假設(shè)有三名優(yōu)秀的程序員，A尤其擅長溝通與團(tuán)隊(duì)管理；B的編程功底深厚，且對新技術(shù)能快速掌握；C在邏輯思維和抽象能力方面表現(xiàn)優(yōu)秀。您會重點(diǎn)培養(yǎng)哪位程序員成為架構(gòu)師？

Fred：不是每個(gè)人都能夠具有一個(gè)架構(gòu)師的能力。在你提供的選項(xiàng)中，C的成功幾率是最高的。駕馭概念的技能，在我看來是每一個(gè)人最高的潛力。對于其他的需求，如語言、經(jīng)驗(yàn)等，我可以通過培訓(xùn)來建立。

B有可能會成為一個(gè)好架構(gòu)師：她顯示出了概念理解能力的一些苗頭。如果她開始領(lǐng)悟一個(gè)好系統(tǒng)的模式(pattern)是怎么一回事，那么她便能夠完成轉(zhuǎn)型。

對于A我不作考慮。把他放在架構(gòu)師的位子上，就相當(dāng)于把“架構(gòu)師”當(dāng)做“設(shè)計(jì)師”的升級版。這就好像把你的祖父扔到F1賽車場上，僅僅因?yàn)樗_車的時(shí)間最長。這個(gè)絕對不對頭。

領(lǐng)導(dǎo)能力是重要的，但并不是一個(gè)好架構(gòu)師的組成因素。

51CTO編輯：對于一個(gè)剛剛從程序員轉(zhuǎn)型過來的架構(gòu)師，通常有哪些問題是他最難把握的？

#T#Fred：如果你從程序員的職位轉(zhuǎn)型，決定自己不再是程序員了，那么你的架構(gòu)師生涯將是短暫的。最好的架構(gòu)師都在寫代碼。Kent Beck曾經(jīng)寫道：“代碼就是設(shè)計(jì)與殘酷現(xiàn)實(shí)之黃昏的交匯(Code is when design meets the harsh reality of dawn.)”。他的意思是，我們畫出來的設(shè)計(jì)都是美好的，但最好的設(shè)計(jì)僅僅是被翻譯為優(yōu)雅代碼的那些。一個(gè)無法將愿景帶入代碼的架構(gòu)師將永遠(yuǎn)無法了解我們這個(gè)急速變化的行業(yè)所展示的深度。

所以說，不編程的架構(gòu)師的職業(yè)生涯是短暫的。

做為一個(gè)架構(gòu)師，我需要實(shí)現(xiàn)（這個(gè)過程是結(jié)對編程，我會有一個(gè)搭檔）一個(gè)系統(tǒng)最難實(shí)現(xiàn)的一部分。我將其稱之為“先鋒”，因?yàn)檫@是我檢驗(yàn)我腦中的主意是否真的是一個(gè)好主意的過程。我在第一次實(shí)施中會細(xì)化這個(gè)主意。然后我才會放心的讓編程團(tuán)隊(duì)的其他成員按照這個(gè)模式來走。這就是“架構(gòu)”。

有點(diǎn)跑題了。對于一個(gè)菜鳥架構(gòu)師而言，最大的障礙就在于承認(rèn)你并不知道詳細(xì)的答案，但你信心滿滿的認(rèn)為可以和程序員和設(shè)計(jì)師一起找到這個(gè)答案。

另一個(gè)新手架構(gòu)師經(jīng)常遇到的問題是“優(yōu)美”以及“簡約”。每次當(dāng)進(jìn)行決策的過程中出現(xiàn)這些概念的時(shí)候，項(xiàng)目經(jīng)理往往對這樣的理由不置可否。項(xiàng)目經(jīng)理通常有短期目標(biāo)要實(shí)現(xiàn)，而對優(yōu)美還是簡約這樣的概念并不感冒。但事實(shí)上，他們這是對系統(tǒng)未來健康狀況的不重視。

最后，菜鳥架構(gòu)師往往是出色的程序員。而他會發(fā)現(xiàn)團(tuán)隊(duì)中的其他程序員貢獻(xiàn)的代碼看起來不太美。菜鳥架構(gòu)師必須要學(xué)會界定哪些丑陋的代碼是可以接受的，哪些是不能接受的。

架構(gòu)師是藝術(shù)家，他們的成就往往不會在他們活著的時(shí)候被贊賞。

#p#

附錄：問題與Fred George郵件答復(fù)內(nèi)容的英文原文

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.