程式員，練就哪些技能才勝任架構師？

架構師，我們程式員打怪升級的主要方向，它不像某些技能報個培訓班就能獲得。勝任架構工作需要具備許多技能，既有硬技能還有軟技能。俗話說：一口吃不成胖子。從程式員到架構師也無法一蹴而就，它是一個循序漸進、穩步提升的進階過程，每個階段都有每個階段要掌握的技能，多項技能之間還存在先後順序。如果想儘快轉型升級至... ...

本系列前序文章索引：

架構師，我們程式員打怪升級的主要方向，它不像某些技能報個培訓班就能獲得。勝任架構工作需要具備許多技能，既有硬技能還有軟技能。俗話說：一口吃不成胖子。從程式員到架構師也無法一蹴而就，它是一個循序漸進、穩步提升的進階過程，每個階段都有每個階段要掌握的技能，多項技能之間還存在先後順序。如果想儘快轉型升級至架構師，那你必須在日常工作中有意識地儲備這些技能，接下來老兵哥結合親身經歷來分享一下：

架構師之硬技能

1. 硬技能

不像產品、管理等條線更加倚重通用技能，從技術條線轉產品或管理，入門相對容易一些。但從產品或管理很難轉型至架構，架構師必須從開發測試崗做起，在工作中不斷提升專業技能和積累實踐經驗，從一個模塊開始，到一個子系統，再到整個系統，最後到多個系統，這是一個循序漸進提升硬技能的過程，也可以看成構建架構師硬技能“點線面”。

1.1 點

老兵哥我剛入行時的崗位就是開發工程師，跟其他幾個畢業生一起被安排在自動化測試平臺項目組，整個系統由部門資深同事設計的，我們分別負責開發其中某個子系統的幾個模塊。這個階段我主要關註函數、類和模塊這個粒度，為了做好工作我要鑽研編程語言 C/C++，以及熟悉 Visual C++ MFC、Socket 等代碼庫的使用。每周我們還會舉行代碼評審會議，邀請同事點評自己寫的代碼，那時候的自己年輕氣盛，不管收到正面或負面的評價都會極大地激勵自己。經過這個階段的歷練，我的編程技能得以較大的提升，也養成了較規範的編碼習慣，掌握瞭如何設計好一個函數、類和模塊。

這個項目前後做了兩年左右時間，後面半年還做了些系統推廣培訓相關的事情。隨後，我們又啟動了採用腳本語言 Python 作為自動化測試腳本的自動化測試腳本，在這個項目我負責預研 Python 腳本解釋引擎和開發測試代理子系統，這段項目經歷讓我躍升到子系統這個粒度。我需要考慮這個子系統在整個系統當中需要承擔什麼職責，以及跟其他子系統或被測系統之間的交互機制。同時，我還要負責這個子系統設計，確定它由哪些模塊構成、每個模塊內部包含哪些類等。

這個階段讓我具備了構建單個子系統的能力和信心，在後面的工作當中我還使用不同類型的編程語言構建過許許多多不同類型的子系統，但其實都是在強化構建單個點的能力，關聯技能樹包括：操作系統、編程語言、應用容器、開發框架、多線程等。

1.2 線

對於稍具規模的系統，它都免不了要劃分成幾個子系統，子系統之間或者與外部系統之間就需要連接通信，這相當於把兩個孤立的點連接起來，即連點成線。這個過程跟開發單個子系統所需要的技能有所不同，它需要網路編程相關的知識技能。在老兵哥我剛參加工作的那些年，Web 應用還沒有成為主流的應用形態，瀏覽器/伺服器（B/S）架構還沒有興起，HTTP 協議尚未被廣泛使用，當時最流行的就是客戶端/伺服器（C/S）架構，IP/TCP 才是最主要的通信協議，我就是在這個階段積累下網路編程相關知識技能的。

最早我們要開發客戶端或伺服器程式，就需要熟悉掌握 Socket 網路編程，包括綁定監聽埠、接受連接請求、併發處理請求等，從無到有全部自己編寫，這些經驗對於我後來理解網路通信機制有非常大幫助。為了滿足子系統之間的交互需求，我們要基於 IP/TCP 協議來定製專門的應用層協議，包括制定報文頭和報文體兩層結構，雖然比 HTTP、FTP、SMTP等協議要簡單，但這段經歷讓我對 HTTP 這類應用層協議的實現原理有了深刻的理解。另外，我們還要考慮報文內容過長時的分包組包、網路發生異常時的丟包重發，以及報文內容的編解碼等。

