作者：程式設計小丫

來源：CSDN部落格

序：的確沒想到隨手寫的東西有那麼多的回覆，不管怎樣還是挺高興的。在這裡謝謝大家的關注了。其實做了這麼多年的技術腦子裡總會跳出很多的想法，但很少有時間靜下來仔細地思考思考，寫寫部落格也算是一種自我歸納和總結吧。

 “軟體架構師”這個名詞也不知是什麼時候進入我的腦中的，不過一直就很疑惑，總覺得和軟體的Team Leader之間有些糾纏不清。不過以我的觀點來看，軟體架構師除了沒有行政上的職責以外，與Team Leader也並無二致了，也就是一個軟體團隊的核心設計者和決策人。

我可以把一個軟體研發工作者的從業經歷大致劃分為3個階段

第一階段是新手期

這個階段的典型特徵是容易被新技術的華麗外表所迷惑。當在網上看到一種新技術的介紹或者心得，立即產生了大量腎上腺素的分泌，幹什麼都想用一用，如果這時有人跟他說你的這項工作用這個不合適的話，要是性子急的人估計就直接開始罵娘了，性子緩些的也會想盡理由說服你使用這個新東西，實在沒辦法的話，吃不下東西睡不著覺也想另找個地方用一下。

新手時期的程式設計師對需求和應用環境的掌控能力還不強，但卻往往信心爆棚地認為自己寫的程式碼有多麼優雅高效。當問題出現時，大多數人的反應就是：“怎麼可能！在我的機器上執行的好好的！”。不管看了多少書，學習了多麼高效的演算法，實際的工作中需求和環境始終是變化萬端的。其實我也很不明白為什麼那麼多的技術類書籍往往都帶有或多或少的炒作成份，往往誇大某方面的優勢，而對缺點卻往往一帶而過，同時，相對思想演算法講解、技術介紹類的書籍，針對具體專案研發例項進行技術選型講解的書真的少之又少，或許這也從側面反應了寫書人很多，真正做研究的卻很少吧。

新手期程式設計師的不成熟還體現在團隊表現上，當一個問題提交給新手，當跟蹤別人的程式碼段時，經常會丟手不管，還理直氣壯地說“我這塊沒問題”，殊不知問題都沒有查清楚，你又怎知不是你的問題呢？在團隊研發中，我一向堅持入口點解決問題的原則，只要問題的入口點在你這裡，就必須全程跟蹤查到底，問題查出來了，再通知相關人員進行程式修正。團隊的程式設計師雖然分工不同，但每個人必須對他人的程式和演算法有清楚的認識和了解，因為大家是在同一個環境下工作，雖然程式碼有分工，可是操縱的卻是相同的裝置和資源。獨善其身在團隊開發中是最要不得的想法。

第二階段是中級程式設計師階段

這個階段的程式設計師對技術、和工具的選擇已經審慎了很多，可以根據具體的需求來選擇需要採用的技術，可以寫出詳細的需求調研報告並提出設計方案，優點、缺點分析得清晰明瞭。在應用層面也有較強的全域性理解力，在團隊中也具有相當的協作能力，因此具備較強的解決問題的能力。

中期的程式設計師雖然在應用層面上已經相當嚴謹，但在系統層面的掌控力卻並不強。應用系統也並非獨善其身，她和網路環境、使用方法、硬體環境、作業系統、地點、時間等等諸多因素有著千絲萬縷的聯絡。在少量使用者的中底端研發中，如越來越多的呈幾何級數增長的資訊管理系統中，系統掌控力並非必須的能力。但在一個高階高併發量，被大量應用於不同環境的軟體產品，系統掌控力就是不可或缺的能力。這種能力我認為大部分取決於知識面，工作越多，經驗越豐富，就越能對不同的應用環境有著敏銳地感覺和判斷。

大多數中階段程式設計師限於行業，對語言的依賴還是很強，比如搞資訊系統的和搞微控制器的、搞網路、路由器交換機的，由於系統層面不同，專精和對語言的理解都不甚相同。

第三階段是高階程式設計師/分析師/架構師階段

進入這個階段的前提是多年的工作經驗，廣闊的知識面和對系統底層到高層的全面認識，已經使其進入了無語言無工具的層次。也就是能任何清楚地感知每種程式語言的優劣、使用範圍、編碼禁忌，對一個大型工程能有最全面的瞭解，在選擇語言和確定技術方案的時候不會被自己對語言或技術工具的偏好（或者根本已經無所偏好）所影響，真正明白了其實別管是神馬語言、神馬技術，歸根到底咱們的物件還不是CPU、記憶體、硬碟和網路，該做的事情一件都不能少，所謂的技術框架是對初級程式設計師用的，真正高階了不研究個清楚透徹都不敢讓你進來。即使對同一種語言，在不同的作業系統中，如Visual C++和Unix C、AIX XLC、GNU G++等等的區別，以及不同版本之間的區別也瞭如指掌。

