架構師害怕程式設計師知道的十項技能

一 每個好架構師都是一位出色的程式設計師（卓越的程式設計師）
架構師，聽起來是如此神祕的一個稱號。尤其是在開發領域剛入門不久的菜鳥級程式設計師眼中，架構師都是高手，都是牛人，都是如此高高在上的存在。
不過，在搞了四、五年程式設計之後，程式設計師們往往早已失去了當年對這些“高階”職位的神祕感，甚至會對自己所在專案的架構師抱怨不已，背後裡稱他們是一群水王。所以有江南白衣曾撰文述說：“國內的架構師到了三十歲以後很多就往理論上跑，而國外的架構師在往上發展的同時保持下面的程式設計體驗，所以國內多水王，而國外則多大師。”

這就是我們今天這篇文章的論題：一個優秀的軟體架構師，首先一定是一個出色的程式設計師。

這句話按照Fred George先生 的話來說，那就是“不程式設計的架構師的職業生涯是短暫的”。他說這句話的背景主要是針對有些架構師的設計與實現有斷層的問題而言的，因為如果架構師不去實踐，只是想當然的認為“沒問題，這個想法能實現”，那麼對於專案的落實而言是個很大的隱患。支付寶架構師馮大輝 也表示過，架構師是一個比較“虛”的崗位，主要的問題都在“落地”的過程中。

而一個架構師確認一個想法究竟能不能落地的最直接的方法，就是自己編寫程式碼，嘗試“實現一個系統最難實現的一部分”（Fred George）。看看Fred，他自己就是最好的示範：年紀一大把了，仍然每天都在編寫程式碼。事實上，我們可以列舉出一個長長的頂級架構師的列表，你會發現他們沒有一個不是頂級的程式設計師。

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

不過這在邏輯上或許沒有多少說服力，因為似乎這並不能證明一位資深架構師憑自己的經驗感覺不能夠知道一個想法能不能落實。如果你覺得上面這些只是某些西方老頭兒對程式設計的古怪癖好，那麼不妨看看eBay的架構師Randy Shoup先生 是如何總結架構師在專案中的職責的：

1. 產品團隊要做一個新產品，架構師開工了。架構師要幫助產品團隊把可行性、技術需求以及權衡取捨等因素一一剖析清楚。

2. 技術需求出來了，架構師的主要工作開始了：設計整體的技術實現步驟。Randy在後面補充說“大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作”，而認為自己應獨自完成這個步驟則是新手架構師常見的誤區。

3. 與開發團隊一起，完成設計與實施的細節

4. 與開發團隊和運維團隊一起，完成部署的過程

5. 與運維團隊一起，進行部署之後的維護和故障排除

在這個過程中，一個架構師至少有一半以上的工作是需要與開發團隊一起進行的。按照Randy的描述，這是“一個架構師不能將實施細節拋之腦後”的體現。而且與開發團隊一起工作，命令式的領導方式並不被推崇，一個架構師必須通過自己的個人影響力來對開發團隊進行指導工作。而什麼是影響力？說的直白一些，就是通過自己寫程式碼以及和其他成員一起寫程式碼，來指導團隊成員實現每個架構細節的思路。

只要稍微思考一下，就會明白此舉的重要性。如果一個架構師靠命令管理開發團隊，告訴他們“要實現這個模組”，“要實現那個功能”，而團隊也嘗試照辦。可是或許是架構師的要求太高了，或許是團隊的開發實力不夠，團隊成員便會向架構師求助：您看這個我們不知道如何實現，您能否指導一下？架構師可能知道怎麼處理，也可能沒有仔細思考過這個問題，但又覺得自己做大事者不拘泥於小節也，於是一皺眉頭扔下一句：這是你們的事，你們自己解決！

然後就是矛盾的開始了。架構師只覺得團隊技術不夠，而團隊則對架構師愈發不滿。專案黃了不說，開發團隊中也會傳出各種說法，比如說“此君其實是個一行程式碼也不會寫的大忽悠！”

 

綜上所述，便映證了Fred的那句斷言：“不程式設計的架構師的職業生涯是短暫的”。一個架構師不僅要會寫程式碼，還必須要能夠寫出自己設計的系統中最難實現的那段程式碼。這樣他才能夠放心的把“落地”的這個重擔交給開發團隊來做。

