【轉】不是每一個程序員都能夠成爲一個架構師

不是每一個程序員都能夠成爲一個架構師——這是開發界廣爲流傳的一個論調。架構師羣體往往對這個言論表示默許，這不得不令廣大入門不久的程序員們懷疑架構師們是不是隱藏了什麼武林祕籍。程序員要修煉什麼武功才能晉升爲一個架構師？

架構師最怕程序員知道的十件事

藝術氣質
管控能力
權衡取捨
內力
溝通能力
多領域知識
問題解決大師
技術前瞻性
抽象思維
卓越的程序員

每個好架構師都是一位出色的程序員

架構師，聽起來是如此神祕的一個稱號。尤其是在開發領域剛入門不久的菜鳥級程序員眼中，架構師都是高手，都是牛人，都是如此高高在上的存在。

不過，在搞了四、五年編程之後，程序員們往往早已失去了當年對這些“高級”職位的神祕感，甚至會對自己所在項目的架構師抱怨不已，背後裏稱他們是一羣水王。所以有江南白衣曾撰文述說：“國內的架構師到了三十歲以後很多就往理論上跑，而國外的架構師在往上發展的同時保持下面的編程體驗，所以國內多水王，而國外則多大師。”
這就是我們今天這篇文章的論題：一個優秀的軟件架構師，首先一定是一個出色的程序員。

這句話按照Fred George先生的話來說，那就是“不編程的架構師的職業生涯是短暫的”。他說這句話的背景主要是針對有些架構師的設計與實現有斷層的問題而言的，因爲如果架構師不去實踐，只是想當然的認爲“沒問題，這個想法能實現”，那麼對於項目的落實而言是個很大的隱患。支付寶架構師馮大輝也表示過，架構師是一個比較“虛”的崗位，主要的問題都在“落地”的過程中。
而一個架構師確認一個想法究竟能不能落地的最直接的方法，就是自己編寫代碼，嘗試“實現一個系統最難實現的一部分”（Fred George）。看看Fred，他自己就是最好的示範：年紀一大把了，仍然每天都在編寫代碼。事實上，我們可以列舉出一個長長的頂級架構師的列表，你會發現他們沒有一個不是頂級的程序員。

我們可以列舉出一個長長的頂級架構師的列表，你會發現他們沒有一個不是頂級的程序員

不過這在邏輯上或許沒有多少說服力，因爲似乎這並不能證明一位資深架構師憑自己的經驗感覺不能夠知道一個想法能不能落實。如果你覺得上面這些只是某些西方老頭兒對編程的古怪癖好，那麼不妨看看eBay的架構師Randy Shoup先生是如何總結架構師在項目中的職責的：
1. 產品團隊要做一個新產品，架構師開工了。架構師要幫助產品團隊把可行性、技術需求以及權衡取捨等因素一一剖析清楚。
2. 技術需求出來了，架構師的主要工作開始了：設計整體的技術實現步驟。Randy在後面補充說“大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作”，而認爲自己應獨自完成這個步驟則是新手架構師常見的誤區。
3. 與開發團隊一起，完成設計與實施的細節
4. 與開發團隊和運維團隊一起，完成部署的過程
5. 與運維團隊一起，進行部署之後的維護和故障排除