這個階段很難達到是由於對作業系統層面的清晰瞭解，相信一個初級程式設計師一路走來，大部分工作都是在Team Leader的規範和引導下完成的，每人都必須做好自己的工作，雖然在應用層面必須顧全大局，但系統層面的問題相對就難以接觸了。如果不是對技術有著強烈的渴求和一定的綜合能力，系統層面的工作經驗將很難與你有緣。這就好比一個當外科醫生的，其實做手術並不像很多人想象中那樣難，一般看個幾次，基本上也就差不多了，如果得到機會實際操作一下，不單是可以積累大量的經驗，自信心方面的收穫也是無法估量的。但是，動手術責任重大，機會不是人人都有的。技術工作者其實還是很幸福的，畢竟工作經驗的取得相對於當醫生還是容易的多。

高階階段一定需要有團隊的開發和管理經驗，一個軟體團隊好比一個樂隊，每個人對曲目的理解都不同，雖然司職不同的樂器，沒有指揮家也會弄得一團糟。軟體團隊的每個人對語言、業務、能力的理解都不一樣，交流方式也有別，同時他們操作著相同的系統和資源，如果Team Leader不做好規劃，後果肯定可想而知。豐富的經驗和敏銳的觸覺神經足以判斷出團隊成員的編碼風格和技術選擇偏好，能以足夠的經驗和理由說服其拋棄自己的感情偏好，從而很好地完成自己的工作。

這種能力有點類似於行政的管理，但實際上卻是有明顯的不同的，這種管理基於的是實際的豐富經驗和充足的理由，絕對不可以將行政管理中的排隊觀念帶入，如果2個人意見相左，就必須爭論，爭不下去了回家想清楚理由再爭，甚至直到時間來證明一切，不能說這次你聽我的，下次我聽你的，技術工作是絕對的，最好的、最適合需求的方案永遠只有一個，如果你覺得“都可以”，只能說對行業和需求還沒有吃透。

高階程式設計師是經常會對需求說“No”的人，對行業的深入認識和對系統及應用全域性的把握能力使他具有真正指導使用者的能力，規範使用者的工作、思想並用計算機這個工具真正對行業產生引領作用。高階架構師能深入認識管理和技術的關係，管理上出現的問題一定要在管理上解決，工作經驗不多的使用者或者程式設計師往往會把管理上產生的問題拋給軟體系統，導致系統越來越複雜，維護成本迅速增長，而管理上的問題卻依然存在。

但有一個現狀是，往往使用者提需求都直接提給負責程式的程式設計師，小公司估計直接就和程式設計師聯絡了，大點的也由一個其實並不怎麼懂技術的所謂“客戶經理”協調轉發，而並非經過設計師和架構師的同意，因為他們可能現在已經在研發別的專案了。那麼使用者的需求是否合理，是否符合當初設計的初衷，往往初級的程式設計師並不知曉或有不同理解和偏好。雖然這也是實際情況所限，很難做的更好，但這也造成了很多系統的持續發展力很低，而許多使用者也處於資訊不對等的弱勢地位，也只好將就算了。

總結

最後，技術和社會是緊密聯絡在一起的。社會的進步發展決定了需求和技術的發展，一個對技術發展有著敏銳感覺的架構師必須對社會有著深刻的認識。一個良好的團隊必須有新老交替才能不斷進步，老人要捨得帶新人。“要讓一部分人先富起來，然後先富的帶動後富的，最終達到共同富裕。”這是我們上學時學到的話吧，不過要是先富的儘想著向前看，根本沒把後富的放在眼裡，那這個團隊也好、社會也好，也就沒多大的持續發展力了。

其實我倒是認為現在真正的大富豪還是有不少知民間疾苦的，頂層的和基層的都還能瞭解屁民們的生活，不瞭解的是中間層，他們整天生活在富庶小康的溫床，經常會提及一些好高騖遠、不切實際的想法，而對那些為底層人民謀福利的事情嗤之以鼻，甚至諷刺為“用先進的技術做愚蠢的事情”，目的僅僅是為了譁眾取寵和彰顯自己的遠見卓識。

先寫到這裡了，其實我自己也在為成為一個真正的架構師而奮鬥，一家之言，難免有所偏差，不過還是那句話，“我們一直在努力”。

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

-END-