一個優秀的軟件架構師，首先一定是一個出色的程序員，這是本篇文章的議題。從本文我們可以了解到一個架構師的工作是什么，他容易遇到的問題是什么，因此他為什么必須是一個出色的程序員。

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

51CTO開發頻道年終巨獻:架構師最怕程序員知道的十件事

不過，在搞了四、五年編程之后，程序員們往往早已失去了當年對這些“高級”職位的神秘感，甚至會對自己所在項目的架構師抱怨不已，背后里稱他們是一群水王。所以有江南白衣曾撰文述說：“國內的架構師到了三十歲以后很多就往理論上跑，而國外的架構師在往上發展的同時保持下面的編程體驗，所以國內多水王，而國外則多大師。”

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

 

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

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

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

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