讓我用Fred的這句話做為本篇的總結：“一個架構師的價值在於，他不僅能看到系統的美，而且能夠在建造系統的時候能夠把這些美創造出來。”

是的，每個好架構師都是一位出色的程式設計師。

本文為《架構師害怕程式設計師知道的十項技能》中的優秀程式設計師篇。

二 女性架構師優先？駕馭概念的技能是最高潛力（抽象思維）

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

對高階架構師王翔先生的訪談 似乎能在一定程度上解答這個現象的由來。在訪談中，王翔先生說到自己在特定情況下會優先培養女性做為架構師，因為“架構師在創造性、知識彙總方面 根據個人經驗似乎女性更適合。”

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

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

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

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

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

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

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

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

以上就是《架構師害怕程式設計師知道的十項技能》中的抽象思維篇。

三 架構師：站在技術的山頂向前眺望（技術的前瞻性）

鐵打的程式設計師，流水的技術。程式設計師的開發生涯可能長達幾十年，但一門技術的平均壽命卻不長。因此作為程式設計師們的技術領袖，架構師必須有很好的技術前瞻性，要先於大家瞭解到最新的技術。

有人談到技術高手與架構師的區別就在於，架構師不光是著眼於現在，不僅僅侷限於開發細節，比如如何呼叫，如何併發等等。而是跳出三界外，考慮一下面向未來問題和潛在風險的應對之道。

那程式設計師該如何培養自己的技術前瞻性呢？很大程度上來說還是要學好英語，國外的新東西，老東西的新特性肯定都是用英文寫的。即使國內有很多網站也在做外電翻譯，但面對海量的資訊肯定是杯水車薪。而且有不少程式設計師所面對的領域本身關注度就不高，靠外部翻譯似乎很難實時跟進。這時就需要有良好的外語水平，能看懂國外的技術文章和文件，能與國外相關人士進行交流。

外功是從外部獲得最新技術資訊，那麼內功就是自己的邏輯思維能力和接受能力。再新的技術，其實也與以前的技術有結合。這也是為什麼我們說架構師首先是卓越的程式設計師，也就是這個道理。

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

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

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

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

51CTO總結： 技術人生如逆水行舟，不進則退。

本文為《架構師害怕程式設計師知道的十項技能》中的技術前瞻能力篇。

四 架構師修煉課程：透過問題看本質（問題 解決 大師）

一個剛剛從學校畢業的、致力於投身程式設計事業的年輕人，在投遞了n封簡歷之後，終於如願以償得到了第一份程式設計的工作。如果他在求學期間沒有積累過專案經驗，那麼可以說這就是他職業的起點，他青澀的程式設計之路開始了。

可能他一開始會滿腔抱負、意氣風發的按照自己的方式完成小頭目交給自己的一些練手任務，然後懊惱的發現小頭目對這些看似能夠完成任務的程式碼大搖其頭，指指點點；然後在真正進入專案之後，又會被各種不知道從哪裡冒出來的bug和漏洞搞得暈頭轉向……

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

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

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

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

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

1. echo   $_GET [ 'username' ];  

小頭目閱畢自然抓狂不已，因為這是一個再明顯不過的安全隱患。菜鳥程式設計師被小頭目訓了一頓，然後知道這樣做是有問題的。

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

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

什麼是本質？將世界萬物理解為原子，將整個網際網路理解成0和1，這倒的確是非常本質了，不過並不能解答任何問題。從問題看本質，實質上是一個從表層逐步深入的過程 。在架構師面對一個使用者需求時，這個“使用者需求”是非常表層的——比如說，一個自動遠端備份資料庫的功能。而架構師的主要工作，就是把這樣的“業務需求”翻譯成“技術需求” 。這個過程一方面需要通過抽象思維將使用者需求提煉為啟動、讀取、儲存、中斷處理等模組，而另一方面則需要看到更深層次的網路、作業系統、硬體等方面，以及其可靠性、穩定性、適用性、安全性等問題。

