本系列前序文章索引：

1. 程式設計師為什麼必須要懂架構？
2. 架構到底是什麼，你知道嗎？
3. 架構都有哪些，我該怎麼選？
4. 架構師都幹什麼，你知道嗎？

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

提示：限於版面，如需高清圖，請先關注 「 IT老兵哥 」，再發私信告知郵箱，謝謝！

• 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老兵哥 」，賦能程式人生！

• 軟技能-熱門文章：（首發公眾號）

1. 如何在打造影響力的路上「碼」不停？（新）
2. 2020 來了，你的 2019 晒好封存了嗎？（新）
3. “花式”裁員套路深，你知道嗎？
4. 遭遇裁員，如何渡過心理危機？
5. 程式設計師“求包養”攻略揭祕

• 硬技能-熱門文章：

1. 如何設計出優美的Web API？（熱）
2. 程式設計師必須掌握的效能調優 X Y Z （熱）
3. 如何把單體式應用拆解成微服務？【上】
4. 如何把單體式應用拆解成微服務？【下】
5. 圖解 Spring：HTTP 請求的處理流程與機制【1】