因此，有志於在技術線發展的程式員都有必要補上這塊技能。在近十五年的技術從業生涯中，老兵哥我前前後後解決過無數現網問題，其中有許多複雜的問題都跟系統交互通信有關，藉助各種網路抓包分析工具抽絲剝繭，最後定位問題的根源都是沒有正確使用網路協議，所以我很慶幸自己在過往的工作中有這段經歷。

隨著互聯網的蓬勃發展，Web 應用成了最主要的應用形態，與此同時 HTTP 這種更人性化的網路通信協議成了最受歡迎的交互協議。從開發客戶端/伺服器（C/S）應用轉到開發瀏覽器/伺服器（B/S）應用的過程中，老兵哥我專門花時間學習了 HTTP 協議，瞭解其運行原理和控制機制，尤其是協議頭中每個欄位作用，包括請求方法、編碼格式、超時機制、緩存機制等。印象最深刻的就是 Roy Thomas Fielding 博士發表了 REST 的論文《Architectural Styles and the Design of Network-based Software Architectures》，即《架構風格與基於網路的軟體架構設計》，讓我對 HTTP 有了全新的認知，這些知識技能對於理解掌握雲計算時代的服務化架構非常有幫助。

除了 IP/TCP、HTTP 這兩類協議之外，老兵哥我覺得還需要掌握消息隊列（Message Queue）相關的協議，這類型協議更適合構建事件驅動架構的系統，不僅僅支持同步還支持非同步。我曾經負責一個移動互聯網的系統，其中有個子系統負責維護各種手機終端型號和設備信息，合作伙伴需要從這個子系統及時地獲取最新信息，最初我們用 HTTP 協議輪詢拉取的方式實現，但隨著合作伙伴數量和信息更新頻次的增加，這種信息同步機制就遭遇瓶頸了，後來我們通過引入消息隊列中間件優雅地化解這個問題。

1.3 面

從點、線開始修煉，隨著連線越來越多，最終將會形成平面，即分散式系統，這是我們程式員通往架構師路上必然經過的站點。剛開始我們僅僅利用互聯網來發佈搜索信息，接著我們的即時通信和社交也搬到了網上，再後來購物差旅等事情也可以通過互聯網來完成了，現在跟我們衣食住行相關的所有事物都開始被互聯網化了，這相當於虛擬世界被構建的越來越龐大越複雜。原先我們開發的軟體系統複雜度還是有限的，它本身頂多被劃分成幾個子系統，需要關聯交互的外部系統數量也非常有限。但隨著業務越來越豐富，單個系統的複雜度也急劇增長，與之關聯的外部系統也非常多，逐漸演變成一張縱橫交錯的網，也就是我們所說的“面”。如何在這樣複雜的網路當中維護好複雜度，以及確保系統依舊滿足易用性、性能、可靠性、穩定性、安全性等質量屬性，這就需要程式員修煉分散式系統相關的技能。

老兵哥我在從事移動互聯網相關係統研發的過程中遇到了更高複雜的場景，當時我們要構建一個蘋果應用商店類似的生態體系，我們負責的系統本身由六七個子系統組成，它還需要跟許多上下游合作伙伴的系統對接交互。如果跟每個外部系統的對接都採用各自不同的標準，隨著接入系統的數量越來越多，那對接相關的複雜度最終走向失控。另外，像應用訂閱購買等典型業務場景都需要多個系統協作完成，其中涉及到分散式事務，怎樣保證數據一致就是很大的挑戰。按照常規邏輯，隨著系統的複雜度不斷提升，那麼系統出現問題宕機的概率就會提升，但對於用戶來說，他們依舊希望系統可以提供 7*24 小時的服務，不要出現服務超時或失效等異常情況，這就是“面”帶來的挑戰。

從那個階段開始，我有了學習和實踐分散式架構的機會。最早就是面向服務架構 SOA，即 Web Service、SOAP 等技術標準，站在現在回看那時候，這套技術棧是偏重偏繁瑣的，但當時分散式系統對於整個業界都是全新的挑戰，這套解決方案是由 Compaq、HP、IBM、Lotus、Microsoft、SAP 這些傳統軟體巨頭們提出的。它通過 Web 服務描述語言 WSDL 來標準化分散式系統中的每個服務，再通過簡單對象訪問協議 SOAP 來規範服務之間的交互，從某個角度來看，越大規模的協作必須依賴統一的標準和規範。