上面述說的是個小型需求，按照某些行業標準，這頂多只能算是一個資深程式設計師的工作，而沒有達到“架構”的規模——即，非大型專案中不存在真正的架構師（按照王翔先生 的描述，大型專案差不多是“100M(RMB)、B(RMB)、10B(RMB)”這些數量級）。那麼，讓我們看看大型系統的情況。以eBay為例，按照其架構師Randy Shoup 的介紹，電子商務站這樣大型的系統有兩個層面的功能：“垂直功能，如買、賣、搜尋、付款等。水平功能，如資料庫、事件與訊息系統、服務基礎設施、展示框架等。”按照編者的理解，如果說垂直功能是抽象思維的產物，那麼其中的水平功能的劃分則是一個架構師“透過問題看本質”能力的體現——這些劃分體現了架構師看到了表層的功能是建造在哪些因素之上的。同時，架構師要看到“電子商務站”這樣一個服務的本質 ，就是要提供一個多人同時線上進行交易的平臺，因此係統的本質也必須包括“功能，效能，可伸縮性，可管理性，安全性，以及可用性”這些因素。否則，即使搭了個架子，沒有上述特性的系統是完全無法滿足客戶需求的。

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

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

 

本文為《架構師害怕程式設計師知道的十項技能》中的透過問題看本質篇。

五 架構師：要成為百科全書式的智者(多領域知識)

通常來說我們將架構師分為系統架構師、軟體架構師等等。雖然有分工不同，各自所處的層次也有不同，但是究其核心能力，跨領域知識的學習能力，是架構師的強項所在。

首先，作為一名卓越的程式設計師，架構師肯定不欠缺開發方面的知識。從架構到方法論，從資料處理到安全監控。可以說IT開發層面上，架構師可以做到爐火純青的地步。但是這僅僅是一名卓越程式設計師的能力級別，離架構師那還有很大的一段距離。

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

很多程式設計師對架構師似乎存在偏見

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

有的程式設計師也會說，如果多學習跨領域、跨學科的東西，會不會成為什麼都懂，但什麼都不精的人？其實在這裡的跨領域，並不是要求大家都成為每個領域的專家。最重要的是有一門敲門磚，學習的引子。如果開發一套金融系統，對於財務結算以及處理方法都不瞭解，那別說是勝任架構師的任務，連普通程式設計師的工作也不可能做好。假設大家工作一段時間後，對某領域很瞭解，但由於工作變動的緣故，到其他公司後，開發的領域完全不會。這裡就要用到跨領域知識學習的能力了，需要大家樣樣都要知曉。

談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽群書，加上高中之前各學科紮實的基礎，相信大多數程式設計師本身就具備一定的跨領域學習的能力。但想成為真正的百科全書式的智者，恐怕不光是簡單覺得眼熟就行。在條件允許的情況下，程式設計師其實可以去參加一些其他領域的專業考試。比如參加會計資格證的考試，抑或其他專業中較初級的考試。這樣的經歷，主要還是在於“以學促考”，通過一定的壓力讓自己能鑽進去學習。

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

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

本文為《架構師害怕程式設計師知道的十項技能》中的跨領域學習能力篇。

六 架構師：一群善於溝通的技術領袖（溝通能力）

架構師的溝通方向與專案經理相比，還是有一定的區別。比如專案經理有很大一部分時間需要與客戶進行溝通，進一步弄清需求。而架構師的溝通主要在於開發團隊內部，一種純技術上的溝通。這也是作為技術領路人的架構師，最日常的工作。

當架構師對整個系統分析完畢，有一些架構師喜歡昏天黑地的奮鬥幾天，然後寫出一本厚厚的架構書扔給程式設計師。在此之後就不做過多的交流與溝通，“具體實現？那是程式設計師的事情，我怎麼能去幹涉他們呢？”其實在這裡，這位架構師就犯了錯誤，他並沒有將自己真正融入開發團隊中，而是以一種高高在上的救世主姿態出現。其實架構師未必就是神人，很多錯誤還是要大家一起來研究來解決的。

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

做到人性化的溝通，需要我們在平時就進行培養。寫出大部頭的架構書，有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖可以極大的方便程式設計師理解架構師的意圖。其次，可以召開小範圍的技術人員會議，大家一起來討論，一起理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的情況。

架構師就相當於一支球隊的主教練，如何將自己佈置的戰術交到執行的球員，也就是開發人員的腦袋裡，是關乎勝利的關鍵。那麼怎樣才能成為一名能說會道的程式設計師呢？

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

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

51CTO總結：架構師不是油腔滑調的程式設計師，但是一句話都憋不出來的程式設計師，是做不好架構師的。

本文為《架構師害怕程式設計師知道的十項技能》中的溝通能力篇。

