前面一年多的時間裡，一直不停的在尋找架構師architect。簡歷收集了上百個，前後面試了至少數十人，大多有相當不錯的職業經歷，也有相當不 錯的專案經驗，他們在很多技術方向都很出色，也有不少含金量高的證書，例如ccie。可是，令人遺憾的告訴大家，找到一位令人滿意的架構師實在是一件非常 不容易的事情。架構師，如同字面上的含義一樣，掌握著乙個建築的風格、層次、標準等。it architect也不例外。架構師決定技術方案的走向，很大程度上會影響管理層的決策，並且對後續的執行和業務交付都至觀重要。
坦白說，雖然也有些候選人是因為英語的問題，但是大部分候選人讓我放棄的原因是考慮問題的方式和技術素養。讓我來總結一下我對架構師的理解。
1 面向架構的思考
乙個目標或一件設計任務，在架構師的頭腦中，永遠是有層次感的，是立體的，就如同草稿中的乙個建築物：它應該是乙個什麼型別的建築物，需要多少個支撐面、 大概需要多高（幾層樓）、需要滿足多少功能…。實際上，這是一種考慮的習慣。我們大領導在一次講話中，提到分類學的問題，強調分類學是管理者最應該具備的 素養之一。我也借用一下，架構師的乙個重要素養或價值是將乙個問題或者方案的「分類學」搞清楚 - 從幾個方面來考慮，最重要的「動因」是什麼，關鍵的需要是什麼，關鍵的設計要素是哪幾個。當然，做到這一點需要很強的理**底，也需要很豐富的經驗，這樣 你拿出來的top3, top5才有說服力，才是真正的top3/top5.
2 深入淺出的展現溝通
忘記了在**有個說法：把書看厚難，再把書看薄更難。理解起來是說，看很多很多書、掌握很多很多知識很難，可是能夠把很多很多知識再融匯貫通、抽象成為言 簡意賅的、深入淺出的「濃縮版」知識更難。為什麼一定要架構師具備這樣的本領？ 架構師需要很多溝通：其中最重要的溝通是向上，與管理層溝通，向管理層報告方案的要點，獲取管理層的理解、支援和批准。一般來說，管理層並不懂技術，至少 不精通技術，也不關心技術的細節（因為他的任務是業務，不對嗎？it is a business，支援的也是業務）。
3 廣博的知識面
架構師不是美術師（把建築圖紙畫的很漂亮），架構師也不是力學家或材料學家。他精通主要技術，熟悉業界的最新動向，為我所用，甚至進而形成自己的設計風格 和vision，然後說服管理層和團隊成員。這是架構師（architect）和某個專項專家（sme, subject matter expert）的區別。
4 面向業務的成本概念
企業的it技術不同於科學研究，技術永遠都不能脫離成本來討論，這就是你不能問賓士和賽歐孰好孰壞的原因。出色的架構師擁有很強的成本概念，熟悉不同的技 術方案的成本屬性，了解不同的業務需求對於成本的基本限制。所以，出色的架構師可以向管理層和使用者提供「適用」的、」secure and reliable」 的技術方案。
每個好架構師都是一位出色的程式設計師
在這個過程中，乙個架構師至少有一半以上的工作是需要與開發團隊一起進行的。按照randy的描述，這是 乙個架構師不能將實施細節拋之腦後 的體現。而且與開發團隊一起工作，命令式的領導方式並不被推崇，乙個架構師必須通過自己的個人影響力來對開發團隊進行指導工作。而什麼是影響力？說的直白一些，就是通過自己寫 ...
每個好架構師都是一位出色的程式設計師
架構師，聽起來是如此神秘的乙個稱號。尤其是在開發領域剛入門不久的菜鳥級程式設計師眼中，架構師都是高手，都是牛人，都是如此高高在上的存在。51cto開發頻道年終鉅獻 架構師最怕程式設計師知道的十件事 不過，在搞了 四 五年程式設計之後，程式設計師們往往早已失去了當年對這些 高階 職位的神秘感，甚至會對...
每個好架構師都是一位出色的程式設計師
乙個優秀的軟體架構師，首先一定是乙個出色的程式設計師，這是本篇文章的議題。從本文我們可以了解到乙個架構師的工作是什麼，他容易遇到的問題是什麼，因此他為什麼必須是乙個出色的程式設計師。架構師，聽起來是如此神秘的乙個稱號。尤其是在開發領域剛入門不久的菜鳥級程式設計師眼中，架構師都是高手，都是牛人，都是如...