怎么成為一個軟件架構師
的確沒想到隨手寫的東西有那么多的回復，不管怎樣還是挺高興的。在這里謝謝大家的關注了。其實做了這么多年的技術腦子里總會跳出很多的想法，但很少有時間靜下來仔細地思考思考，寫寫博客也算是一種自我歸納和總結吧。
“軟件架構師”這個名詞也不知是什么時候進入我的腦中的，不過一直就很疑惑，總覺得和軟件的Team Leader之間有些糾纏不清。不過以我的觀點來看，軟件架構師除了沒有行政上的職責以外，與Team Leader也并無二致了，也就是一個軟件團隊的核心設計者和決策人。作為一個軟件團隊的領頭人，架構師應該具備哪些能力、素質和經驗呢?
我可以把一個軟件研發工作者的從業經歷大致劃分為3個階段
第一階段是新手期
這個階段的典型特征是容易被新技術的華麗外表所迷惑。當在網上看到一種新技術的介紹或者心得，立即產生了大量腎上腺素的分泌，干什么都想用一用，如果這時有人跟他說你的這項工作用這個不合適的話，要是性子急的人估計就直接開始罵娘了，性子緩些的也會想盡理由說服你使用這個新東西，實在沒辦法的話，吃不下東西睡不著覺也想另找個地方用一下。
新手時期的程序員對需求和應用環境的掌控能力還不強，但卻往往信心爆棚地認為自己寫的代碼有多么優雅高效。當問題出現時，大多數人的反應就是：“怎么可能!在我的機器上運行的好好的!”。不管看了多少書，學習了多么高效的算法，實際的工作中需求和環境始終是變化萬端的。其實我也很不明白為什么那么多的技術類書籍往往都帶有或多或少的炒作成份，往往夸大某方面的優勢，而對缺點卻往往一帶而過，同時，相對思想算法講解、技術介紹類的書籍，針對具體項目研發實例進行技術選型講解的書真的少之又少，或許這也從側面反應了寫書人很多，真正做研究的卻很少吧。
新手期程序員的不成熟還體現在團隊表現上，當一個問題提交給新手，當跟蹤別人的代碼段時，經常會丟手不管，還理直氣壯地說“我這塊沒問題”，殊不知問題都沒有查清楚，你又怎知不是你的問題呢?在團隊研發中，我一向堅持入口點解決問題的原則，只要問題的入口點在你這里，就必須全程跟蹤查到底，問題查出來了，再通知相關人員進行程序修正。團隊的程序員雖然分工不同，但每個人必須對他人的程序和算法有清楚的認識和了解，因為大家是在同一個環境下工作，雖然代碼有分工，可是操縱的卻是相同的設備和資源。獨善其身在團隊開發中是最要不得的想法。
第二階段是中級程序員階段
這個階段的程序員對技術、和工具的選擇已經審慎了很多，可以根據具體的需求來選擇需要采用的技術，可以寫出詳細的需求調研報告并提出設計方案，優點、缺點分析得清晰明了。在應用層面也有較強的全局理解力，在團隊中也具有相當的協作能力，因此具備較強的解決問題的能力。
中期的程序員雖然在應用層面上已經相當嚴謹，但在系統層面的掌控力卻并不強。應用系統也并非獨善其身，她和網絡環境、使用方法、硬件環境、操作系統、地點、時間等等諸多因素有著千絲萬縷的聯系。在少量用戶的中底端研發中，如越來越多的呈幾何級數增長的信息管理系統中，系統掌控力并非必須的能力。但在一個高端高并發量，被大量應用于不同環境的軟件產品，系統掌控力就是不可或缺的能力。這種能力我認為大部分取決于知識面，工作越多，經驗越豐富，就越能對不同的應用環境有著敏銳地感覺和判斷。
大多數中階段程序員限于行業，對語言的依賴還是很強，比如搞信息系統的和搞單片機的、搞網絡、路由器交換機的，由于系統層面不同，專精和對語言的理解都不甚相同。
第三階段是高級程序員/分析師/架構師階段
進入這個階段的前提是多年的工作經驗，廣闊的知識面和對系統底層到高層的全面認識，已經使其進入了無語言無工具的層次。也就是能任何清楚地感知每種編程語言的優劣、使用范圍、編碼禁忌，對一個大型工程能有最全面的了解，在選擇語言和確定技術方案的時候不會被自己對語言或技術工具的偏好(或者根本已經無所偏好)所影響，真正明白了其實別管是神馬語言、神馬技術，歸根到底咱們的對象還不是CPU、內存、硬盤和網絡，該做的事情一件都不能少，所謂的技術框架是對初級程序員用的，真正高級了不研究個清楚透徹都不敢讓你進來。即使對同一種語言，在不同的操作系統中，如Visual C++和Unix C、AIX XLC、GNU G++等等的區別，以及不同版本之間的區別也了如指掌。這個階段很難達到是由于對操作系統層面的清晰了解，相信一個初級程序員一路走來，大部分工作都是在Team Leader的規范和引導下完成的，每人都必須做好自己的工作，雖然在應用層面必須顧全大局，但系統層面的問題相對就難以接觸了。如果不是對技術有著強烈的渴求和一定的綜合能力，系統層面的工作經驗將很難與你有緣。這就好比一個當外科醫生的，其實做手術并不像很多人想象中那樣難，一般看個幾次，基本上也就差不多了，如果得到機會實際操作一下，不單是可以積累大量的經驗，自信心方面的收獲也是無法估量的。但是，動手術責任重大，機會不是人人都有的。技術工作者其實還是很幸福的，畢竟工作經驗的取得相對于當醫生還是容易的多。
高級階段一定需要有團隊的開發和管理經驗，一個軟件團隊好比一個樂隊，每個人對曲目的理解都不同，雖然司職不同的樂器，沒有指揮家也會弄得一團糟。軟件團隊的每個人對語言、業務、能力的理解都不一樣，交流方式也有別，同時他們操作著相同的系統和資源，如果Team Leader不做好規劃，后果肯定可想而知。豐富的經驗和敏銳的觸覺神經足以判斷出團隊成員的編碼風格和技術選擇偏好，能以足夠的經驗和理由說服其拋棄自己的感情偏好，從而很好地完成自己的工作。這種能力有點類似于行政的管理，但實際上卻是有明顯的不同的，這種管理基于的是實際的豐富經驗和充足的理由，絕對不可以將行政管理中的排隊觀念帶入，如果2個人意見相左，就必須爭論，爭不下去了回家想清楚理由再爭，甚至直到時間來證明一切，不能說這次你聽我的，下次我聽你的，技術工作是絕對的，最好的、最適合需求的方案永遠只有一個，如果你覺得“都可以”，只能說對行業和需求還沒有吃透。
高級程序員是經常會對需求說“No”的人，對行業的深入認識和對系統及應用全局的把握能力使他具有真正指導用戶的能力，規范用戶的工作、思想并用計算機這個工具真正對行業產生引領作用。高級架構師能深入認識管理和技術的關系，管理上出現的問題一定要在管理上解決，工作經驗不多的用戶或者程序員往往會把管理上產生的問題拋給軟件系統，導致系統越來越復雜，維護成本迅速增長，而管理上的問題卻依然存在。但有一個現狀是，往往用戶提需求都直接提給負責程序的程序員，小公司估計直接就和程序員聯系了，大點的也由一個其實并不怎么懂技術的所謂“客戶經理”協調轉發，而并非經過設計師和架構師的同意，因為他們可能現在已經在研發別的項目了。那么用戶的需求是否合理，是否符合當初設計的初衷，往往初級的程序員并不知曉或有不同理解和偏好。雖然這也是實際情況所限，很難做的更好，但這也造成了很多系統的持續發展力很低，而許多用戶也處于信息不對等的弱勢地位，也只好將就算了。
最后，技術和社會是緊密聯系在一起的。社會的進步發展決定了需求和技術的發展，一個對技術發展有著敏銳感覺的架構師必須對社會有著深刻的認識。一個良好的團隊必須有新老交替才能不斷進步，老人要舍得帶新人。“要讓一部分人先富起來，然后先富的帶動后富的，最終達到共同富裕。”這是我們上學時學到的話吧，不過要是先富的盡想著向前看，根本沒把后富的放在眼里，那這個團隊也好、社會也好，也就沒多大的持續發展力了。其實我倒是認為現在真正的大富豪還是有不少知民間疾苦的，頂層的和基層的都還能了解屁民們的生活，不了解的是中間層，他們整天生活在富庶小康的溫床，經常會提及一些好高騖遠、不切實際的想法，而對那些為底層人民謀福利的事情嗤之以鼻，甚至諷刺為“用先進的技術做愚蠢的事情”，目的僅僅是為了嘩眾取寵和彰顯自己的遠見卓識。
先寫到這里了，其實我自己也在為成為一個真正的架構師而奮斗，一家之言，難免有所偏差，不過還是那句話，“我們一直在努力”。
原文鏈接：http://blog.csdn.net/chui88/archive/2011/04.aspx
【編輯推薦】