七 獨家專訪馮大輝：由“實”及“虛”的架構師學習之旅（內力）

在過去的一週間，51CTO開發頻道陸續對國內外數位軟體架構師進行了郵件訪談，詢問他們一個程式設計師要成長為一個架構師需要學習哪些知識和技能，在工作上需要注意哪些問題。其中，王翔先生提到堅持不懈是架構師人生第一課 ，Fred George先生描述了架構師應該是有藝術追求的使用程式碼作畫的大師 ，而eBay的Randy Shoup先生則主要強調了架構師在專案需求、系統和團隊之間進行權衡取捨的重要能力

。

這一次，51CTO開發頻道邀請到了一位有些特別的嘉賓。他的大學專業是生物，畢業後開始從事IT。技術起點是Oracle資料庫，數年的工作經驗也主要圍繞Oracle資料庫的管理與效能優化。而他同時又是個技術雜家，對Oracle/MySQL關係型資料庫、Unix / Linux、網站架構 / 安全、使用者體驗、電子支付都有所涉及。活躍於各個技術社群，是國內IT業界最受歡迎的技術博主之一。自認為是個Evangelist（編者注：這個稱號由於其文化背景和意境，在國外的很多IT從業者都很願意使用這個稱號。直譯過來應為“技術佈道者”）。

他就是支付寶的資料架構師馮大輝先生。

 
馮大輝的Twitter頭像 @Fenng

學習篇

資料架構師（DB Architect）主要是從資料庫管理員（DBA）成長而來的，正如軟體架構師原本都是程式設計師一樣。資料庫管理員的工作是資料庫具體的維護工作，而架構師的工作則在一個更高的抽象層面上。因此大輝也曾說到，自己是從做一些比較“實”的維護工作的DBA轉變到一個相對比較“虛”的DBA崗位上。當然這樣的轉變並不輕鬆，架構師必須要有看得更遠、更全面的能力，成長的過程需要學習很多知識並積累經驗。對於自己的學習經歷，大輝在此次訪談中是這樣總結的：

“學習主要是通過網路進行，比如仔細研讀和架構有關的經典論文，訂閱一些技術架構師的BLOG。當然，不可或缺的是線下、線上的積極交流，我自己也會寫一些文章和大家分享，從分享中我也能再次學到很多。”

聽起來是一些挺平常的事情，但是如果你去大輝的部落格（dbanotes.net ），觀看他幾年間撰寫的博文，看到他那個長長的網誌關注列表，你會發現這是個絕佳的建議。網際網路發展到今天的程度，像網誌、社群這樣的平臺已經成為技術人自我提高的一個絕好的工具——而且幾乎沒有門檻。無論你是一個程式設計師還是DBA，維護一個技術部落格，與其他博主互相交流，絕對會令你受益良多——無論你是否希望成為一個架構師。

不過另一方面，視野和經驗的積累如果沒有實際的業務是很難獲得的。因此，如果你在一個公司平臺環境之上，那麼也要爭取“有意識的開拓技術視野，深入理解公司業務”，因為這些也是不可或缺的。大輝介紹說，資料架構師這個崗位很少有公司設定，很多時候沒有可供參考的案例，更多是摸索、琢磨。

能力篇

一個架構師有哪些必備的素質？在之前的訪談中，幾位架構師談到了在培養一位軟體架構師時最看重其抽象思維的能力，因為這是架構師的工作中最需要的能力，往往也是很多程式設計師所不具備的。正如Randy Shoup所介紹的那樣，像eBay這樣的大型系統，從專案啟動到最後的維護都有工作要做，但是第一步就是需要將整體需求抽象為垂直的買、賣、搜尋、付款，還有水平的資料庫、事件與訊息系統、服務基礎設施、展示框架等功能。而想法在落實的過程，也是對架構師抽象思維和邏輯思維能力的最大挑戰。大輝分享自己資料架構師經歷的挫折經驗，大多都是在想法的落實過程中。他說，一個比較新而且“虛”的崗位，一般"落地"會遇到一些問題，需要自己去摸索。這是個很難做到的事情。

同時，大輝也談了談自己對架構師這個群體的整體感受。他覺得他認識的架構師有一個共同點，那就是都“具備出色的交流能力，能夠推動大家就某些方向達成一致”。

八 獨家專訪Randy Shoup：架構師要學會權衡取捨（權衡取捨）