在這個過程中，一個架構師至少有一半以上的工作是需要與開發團隊一起進行的。按照Randy的描述，這是“一個架構師不能將實施細節拋之腦後”的體現。而且與開發團隊一起工作，命令式的領導方式並不被推崇，一個架構師必須通過自己的個人影響力來對開發團隊進行指導工作。而什麼是影響力？說的直白一些，就是通過自己寫代碼以及和其他成員一起寫代碼，來指導團隊成員實現每個架構細節的思路。* ?* N h( v+ i, H
只要稍微思考一下，就會明白此舉的重要性。如果一個架構師靠命令管理開發團隊，告訴他們“要實現這個模塊”，“要實現那個功能”，而團隊也嘗試照辦。可是或許是架構師的要求太高了，或許是團隊的開發實力不夠，團隊成員便會向架構師求助：您看這個我們不知道如何實現，您能否指導一下？架構師可能知道怎麼處理，也可能沒有仔細思考過這個問題，但又覺得自己做大事者不拘泥於小節也，於是一皺眉頭扔下一句：這是你們的事，你們自己解決！4 c! v0 E$ @1 ? [. `
然後就是矛盾的開始了。架構師只覺得團隊技術不夠，而團隊則對架構師愈發不滿。項目黃了不說，開發團隊中也會傳出各種說法，比如說“此君其實是個一行代碼也不會寫的大忽悠！”

綜上所述，便映證了Fred的那句斷言：“不編程的架構師的職業生涯是短暫的”。一個架構師不僅要會寫代碼，還必須要能夠寫出自己設計的系統中最難實現的那段代碼。這樣他才能夠放心的把“落地”的這個重擔交給開發團隊來做。
讓我用Fred的這句話做爲本篇的總結：“一個架構師的價值在於，他不僅能看到系統的美，而且能夠在建造系統的時候能夠把這些美創造出來。
是的，每個好架構師都是一位出色的程序員。

女性架構師優先？駕馭概念的技能是最高潛力

在近日對數位架構師進行採訪的時候，編輯觀察到一個很有意思的現象，那就是他們在提起一個假想架構師的時候會下意識的使用“she”或者“她”來指代。然而我們這次採訪到的的架構師們卻全都是男士，這似乎是一個比較難以理解的現象。

對高級架構師王翔先生的訪談似乎能在一定程度上解答這個現象的由來。在訪談中，王翔先生說到自己在特定情況下會優先培養女性做爲架構師，因爲“架構師在創造性、知識彙總方面根據個人經驗似乎女性更適合。
無論王翔先生的個人經歷是否常態，既然說男人來自火星而女人來自金星，那麼這至少表明是否適合架構師一職與人的思維模式有很大關係。在這一系列的訪談中，所有接受採訪的架構師們都一致的表示邏輯思維和抽象思維能力是一個架構師最重要的素質。eBay的Randy Shoup先生稱擁有條理清晰的邏輯思維能力的人“就像稀有動物那樣難找”。Fred George則表示“駕馭概念的技能，在我看來是每一個人最高的潛力”，並表示自己不太介意這樣一個苗子在其他方面的技能和經驗的匱乏，因爲在他看來除了思維之外的其他因素都是可以培養的。

邏輯思維，抽象思維，這些乾巴巴的名詞並不比高舉某某旗幟、將某某貫徹到底的口號說明了更多問題。架構師們習慣了思考“虛”飄飄的概念，但如果不能讓非IT人員明白這個或那個概念到底是在說什麼，那麼這個架構師也註定是失敗的（詳見架構師技能之溝通技術篇）。所以首先有必要解釋一下這些架構師們說的這兩個概念是什麼意思。

程序員對邏輯思維是再熟悉不過了，因爲程序員寫的代碼都是邏輯。如果怎樣怎樣就做什麼什麼，如果什麼什麼就觸發這個或停止那個。編寫條件這樣的邏輯構成了代碼中的絕大部分，因此缺乏邏輯思維能力基本等同於不可能成爲程序員。架構師必須要有很好的邏輯思維的理由，事實上和架構師必須先是個出色程序員的理由是一樣的（詳見架構師技能之優秀程序員篇）。

因此本文的關鍵在於抽象思維能力。這個能力常常被與物理成績或數學能力等同起來，但它事實上並不是計算能力。比如說小學常見的數學題，兩個城之間的鐵路長度500公里，一輛火車平均時速100公里，問這輛火車從這個城到那個城需要多少時間。學生們往往會陷在於500公里、100公里/小時和5小時這些數字中，但是這道題的抽象因素其實是在“長度”、“時速”和“時間”這三個概念當中。

這其中其實又有兩個概念，一個是將實在的事物概念化，一個是將模糊的感覺數量化。看到一個蘋果，能夠將其抽象爲質量、大小、顏色、形狀、味道等概念的組合，就是概念化，而量化則是在概念化之上，將蘋果用多少克、多少立方厘米來定義；至於顏色、形狀、味道等概念，則是還沒有完善量化標準的概念。如果在沒有徹底理解概念的前提下過分拘泥於數字，那麼到頭來只是活躍了頭腦的計算功能而無助於抽象思維的鍛鍊。

人們往往發現優秀的數學家、物理學家以及軟件架構師有着很多相似的素質，甚至往往能夠一人精通這好幾個領域（比如UML之父James Rumbaugh），其中很重要的原因就是這個抽象思維的能力。架構師在接到商業需求之後，最主要的工作就是將其轉化爲技術需求。這個過程的完成與架構師抽象思維的能力密不可分。好比說這個項目是eBay那樣的電子商務平臺，那麼eBay的主架構師第一個閃過的念頭多半就是：這個系統，將會有“買、賣、搜索、付款等功能。”而負責每一個功能的架構師，又需要對這些部分進行進一步的抽象化。

很難想象一個缺乏抽象思維能力的人，要如何擔負起架構師的工作。

而抽象思維和之前所講的邏輯思維能力，並非是同一個東西，這也是爲什麼並非所有優秀的程序員都能夠成爲一個好的架構師。不過編輯在這裏並不是想說難以成爲架構師的程序員都是缺乏天賦，事實上抽象思維並非是一個不能培養的能力，只是它需要你主動地去思考。正如支付寶的馮大輝所說，程序員要想成爲架構師，必須“有意識的開拓技術視野，深入理解公司業務”，這其實就是一個擴展視野的同時，培養抽象思維能力的過程。架構師在項目中處於位置較高的地方，工作的問題很難說找到誰來學習、借鑑一下，更多的是摸索、琢磨。如果你有這樣的決心和毅力，那麼相信抽象思維的能力也是不會難倒你的。

架構師：站在技術的山頂向前眺望
鐵打的程序員，流水的技術。程序員的開發生涯可能長達幾十年，但一門技術的平均壽命卻不長。因此作爲程序員們的技術領袖，架構師必須有很好的技術前瞻性，要先於大家瞭解到最新的技術。
有人談到技術高手與架構師的區別就在於，架構師不光是着眼於現在，不僅僅侷限於開發細節，比如如何調用，如何併發等等。而是跳出三界外，考慮一下面向未來問題和潛在風險的應對之道。

那程序員該如何培養自己的技術前瞻性呢？很大程度上來說還是要學好英語，國外的新東西，老東西的新特性肯定都是用英文寫的。即使國內有很多網站也在做外電翻譯，但面對海量的信息肯定是杯水車薪。而且有不少程序員所面對的領域本身關注度就不高，靠外部翻譯似乎很難實時跟進。這時就需要有良好的外語水平，能看懂國外的技術文章和文檔，能與國外相關人士進行交流。
6 k6 Z3 z" Y/ s
外功是從外部獲得最新技術信息，那麼內功就是自己的邏輯思維能力和接受能力。再新的技術，其實也與以前的技術有結合。這也是爲什麼我們說架構師首先是卓越的程序員，也就是這個道理。

但是架構師並不是將前沿技術的名詞天天掛在嘴上之人，整天只知道在程序員面前大談“雲計算，SaaS”這些東西的架構師註定成不了好的架構師。新的技術雖好，但是程序員接受和再培訓還需要時間，還要考慮到系統的兼容性問題。因此，誇誇其談的名詞專家，並不是我們努力的方向。好的架構師，應該提前想到如何爲程序員儘可能減輕負擔，比如數據庫軟件新的特性可以提高性能，簡化查詢步驟，那架構師是不是第一時間要引導程序員去適應新的特性，提高開發效率。


被技術潮流拋棄的架構師是可悲的

技術前瞻性還體現在對新技術的選擇上，哪些東西適合自己團隊，哪些不適合肯定要自己心中有本帳。工具選好了再返工的人力成本和時間成本是很多公司沒法負擔的，利潤就那麼多，經不起瞎折騰。程序員在自己的學習過程中，也可以適當培訓一下自己，比如新的IDE中有新的功能，但是要安裝這新版本的IDE需要更新系統，更新硬件，還要更新和數據庫的接口。這一套下來花費的時間成本是多少，換算成工資是多少？我想事事都這樣過一遍，我們在做選擇的時候就不會盲目。

架構師在自己所處的領域肯定了解頗深，未來本領域技術該如何發展，應該有自己的理解。也會對未來技術的發展有所期盼，有自己的見解。當然這屬於比較發散的想法，個人有個人的目標。

架構師修煉課程：透過問題看本質.
一個剛剛從學校畢業的、致力於投身編程事業的年輕人，在投遞了n封簡歷之後，終於如願以償得到了第一份編程的工作。如果他在求學期間沒有積累過項目經驗，那麼可以說這就是他職業的起點，他青澀的編程之路開始了。
可能他一開始會滿腔抱負、意氣風發的按照自己的方式完成小頭目交給自己的一些練手任務，然後懊惱的發現小頭目對這些看似能夠完成任務的代碼大搖其頭，指指點點；然後在真正進入項目之後，又會被各種不知道從哪裏冒出來的bug和漏洞搞得暈頭轉向……

這些問題一方面和這位菜鳥程序員缺乏經驗有關，但是在過來者看來，造成這些問題的一個主要原因正是在於，這位程序員沒能看到問題的本質。

而看到問題的本質，也是架構師所必須具備的素質。

所謂看到問題的本質，實際上是一個思考的層面問題。比如說，你現在看到的這篇文章，從表面上看，就是你的顯示屏顯示出來了一些文字，但這明顯不是它的本質。從內容而言，這篇文章是一篇有關架構師技能的文章，它是對一個職業的某一項能力的描述；從技術而言，這篇文章是在世界上某臺服務器上的數據庫中提取出來的某些信息，經過漫長光纜和層層協議的傳遞，經過你的網線插口（或無線接收器）進入了你的機器，通過瀏覽器解讀並最終呈現出來。

聽起來，這個和另一篇文章介紹的同樣是架構師所需要的“抽象思維”有點像，只是方向不同：抽象思維是往高層次的昇華，透過問題看本質則是往深層次的挖掘。

讓我們看看文章一開始的那位菜鳥程序員爲什麼總是失敗。如果你是一位PHP程序員，那麼可以參考這篇文章，裏面總結了一些常見的問題。最簡單的一個（有時被用作面試題）可能出現在這樣的情況下——小頭目說：“顯示用戶提交的ID名”，然後菜鳥程序員大筆一揮：

echo $_GET['username']; 小頭目閱畢自然抓狂不已，因爲這是一個再明顯不過的安全隱患。菜鳥程序員被小頭目訓了一頓，然後知道這樣做是有問題的。

這個事情如何與通過問題看本質有關？這個就取決於這位菜鳥程序員是如何改正這個錯誤的。如果這位程序員只是把下面的那段“合格”代碼抄襲過來並死記硬背，那麼，以後等待這位程序員的大概是比較悲慘的結局——因爲漫長的代碼生涯中有極多類似的問題，而等到他進入真正的項目之後，犯錯誤是有成本的。他的學習方式表示他沒有主動避免這樣類似問題的能力，那麼他可能將會造成極大的損失，從而最終失去在這個行業的競爭力。9 ])

但是，如果他瞭解到代碼之下，更深層次的那些機制，比如echo是如何執行的？在什麼時候執行的？哪些字符可能導致安全問題？htmlspecialchars爲什麼能解決這個問題？它真的解決這個問題了麼？那麼他將會一點一點的進步，逐漸成爲一個合格的程序員。

什麼是本質？將世界萬物理解爲原子，將整個互聯網理解成0和1，這倒的確是非常本質了，不過並不能解答任何問題。從問題看本質，實質上是一個從表層逐步深入的過程。在架構師面對一個用戶需求時，這個“用戶需求”是非常表層的——比如說，一個自動遠程備份數據庫的功能。而架構師的主要工作，就是把這樣的“業務需求”翻譯成“技術需求”。這個過程一方面需要通過抽象思維將用戶需求提煉爲啓動、讀取、存儲、中斷處理等模塊，而另一方面則需要看到更深層次的網絡、操作系統、硬件等方面，以及其可靠性、穩定性、適用性、安全性等問題。
上面述說的是個小型需求，按照某些行業標準，這頂多只能算是一個資深程序員的工作，而沒有達到“架構”的規模——即，非大型項目中不存在真正的架構師（按照王翔先生的描述，大型項目差不多是“100M(RMB)、B(RMB)、10B(RMB)”這些數量級）。那麼，讓我們看看大型系統的情況。以eBay爲例，按照其架構師Randy Shoup的介紹，電子商務站這樣大型的系統有兩個層面的功能：“垂直功能，如買、賣、搜索、付款等。水平功能，如數據庫、事件與消息系統、服務基礎設施、展示框架等。”按照編者的理解，如果說垂直功能是抽象思維的產物，那麼其中的水平功能的劃分則是一個架構師“透過問題看本質”能力的體現——這些劃分體現了架構師看到了表層的功能是建造在哪些因素之上的。同時，架構師要看到“電子商務站”這樣一個服務的本質，就是要提供一個多人同時在線進行交易的平臺，因此係統的本質也必須包括“功能，性能，可伸縮性，可管理性，安全性，以及可用性”這些因素。否則，即使搭了個架子，沒有上述特性的系統是完全無法滿足客戶需求的。

看到這裏我們應該明白了，“透過問題看本質”並不是什麼神祕的能力，而是有一定經驗能力的程序員都具備的能力。如果你在編寫Java代碼時考慮到了JVM的性能，在編寫PHP代碼時想到了潛在的安全問題，甚至於在編寫HTML+CSS頁面時考慮到了不同瀏覽器的兼容性，這些都體現了“透過問題看本質”的素質。只是，架構師之所以爲架構師，是在於他們在面對龐大系統之時，仍然能夠敏銳的發現其底層之真實。這不僅需要此哲學層面的“內功”，還需要架構師具有多領域知識和經驗的積澱。

“透過問題看本質”，這也是程序員往往需要修煉十餘年纔有資格晉升爲架構師的主要原因之一。程序員們，好好努力吧！

架構師：一羣善於溝通的技術領袖
架構師的溝通方向與項目經理相比，還是有一定的區別。比如項目經理有很大一部分時間需要與客戶進行溝通，進一步弄清需求。而架構師的溝通主要在於開發團隊內部，一種純技術上的溝通。這也是作爲技術領路人的架構師，最日常的工作。
當架構師對整個系統分析完畢，有一些架構師喜歡昏天黑地的奮鬥幾天，然後寫出一本厚厚的架構書扔給程序員。在此之後就不做過多的交流與溝通，“具體實現？那是程序員的事情，我怎麼能去幹涉他們呢？”其實在這裏，這位架構師就犯了錯誤，他並沒有將自己真正融入開發團隊中，而是以一種高高在上的救世主姿態出現。其實架構師未必就是神人，很多錯誤還是要大家一起來研究來解決的。

究竟怎樣才能是一名合格的架構師，成爲一名真正能說會道的程序員呢？首先自然是溝通要清晰明瞭，平和待人。架構師不能將自己鎖在自己的象牙塔上，頤指氣使的對程序員發號施令。這樣的態度必然遭到程序員的憤恨，大家都是一樣的技術人員，只是分工的不同，爲什麼要受氣呢？

做到人性化的溝通，需要我們在平時就進行培養。寫出大部頭的架構書，有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖可以極大的方便程序員理解架構師的意圖。其次，可以召開小範圍的技術人員會議，大家一起來討論，一起理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的情況。
架構師就相當於一支球隊的主教練，如何將自己佈置的戰術交到執行的球員，也就是開發人員的腦袋裏，是關乎勝利的關鍵。那麼怎樣才能成爲一名能說會道的程序員呢？

在一般人的印象裏，程序員都是一羣略顯呆滯，溝通能力不強的技術狂人。邏輯思維非同常人，但就是倒不出來。有些人通過找女朋友作爲旁證，連經濟適用男中的定義原型都是IT人士，月薪4000以上，不善言談，最後娶一剩女爲妻。看來我等程序員，真的只能被人如此定義了。雖說架構師技術層面上的東西與前例不可同日而語，但是也看到溝通能力上，程序員還有很大的發展空間。


其實很多程序員都是善於談吐的，木訥的形象只是人們的誤解。但是如何來改變呢？首先我們需要更多的感性思考，說話時也要注重別人的感受，尊重對方纔能更好的交流。微軟MVP陳廣琛在與51CTO編輯談到程序員溝通能力時，曾說道：“很多程序員總能列出一堆的理由來，說明爲什麼自己不適合學習或者不需要掌握某項與程序無關的技能，例如說演講、英語、設計等等。但其實問題並沒有那麼複雜，你需要考慮的只是多學一項技能是否對你的職業發展更有利，只要你願意，沒什麼是不能改變的。”

架構師：要成爲百科全書式的智者
通常來說我們將架構師分爲系統架構師、軟件架構師等等。雖然有分工不同，各自所處的層次也有不同，但是究其核心能力，跨領域知識的學習能力，是架構師的強項所在。
首先，作爲一名卓越的程序員，架構師肯定不欠缺開發方面的知識。從架構到方法論，從數據處理到安全監控。可以說IT開發層面上，架構師可以做到爐火純青的地步。但是這僅僅是一名卓越程序員的能力級別，離架構師那還有很大的一段距離。

架構師身爲一名技術領袖，需要通過發散知識的光芒來統御開發團隊的。如果只是對本行業知識做到爛熟於心，那還僅僅是一名熟練工的水平。要想晉升更高的層次，還需要跳出“只緣身在此山中”的困惑。例如在目前國內架構師，至少有網絡領域爲依託，物流金融證券等熟知越多越好，這個是應用級別。比如南天的金融平臺研發部門，但是這個成不了底層平臺架構師。再往上走，很多公司的研發人員不是精通計算機，可能是物理極爲精通，比如中軟研發聲納軟件部門很多人對數據信號極有研究。

很多程序員對架構師似乎存在偏見

這裏就會出現一個常見的問題“架構師是不是一個只會誇誇其談，只會忽悠下面人而對軟件開發瞭解不多的人？”更尖酸的問題還在於架構師連一段代碼都不會寫。相信這是一定的誤解，就好像銀行的高層管理人員，要更多的從宏觀的角度考慮問題，儘管他們點鈔的能力肯定不及下面的櫃檯人員。事必躬親的諸葛亮，最後的結局還是國破家亡，過多的干預細節忽視整體，絕對是要打敗仗的。架構師學習更多跨領域知識，也是爲了在接受一個項目時，能更快更準確的找到解決問題的“命門”。

有的程序員也會說，如果多學習跨領域、跨學科的東西，會不會成爲什麼都懂，但什麼都不精的人？其實在這裏的跨領域，並不是要求大家都成爲每個領域的專家。最重要的是有一門敲門磚，學習的引子。如果開發一套金融系統，對於財務結算以及處理方法都不瞭解，那別說是勝任架構師的任務，連普通程序員的工作也不可能做好。假設大家工作一段時間後，對某領域很瞭解，但由於工作變動的緣故，到其他公司後，開發的領域完全不會。這裏就要用到跨領域知識學習的能力了，需要大家樣樣都要知曉。
談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽羣書，加上高中之前各學科紮實的基礎，相信大多數程序員本身就具備一定的跨領域學習的能力。但想成爲真正的百科全書式的智者，恐怕不光是簡單覺得眼熟就行。在條件允許的情況下，程序員其實可以去參加一些其他領域的專業考試。比如參加會計資格證的考試，抑或其他專業中較初級的考試。這樣的經歷，主要還是在於“以學促考”，通過一定的壓力讓自己能鑽進去學習。

還有一種跨領域學習的目標，就是多語種的學習。學習除英文之外的語言，既能開拓國際視野，也能在平時的工作中有所建樹。

架構師害怕程序員知道的技能，其實就是他們自己“獨門絕技”。雖然他們自己不說，但是我們自己還是能總結出來，在一定深度之內成爲一個“雜家”並沒有什麼不好。其關鍵在於所學的跨領域知識，能否成功的運用到工作中去。在採訪王翔高級架構師時，他曾提到，一個致力於成爲架構師的程序員。需要儘可能的參加大的項目開發，儘管積累1000個小項目的經驗也是很好的程序員，但好的架構師必須參與更大的項目，哪怕數量不多。從中我們能解讀到一個信息，大的項目意味着學科跨度的增大，所需要學習的跨領域知識必然也足夠大，也就更有利於程序員向架構師晉級。