"比你牛B的人比你還努力,你有什麼資格不去奮鬥"

   http://developer.51cto.com/developer/top10Architect/#rd?sukey=66d4519b2d3854cd535bf0462edeb1d5721720363e90d6701c95530c7d8a78ac6203d54a7f38501ac7386ff1f65d9356

一、卓越的程式設計師：每個好架構師都是一位出色的程式設計師

這一點毋庸置疑，如果不是寫過N年程式碼的優秀程式設計師，一定不是好的架構師。“架構師”這是一個聽上去比較虛的職位，它的主要價值在於“落地”的過程中，而不是“指點江山”。eBay的架構師總結架構師在專案中的職責：

1)、解決解決方案：產品團隊要做一個產品，架構師要幫助團隊把技術可行性，技術方案權衡取捨一一剖析清楚；

2)、架構設計和技術實現步驟：技術方案權衡取捨出來了，架構師要設計整體的技術實現步驟，這個過程一定是和團隊其他成員一起完成的，常見的實踐是，1到2個核心成員出一個初稿，然後大家討論完善；

3)、編寫核心模組：技術實現步驟出來了，架構師要和開發團隊一起，進行編碼，可能架構師不一定細究到任何細節，常見的實踐是，系統最困難最核心最關鍵的部分往往由架構師親自操刀；

4)、部署上線和完善流程：系統初版實現了，架構師要和開發團隊、測試團隊、運維團隊一起，完成各類測試，協助解決最困難的bug，和團隊一同完成線上部署、並一同排除上線初期系統的故障

在專案的過程中，架構師至少一半以上的時間是和開發團隊一起進行的，好的架構師不能將實施細節拋之腦後，更直白一些，他要通過撰寫程式碼的方式來指導團隊其他成員理解和實現架構中的細節。

反面的例子是，專案失敗後，架構師反饋“團隊的技術能力不夠”，團隊反饋“這是一個一行程式碼也不會寫的大忽悠”。

二、抽象思維：駕馭概念的技能是最高潛力

“邏輯思維，抽象思維”比“編碼的時間”對架構師而言更為重要，如果你不能讓某個非IT人員明白某個概念在說什麼，這個架構師註定也是失敗的

邏輯思維不用展開多說，程式設計師的程式碼都是邏輯，如果XXX就YYY，如果AAA就BBB，缺乏良好的邏輯思維能力基本不可能成為好的架構師，甚至好的程式設計師。

抽象思維又分兩點，一個是將實在的事物概念化，一個是將模糊的感覺數量化。一個蘋果，抽象為質量、大小、顏色、形狀、味道等，這是概念化，是架構師的必備思維。至於質量、大小、顏色、形狀、味道如何轉變成數字來描述，這也是架構師必備的思維。

有了上述兩點，架構師能將一個“虛”的架構概念描述清楚。

三、技術前瞻性：站在技術的山頂向前眺望

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

架構師與技術高手的區別在於，架構師不僅侷限於如何呼叫、如何併發等架構細節（技術高手對這些也非常熟練），還跳出三界，考慮未來問題和潛在風險的應對之道。

要培養自己的技術前瞻性，首要是學好英語（不多屆時了，希望未來最先進的技術都首先從國內誕生），看懂外文技術文章，能與業界專家溝通交流，學習別人的實踐方案。

反面的例子是，成天將技術前言的名詞掛在嘴邊，大談“雲端計算，SaaS”這些東西，天天吹水，而落不了地（有可能他自己也搞不清概念如何落地）。

技術前瞻性還提現在對新技術的選型上，哪些東西適合自己團隊，哪些不適合。學習成本、維護成本、硬體成本、潛在風險等等都是架構師需要考慮的。

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

四、透過問題看本質：解決問題和繞開問題

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

菜鳥程式設計師的如此寫PHP：

echo $_GET['username'];  

大部分人知道這個出現安全隱患。一般人使用htmlspecialchars解決問題就可以了。但問題的本質是什麼？可以從更深的層次去理解：

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

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

架構師要有將“業務需求”轉化為“技術需求”的能力，這是一個本質的挖掘。例如，業務層面看到的是一個“電子商務網站系統”，架構師看到的是一個多人線上，併發交易，需要保證資料一致性的站點、服務、資料系統，功能、效能、擴充套件性、維護性、安全性、可用性這些字眼會慣性的蹦到架構師的腦子裡。

架構師之所以是架構師，他在龐大系統的面前，仍然能夠敏銳發現其底層之真實，這就需要，他有多年多領域知識和經驗的沉澱。

五、跨域知識：要成為百科全書式的智者

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

架構師作為一名技術領袖，需要通過散發知識的光芒來溫暖開發團隊，如果只一個領域內的知識爛熟於胸，那也僅僅是一名技術高手。要想更進一步，需要對APP層面、服務層面、資料層面均要了解（系統分層），要對研發、測試、運維、安全也要有所瞭解（職能），上要對介面，下要對原理（介面與實現）都有所瞭解，甚至，要在多個業務領域都有所涉獵。

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

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

初級架構師所害怕的，是跳出自己的“獨門絕技”，在一定程度上說，在一定深度之內成為一個“雜家”也沒什麼不好。

六、溝通能力：善於溝通的技術領袖

架構師和專案經理，對溝通能力的要求都很高，很多網際網路公司甚至直接由架構師擔任專案經理的角色。這兩個角色其實還是有所偏重的，專案經理更傾向於與客戶的交流，跨團隊的協作與交流，架構師主要偏向技術團隊內部的溝通與交流，純技術上的溝通。

如何成為一名“善於溝通”的架構師呢？在目標清晰的前提下：

首先做到平和，不能將自己所在象牙塔上，頤指氣使的發號施令，這樣的態度必然遭恨，大家都是技術人員，只是分工不同，為何要受你的氣呢？

其次，架構師要有一定的繪圖能力。人對圖形的理解遠大於對文字的理解，一個層次圖，一塊小白板，幾隻筆，真的這麼容易把問題描述清楚麼？

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

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

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