在軟體行業中，架構師往往是從那些出色的程式設計師中蛻變而成。然而，出色的程式設計師都能成功的晉級為出色的架構師麼？這是51CTO開發頻道年終活動《架構師最怕程式設計師知道的十件事》的主旨。雖然並非每一個程式設計師都希望能成為一個架構師，但潛意識裡他們是尊敬架構師的——而一個優秀的架構師往往在舉手投足中顯示出一個程式設計大師的風範。

為了深入的瞭解這些問題的答案，51CTO開發頻道展開了對國內外幾個著名架構師的一系列郵件訪談。本次訪談的物件是eBay的傑出架構師Randy Shoup先生。

架構師個人簡歷

 
eBay傑出架構師Randy Shoup

Randy Shoup是eBay市場架構團隊的傑出架構師(Distinguished Architect)。他從2004年開始成為eBay搜尋基礎設施的主要架構師。在eBay之前，他是Tumbleweed Communications的首席架構師，並在甲骨文以及Informatica公司擔任數職。他是史丹佛大學的數學與計算機系以及政治科學系的本科畢業生。

以下是此次訪談的具體內容。

51CTO編輯：不同的企業和專案經理對架構師往往定義不完全相同。在您的團隊中，對架構師是如何定義的？對於招聘的架構師會有怎樣的技能要求？

Randy Shoup：在eBay，一個架構師的任務就是設計一系列的技術方案，這些方案必須滿足商業上的要求，同時還要能夠維持高標準的功能，效能，可伸縮性，可管理性，安全性，以及可用性。一個架構師與開發團隊、產品團隊和運維團隊通過緊密的合作來實現上述的這些目標。

在產品團隊開始醞釀一個新的主意的時候，架構師是產品團隊第一個接觸的人：架構師會幫助他們把可行性、技術需求以及權衡取捨等因素一一剖析清楚。一個架構師之後的工作可總結為以下幾條：

◆設計整體的技術實現步驟

◆與開發團隊一起，完成設計與實施的細節

◆與開發團隊和運維團隊一起，完成部署的過程

◆與運維團隊一起，進行部署之後的維護和故障排除

一個架構師設立好技術風向標，並確保整個專案的進展按照這些方向進行。一個架構師不愛下達命令，他往往通過影響力來領導團隊。一個架構師考慮“大的”和“長期的”，並在各個因素之間做出權衡。

由於eBay是一個大站，每一個架構師都要為這個站的不同方面負責。有些對垂直功能負責，如買、賣、搜尋、付款等功能。有些對水平功能負責，如資料庫、事件與訊息系統、服務基礎設施、展示框架等功能。

我們在招聘架構師時有如下要求：

◆在設計與開發大型系統方面有10年以上做為開發者和技術管理者的經驗

◆技術領導能力

◆出色的交流和處理人際關係的技能，尤其是向開發者和非開發者解釋高階技術話題的能力

◆出色的分析和解決問題的能力

◆對我們的技術堆疊有相當程度的經驗

◆對於商業需求和客戶需求有著很強的理解能力，尤其是對權衡取捨方面有著出色的把控能力

51CTO編輯：假設有三名優秀的程式設計師，A尤其擅長溝通與團隊管理；B的程式設計功底深厚，且對新技術能快速掌握；C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程式設計師成為架構師？

Randy Shoup：一個優秀的架構師需要同時兼有A，B和C的能力。我們希望我們招聘的架構師擁有以上所有這些能力，這也是為什麼並非每一個頂級開發者都能夠成為一個優秀架構師的原因:-)

如果一定要排序，那麼我會按照C、B、A的順序。條理清晰的邏輯思維能力可能是一個架構師最重要的技能了，而我們往往發現擁有這種技能的人就像稀有動物那樣難找。不過，這個能力僅僅在和大量的實際開發經驗、豐富的理論背景和好的領導能力相結合的時候才能體現出它的價值。

51CTO編輯：對於一個剛剛從程式設計師轉型過來的架構師，通常有哪些問題是他最難把握的？

Randy Shoup：做為一個從菜鳥成長起來的架構師，我還真記得幾次挑戰：

◆習慣了思考細小的方面：有時候，一個新手架構師很容易在具體的程式碼編寫和實施上花費太多的精力。一個架構師最基本的職能是往廣處思考，把系統看做一個完整的個體來思考，以維護並增強可伸縮性和可用性這些系統級的特性為目標。一個架構師不能將實施細節拋之腦後，但她最大的價值在更高的層次。