但傳統軟體巨頭很少有在互聯網第一線實踐的經驗，不像 BAT 他們對互聯網分散式系統的挑戰有那麼真切的感受，阿裡巴巴就在實踐中孵化出了比 Web Service、SOAP 更加輕量化的 Dubbo，它也是依托面向服務架構 SOA 這套理論，只是是線上更加接地氣。這段工作經歷讓我對分散式架構有了體系化的認知，雖然近些年分散式技術從面向服務架構 SOA 演進至微服務架構 MicroService，技術中間件從 Dubbo 更替為 Spring Cloud，但我依然可以套用這套知識體系去理解新技術。

2. 軟技能

軟硬技能到底是怎麼區分呢？老兵哥我覺得一個人靠哪門手藝吃飯，那麼這門手藝相關的技能就是硬技能，而輔助硬技能產生更大價值的技能就是軟技能，這跟“T”字型人才的要求類似，既要求有足夠精湛拔尖的主攻技藝，也要有各式各樣的綜合技能。硬技能很重要，這點我相信沒有人會反對，但也有不少人意識不到軟技能的重要性。對技術人來說，從開發到架構，從架構到 CTO，或者從開發轉產品或管理，不管是晉升還是轉型，我們都是在加強硬技能的同時提升軟技能的比重，甚至原先的硬技能變成了軟技能，而原先輔助作用的軟技能卻成了硬技能。接下來，我將結合個人從開發轉型架構的經歷來談一談哪些軟技能很重要：

溝通：相對於開發工程師，架構師的工作職責決定了他需要對接更多上下游客戶，對溝通技能的要求就要高很多，畢竟不同角色的思維模式和立場角度各不相同，架構師必須懂得採用不同方式跟這些角色溝通互動，換位思考，從而挖掘到真實的需求，然後利用專業技能平衡好各方需求，最終輸出各方都滿意的架構方案。
寫作：做開發崗時，我的主要輸出就是代碼。雖然偶爾也要寫一些技術文檔，但通常是供自己看的技術文檔或者湊數用的產品操作使用說明。在轉型做架構之後，我寫代碼的比重降低了，為了讓各個干係人理解認可我的架構方案，除了口頭說明之外，最主要就是靠技術寫作，寫給他人看的文檔跟純粹記錄的完全不同。
設計：不管是口頭溝通還是文檔傳播，語文或文字功底再好，也抵不過搭配上設計圖例，圖例中包含的信息是多個維度的，也更加直觀易懂。通常，我習慣在寫技術文檔之前先把設計圖畫出來，畫設計圖的過程就是理順思路的過程，在此基礎上再來組織文字或語言變得更加簡單容易，相當於是看圖說話了。
演講：權力和非職權影響力，架構師開展工作主要依賴於非職權影響力。架構師跟各個干係人之間不存在上下級關係，要讓團隊及合作伙伴認可並執行你的架構方案，你必須要靠自己的專業能力讓對方信服。在以往學校教育或成長過程中，我本身是缺乏這方面的積累的，為了成功轉型架構師我刻意訓練提升自己這方面的能力。

總結起來說，為了在架構師這個新平臺上做好工作，我們需要提升自己輸入、設計和輸出等方面的能力。以往我們從外界獲取信息主要靠閱讀文檔，現在還要加強立體多方位的溝通。在輸出方面，以往我們的輸出形式太過單一，現在我們要掌握文字、演講等多媒體方式。當然，最核心的還是架構設計的專業技能，這個輸入輸出的中心。

3. 知識體系

今天先分享到這裡，老兵哥後續還會分享程式員到架構師的進階指南等，包括每個階段需要掌握的軟硬技能圖譜（如題圖所示），文字提綱可以參考文章《從程式員到架構師，有捷徑嗎？》。如果你對這個主題感興趣，千萬要記得先關註哦！堅持原創不易，如果你覺得有價值，麻煩動動手指點下文「推薦」按鈕，讓更多小伙伴可以看到，老兵哥會更有動力堅持分享的。另外，我後續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎關註本專欄或歪信公主號「 IT老兵哥」！

微信公眾號「 IT老兵哥」