◆習慣了單獨工作：有時候，一個新手架構師會覺得她的工作就是獨自開發出一個專案的架構和設計，並將這一整個成品交給一個團隊來完成實施的部分。不過據我所知，大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作。這不僅對架構本身有利，而且會令實施過程進展的更加平滑。

九 獨家專訪王翔：堅持不懈是架構師人生第一課（管控能力）

什麼是架構師最害怕程式設計師知道的十項技能？如何才能成為架構師？這是51CTO開發頻道年終活動《架構師最怕程式設計師知道的十件事》的主旨，其實程式設計師與架構師是合作互助的夥伴，程式設計師內心中成為架構師的願望是十分強烈的。本系列文章主要就是讓更多的人瞭解什麼是架構師，他們都有哪些鮮為人知的特殊技能，讓我們一起來向他們學習。今天我們訪問的是高階架構師王翔先生。

架構師個人簡歷

王翔

軟體架構師，主要從事Java EE/.NET企業應用、XML、公鑰基礎設施的開發。專注於資料（尤其是 XML）的生產、加工、交換、提煉等過程。此外，參與了一系列有關應用密碼技術和 PKI環境保護資訊系統資料安全的專案。

最喜歡數學,專案間隙經常到各海濱城市徒步旅行、野外露營、出海航行、極限運動。

所著圖書

《設計模式——基於C#的工程化實現及擴充套件》

《Google API大全——程式設計•開發•例項》（合著）

我們的問題主要為以下三個：

1、軟體架構師必須具備哪些技能或素質？哪項技能（素質)是您認為最重要的？

1)首先是經驗和技術基礎，以其昏昏做不到以人昭昭。

2)創造性和知識彙總能力，兩者互承

3)領導力和信心，架構師做事情要有格局

4)基於2、3語言(含母語)的溝通學習能力，不管做的是什麼專案，要有國際化視野

5)市場嗅覺

6)最後，好的A還有有些藝術氣質(畢竟軟體是給人用的，藝術正好是提供良好體驗的橋樑)和冒險精神（架構師要有烹小鮮的危機感，但要做業內創新更要有冒險精神)

僅從技能角度我一般總結為9個方面：

1、架構理論和方法學

2、物件理論

3、JEE/.NET/動態，技術領域技術能力。而且作為A最好保證鑽自己平臺基礎上，對其他平臺有個客觀、與時俱進的瞭解。

4、模式

5、遺留系統互聯

6、中介軟體

7、訊息機制和協議

8、本地化和國際化

9、安全性和效能

2、要成為一個架構師，是否存在快速成長的捷徑？普通程式設計師如何一步步向架構師的目標靠近?

存在捷徑，主要是機遇問題。

對國內而言，如果一個人一直從事M(RMB)級以下專案，那麼做10年或者做100個專案還是不能很快成長，如果他從事100M(RMB)、 B(RMB)、10B(RMB)專案，並且在其中負責全域性性的技術工作，那麼一兩個專案就可以快速成長，可能4、5年就能成為不錯的架構設計人員(不過還要看她/他交付成果的質量)。

普通程式設計師成為A最重要的是他自己有信念和行動，其他的都是其次的。

哪怕是Assistant Programmer，只要有信念和行動，應該可以承擔各種壓力和困難，逐步走上Programmer、S. Programmer、Developer、S. Developer、Designer、S. Desinger、A、S. A、D. A、C. A。

3、假設有三名優秀的程式設計師，A尤其擅長溝通與團隊管理；B的程式設計功底深厚，且對新技術能快速掌握；C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程式設計師成為架構師？

C(後面依次遞減是B、A。A更適合做專案經理、產品經理)

而且根據個人的經驗，雖然女性程式設計師開發階段顯得不如男性那麼快深入和入手(Programmer)，但能堅持到Developer、S. Developer、 Designer、S. Desinger階段她們的思維能力優勢就顯示出來。如果B是女性Desinger級別的人員，我寧願選擇培養她，因為架構師在創造性、知識彙總方面根據個人經驗似乎女性更適合。

十 獨家專訪樑遠華：架構師需要廣泛的知識面（藝術氣質）

成為一個軟體架構師往往需要具備十年以上的軟體開發經驗，入門的門檻是相當高的。而架構師的工作與實際專案經驗密不可分，尤其是在網際網路產品愈發重要的當下，一個軟體架構師往往需要掌握多項技能。程式設計師如果想要修煉為一個架構師，究竟需要培養自己的哪些技能？近日，51CTO開發頻道對廣州鐵克司雷網路科技有限公司（techsailor.cn ）樑遠華先生（Leung）進行了郵件專訪。樑先生現在是網路社群平臺聚聚呀（jujuya.com ）專案的專案總監。

架構師個人簡歷

 
聚聚呀專案總監樑遠華先生

樑遠華先生有十年的IT工作經驗，在鐵克司雷公司負責了整個聚聚呀專案的架構與實施。樑先生接觸過各種各樣的工作，做過的工種也是多種多樣，服務過的公司也是型別多樣，並且曾經和朋友一起兩次創業。曾經從事計算機教學，網管，程式設計師，網站專案管理等工作，並曾在資訊產業部第五電子科研所及地球村計算機科技公司積累了不少寶貴經驗。

以下是此次訪談的具體內容。

51CTO編輯：軟體架構師必須具備哪些技能或素質？哪項技能（素質）是您認為最重要的？

樑遠華：就我的經驗，下面三點是十分重要的。

１、整合分析能力

就拿聚聚呀來說吧，我們的宗旨是“讓大家結識共同興趣愛好人群的平臺，可以方便讓每個人建立和管理自己社群的平臺”，這個是我們現在的核心，對於一個架構師應該有很強的分析能力，能夠根據產品的宗旨，目標，分析產品的定位和產品業務，整合現有的技術領域用最佳的方式來實現產品的概念。

２、產品實現規劃能力

對於任何一個網際網路產品如何實現是架構師的重要責任之一，需要保證產品功能的現實，產品功能的可持續性，產品的穩定性及產品的可用性等。產品的這些需求都依懶於架構師對產品技術的規劃。我們團隊在產品的現實規劃上有自己明確的目標和具體的可行性實施方案，以滿足產品在升級，改版的需要。

３、橫向溝通能力

一個產品它會分成多個部門的合作，各部門溝通的有效性直接會影響到產品的質量和產品的進度。聚聚呀產品現在有7個部門的同事協同工作，對於架構師的溝通要求是需要去同各個部門間進行溝通，交流，獲得更多的產品資訊，業務資料，運營指標，產品需求等各種資訊的彙集才能作為產品架構決策的基礎資料。 

51CTO編輯：要成為一個架構師，是否存在快速成長的捷徑？普通程式設計師如何一步步向架構師的目標靠近?

樑遠華：成為架構師嚴格上來說是沒有什麼捷徑的，架構師從產品的生命週期上來看，他所涉及的層面很廣，而且他所需要的知識面也會很廣，需要過程更需要時間的學習和磨練。

我們的團隊也會有一個培訓機制，會挑選出一些比較有發展潛力的開發人員通過引導培訓方式讓他們走上架構之路。

我們的經驗是從以下幾個方面著手：

１、 擴大知識面：提升對網際網路行業的認知度，對網際網路產品的分析，並且通過小團隊分享方式對網際網路“熱門現象”進行案例分析。

２、 專業度訓練：提升橫向和縱向的技能培訓，特別是對專業態度的培訓很重要，要求開發人員對自己的做的工作有強烈的責任心。

３、 分析思維訓練：提升開發人員對產品功能需求的分析以及對產品業務需求的分析整合能力。

51CTO編輯：假設有三名優秀的程式設計師，A尤其擅長溝通與團隊管理；B的程式設計功底深厚，且對新技術能快速掌握；C在邏輯思維和抽象能力方面表現優秀。您會重點培養哪位程式設計師成為架構師？

樑遠華：我會選擇C在邏輯思維和抽象能力方面表現優秀，架構師需要很強的抽象能力。

51CTO編輯：在一個軟體專案中，通常有哪些問題是架構師最難把握的？

樑遠華：我感覺有下面兩點——

１、 對問題的定位，分析

２、 權衡取捨

以上二點在做聚聚呀產品過程中有深刻的體會，特別是第二點，一個產品會有很多的東西要做，什麼是可做的，什麼是重要的，什麼是將來能做的，每天都做做選擇題。