幾年前，我被問到“你是如何變成一名架構師的？”。基于這個話題，我們討論了很多，比如必要的技術、經驗以及所需要的知識儲備等。這一次討論促使我開始思考要成為一名架構師應該具備和學習的東西有哪些，成為一個優秀的架構師應該具備哪些能力和做哪些事情。為此我查閱資料，走訪各位大佬，當然也結合自己的經歷，最終我輸出了今天這樣一篇文章，希望通過閱讀此文，你可以從此知道自己的架構師之路該怎么走。

什么是架構師？

在開始具體的細節之前，我們先來理清兩個定義。

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect.

軟件架構師是一個軟件專家，他（她）負責做出高階設計選擇和輸出技術標準，包括軟件編碼標準、工具和平臺（框架）。首席專家（leading expert）也被稱為首席架構師（chief architect）。

(來源: Wikipedia: Software Architect)

Software architecture is the fundamental organization of a system, represented by its components, their relationships to each other and to the environment, and the principles that determine the design and evolution of the system.

軟件架構是一個系統的基本（基礎）組織。包含組件，他們之間的關系以及與周邊的關系，設計原則，以及系統演進。

(來源: Handbook of Software Architecture)

架構的級別

架構可以被抽象為幾個級別（level）。級別決定了要選擇哪些對應的技術。市面上有多種分類方式，我個人喜歡把它分為三個級別：

應用級別（Application Level） : 架構最下層級別（lowest level）。只關注一個單一的應用。非常的關注細節，關注底層設計（ Very detailed, low level design）。溝通往往只限于開發團隊內部。
解決方案級別（Solution Level） : 架構的中間級別（mid-level）。關注的是一個或多個應用，從而滿足某個業務需求 (業務解決方案)。有點高，但主要還是 low-level 設計。溝通跨多個開發團隊。
企業級別（Enterprise Level） : 架構最高級別。關注多個解決方案（solution）。高級（High level）, 抽象設計（abstract design）, 需要總覽全局，總覽多個解決方案和多個應用架構師。溝通橫跨整個組織。

有時候，架構師是也被戲稱為“膠水（粘合劑）”，不同利益相關者之間的膠水，舉三個例子：

水平 : 業務、開發人員或不同開發團隊之間的溝通橋梁。
垂直 : 開發人員和管理人員之間的溝通橋梁。
技術 : 不同技術或項目（產品）之間的集成橋梁。

軟件架構師要做的幾個典型活動：

在搞清楚要使用的技術之前，我們先要明白軟件架構師要做的幾個典型的活動。以下是我梳理的幾個典型的活動：

確定和決定要使用的開發技術和平臺。
定義開發標準。比如，編碼標準，工具，代碼 review 流程，測試方法等。
協助識別和理清業務需求。
設計系統和基于需求做出決策。
記錄和溝通架構定義、設計和決策（Document and communicate architectural definitions, design and decisions）。
檢查和 review 架構和代碼。比如，檢查確定的模式和編碼標準的實現是否合理。
與其他的架構師和利益相關者協作。
開發人員的教練和顧問。
細化并把 high level 的設計具體到 low level 設計。

注意：架構是一個持續的活動，尤其是在敏捷開發團隊中。因此，這些活動得一遍一遍的重復迭代， over and over again。

軟件架構師要掌握的重要技能

為了能夠支撐上面列出的活動，軟件架構師需要一些必備的技能。根據我過往的經歷，以及翻閱資料以及與大佬們進行討論，最后得出了如下軟件架構師必備的 10 個重要技能： 設計，決策，簡化，代碼，文檔，溝通，評估，權衡，顧問，營銷。

接下來我們一個個說。對于每種技能，我都提出了一些行動或見解，你可以根據這些來改進你的工作。

(1) 設計

什么是好的設計？這個可能是一個非常重要同時又要挑戰性的問題。分為理論和實踐。就我的經驗，二者的結合是最有價值的。

知道基礎的設計模式：模式是一個非常重要的工具，是架構師開發可維護系統的重要工具之一。記住，你要想開發出 可維護 的系統，請記得適當地運用設計模式。通過模式你可以重用那些已經被證明可以解決常見問題的設計思路。去看看 GoF（Gang of Four）寫的有關設計模式的書吧，盡管這些模式已經 20 多年了，但依然是現代軟件架構的基礎。比如 Model-View-Controller (MVC) 模式就可以用于多個領域，甚至是一些更新的模式的基礎，比如 MVVM。
對模式和反模式進一步鉆研：如果你已經知道了所有基礎的 GoF 設計模式，接下來可以擴展自己的知識儲備去學習更多的軟件設計模式，或對你感興趣的領域進行垂直鉆研。我個人比較喜歡 Gregor Hohpe 寫的一本書叫：Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions。這本書主要的內容是系統之間的數據交換（應用集成方面）。
知道質量度量（quality measures）：確定和定義架構不是終點。你還需要讓你的系統可維護、可靠、適應性好、安全、可測試、可擴展、可重用等。所有這些都滿足了，才算是一個好的架構。你可以去百科上去看看有關 quality measures 的內容。不過理論固然重要，但實戰同樣重要，甚至更重要。千萬不要變成“象牙塔架構師”（http://www.gitshah.com/2011/01/ivory-tower-architect.html）。
嘗試并了解不同的技術棧：我認為這是非常重要的，如果你想變成一個更好的架構師的話。嘗試去了解新的技術棧，然后學習下這些技術是怎么實現的。不同的新的技術一般是使用不同的設計思路和模式。簡單地去看看 PPT 之類的你可能并不能學到什么，你只有親自去實踐了，才會感受到痛苦和甜蜜。一個架構師不能只是面廣，在某些領域還要扎得深。也許 hold 住所有的技術棧不是最重要的，但你需要在你的某個最重要的領域要有獨到和扎實的見解。同時你也學習一下不屬于你領域的技術，比如你是 JAVA，那么你也要學習一下 JavaScript 等前端語言或技術，反之亦然。
分析和了解框架中應用的設計模式：你可以去研究當前任何開源的或正在使用的框架，比如 Angular. 你可以學習到在實踐中的很多設計模式，比如 Observables。嘗試去搞懂該模式在這個框架中是如何被使用的，為什么它這么做。如果你真的狂熱，也可以看看源碼并且搞懂它是如何實現的。
保持好奇并去參加各種技術聚會：在德國，我們有個 Java User Group (JUG) 組織，這個組織在每個大點的城市都有。我們會討論各種 topic，從 low level 的編碼到上層的有關架構的主題。我真的熱愛這些活動，因為它可以增強你的思維能力和擴大你個人的社交網絡。

(2) 決策（決定）

架構師需要能夠做決定并且引導項目或整個組織朝著正確的方向邁進。

知道什么是重要的：不要浪費時間在那些不重要的決定或活動上，學會認識什么是重要的。目前看來也沒什么書籍教你識別這些。我個人有個原則，每當我要評價一件事是否重要我就會考慮這兩個方面：
(1) 概念完整性（Conceptional Integrity）: 如果你決定以某種方式去做，那么就干，即使有時候會有更優的方案。通常來說，這會使得你有一個直接的全局的概念，使得更容易理解和更容易維護。
(2) 統一性（Uniformity）:比如如果你有名稱的一些約定，當然無論是小寫還是大寫，至少讓每個地方都是用同樣的方式，比較統一。
優先級：有關這方面建議去看一下 Weighted Shortest Job First (WSJF) 模型，這個模型被廣泛用于敏捷軟件開發中。尤其是時間緊迫性（ time criticality ）和降低風險（ risk reduction ）對于評估架構決策優先級至關重要。
知道自己的能力：不要對你不了解的事情做決策和決定。各級干各級的事情，要理清每一層的責任，然后對你所負責的層去做決策。如果有多個架構師，那么你應該遵循目前你所安排的架構級別。作為一個 lower level 架構師，如果對 higher level 的架構不滿意，可以提建議，而不是做決定。此外，我建議始終與同伴一起檢查關鍵決策。
評估多個選項：應該總是給出多種方案，這樣才能進行做出決策和決定。不要只給一個方案，聽著感覺就是你沒有認真工作一樣。另外只有一個方案的時候，也沒法做出一個合理的選擇，因為只有一個方案。另外就是要定義一些指標和標準，通過這個來衡量哪個方案好，哪個方案不好，最好不要去憑感覺。比如：license 花費或成熟度（本文有講到成熟度模型）。這樣才能做出一個更好的決策。

(3) 簡化（化繁為簡）

記住一個解決問題的原則 Occam’s Razor。這個原則告訴你解決問題要簡單。這個原則里有一句話叫：最簡單的那個 solution 往往是最好的。我總結這個原則的核心是：如果你對某個問題有多個假定解決方案，這很有可能就是錯的，或者導致沒必要的復雜的解決方案。多個假定方案應該被簡化到只有一個好的解決方案。別提出來一大堆解決方案，說這個也可以，那個也可以，說明是有問題的。

矯正解決方案：通過對解決方案的矯正，有助于你發現最簡單的那個方案，通過從不同的角度和位置去看，往往會得到不錯的效果。你可以從上到下的想一遍，然后再從下到上的想一遍。如果你有一個數據流（data flow）或流程，那么你可以先從左往右想一遍，然后從右往左想一遍。與此同時問自己一個問題：“在理想的世界里，你的解決方案會發生什么？” 或：“公司或指定人員會做什么？” 這兩個問題會強迫你把解決方案減少到如 Occam’s Razor 建議的那樣。
退一步海闊天空 : 經過了激烈而漫長的討論，通常會得出一個高度復雜的涂鴉。但千萬也永遠都不應將這個視為最終結果。這時候，你需要后退一步：再次查看全局（抽象級別）。回到最初的本心，還是有意義嗎？然后再次在抽象級別上進行遍歷并進行重構。做這一步有時候讓結論更加清晰，而不至于第二天繼續進行方案的討論。至少我的大腦需要一些時間來處理并提出更好，更優雅，更簡單的解決方案。人的腦子是需要時間來思考的。
分解成一個個小問題（Divide and Conquer ）: 簡化問題的一個好辦法就是把問題切分成多個小問題然后挨個解決。這讓我想起了自己小時候打掃院落的場景，看著偌大一個院子，看著就煩，于是我決定把院子劃分成三個小塊，然后一個個去打掃，這讓我的心理負擔減輕了不少。一個個小塊打掃完了，最后再整體查看下整個院子還有沒有邊邊角角的地方需要打掃。總覽一下全局，然后整個院子就打掃完了。再枯燥的生活，都可以發現一些樂趣。
重構并不可恥 : 有時候，你可能一時半會想不到更簡單的方案，你不妨就從一個復雜的方案開始做起，先做著，等到之后再進行重構，這時候再去重新思考解決方案。重構并不可恥，但重構之前要注意一件事情：足夠的自動化測試以確保你所重構的地方的功能正確和滿足利益相關者的需求。學習更多重構的知識，我建議你可以讀讀《重構、改善既有代碼的設計》 “ Refactoring. Improving the Design of Existing Code”，這本書是 Martin Fowler 寫的。

(4) 代碼

即使你是一個企業級別的架構師，就最頂層的那種架構，你依然應該知道開發人員在他們每天的工作中主要做些什么。如果你不能明白某個東西如何實現的，你可能會面臨兩個主要問題：

(1) 開發人員有可能不會接受你說的。

(2) 你也不會明白開發人員要什么和面臨的挑戰。

有個輔助項目（Have a side project） : 跟進一個輔助項目，可以讓你了解到新的技術和工具，以了解到當今和未來的開發方式。Kurt Schneider 寫的 “Experience and Knowledge Management in Software Engineering” （軟件工程中經驗和知識管理）一書中說經驗是所見、情感和假設的結合。看書固然是好事，但這只是書本知識（book knowledge）。只有當你自己嘗試去做事情本身，然后你感受到情感和發生情緒，然后有了對事物好壞的判斷。你使用技術的時間越長越能做出正確的評判。這有助于你在日常的工作中做出正確的判斷。當前有大量的語言和框架，只有你對這些有一定的經驗和了解后才能做出正確的決策，從而引導開發人員朝著正確的方向邁進。還是那句話，記住經驗的定義：所見、情感和假設。要想有經驗就要去動手！
找到正確的事去嘗試：你不可能去嘗試所有事情。這是不可能的。你需要一個更加結構化的方法。有一個來自 ThoughtWorks 不錯的方法是技術雷達（Technology Radar）。他們把技術、工具、平臺、語言和框架分為四類：Adopt，Trial，Assess 和 Hold。 Adopt（采用） 意思是 “強烈的感覺到已經可投入到生產中使用了”， Trial（試用） 意思是 “可以先在某個項目中做嘗試，在這個項目中做到風險可控”， Assess（調研） 意思是“可以探索下對公司有哪些影響”， Hold（保留） 意思是 “謹慎使用”。通過這種分類，更容易獲得新技術的整體情況及其準備情況，以更好地評估下一步要干什么。

(5) 文檔

架構文檔有時候很重要，但有時候又不重要。重要的文檔比如架構決策或編碼指導手冊。編碼開始之前通常需要初始文檔，并且需要不斷完善。其他文檔可以自動生成，因為代碼也可以是文檔，例如 UML 類圖。

Clean Code：代碼是最好的文檔，如果你寫得足夠好。一個好的架構師要有能力分辨出好代碼和爛代碼。著名的書：“ Clean Code ”。
如果可能的話，盡可能自動生成文檔：手動寫文檔的壞處不多說，把 Swagger 和 RAML 或者公司內部開發的文檔系統快點用起來吧。
文檔盡可能少（As much as necessary, as little as possible）：文檔盡量少。無論您需要寫什么文檔（例如決策文檔），都應嘗試一次只關注一件事，并且僅包含關于這件事的必要信息。大量的文檔很難閱讀和理解。附加信息應放在附錄中。特別是對于決策文件，講一個有說服力的故事更為重要而不是僅僅發表大量的論證。而且，這可以為你和你的同事節省很多時間，因為他們要閱讀你的文檔。看看你過去輸出過的一些文檔（源代碼，模型，決策文件等），然后問自己以下問題：“是否包含所有必要的信息才能理解它？”，“確實需要哪些信息？可以省略嗎？”和“文檔中是否有紅線？”。一句話，不要廢話。

(6) 溝通

不多說，溝通很重要。

學習怎么和別人溝通你的觀點：推薦一本書 “UZMO — Thinking With Your Pen” 。作為架構師你經常參會，甚至主持會議，所以你得學會如何和人們溝通你的想法。
通過演講宣貫：一開始你可以向你身邊的朋友表達，然后范圍慢慢擴大，最后向眾多人演講來表述你的觀點。如果你對此感到不適，你需要走出舒適區來加強提高這一點。保持耐心，這個可能需要一些時日。（有時候大佬的一句鼓勵，會讓你釋放掉過往的不自信，開始相信即使最差發揮大家都會感覺到還不錯。）
確定溝通的人群 level：不同的利益相關者有不同的興趣和視角。不同的人群需要單獨的針對某一級別的人群去定向溝通。在溝通之前，請確認你要溝通的人群，比如抽象性、內容、目標、動機等。比如開發人員關注一些解決方案的微小細節，而管理者更傾向怎么省錢。
經常溝通：一個再好的架構沒人知道它的價值依然為零。分發對應級別的架構，然后安排會議與開發者、架構師和管理者分享未來的和已經在踐行的架構。
要透明：定期的溝通只能部分緩解透明度問題。你需要把決策的原因透明化。特別有的人可能沒有參加決策過程的情況下會很難理解決策以及其背后的原因。
隨時準備演講：把常見問題放在一個顯眼（易找到）的地方，隨時應對人們提出的問題，這樣有時候會保護你。

(7) 估算和評估

知道基本的項目管理和原則：作為架構師你經常會被問到如下問題，多久完成？得花多少錢？需要幾個人？用到哪些技術？等。你需要學習一些估算技能。比如敏捷中的估算法等，建議到網上查閱這部分的資料。
評估未知架構（Evaluate “unknown” architecture）：作為一個架構師你也要能夠去評估架構的適用性，針對目前和將來的適用性。這不是一個簡答的事情，但你可以準備一些問題，然后去使用，以下是一些通用的問題：
(1) 設計實踐 :
這個架構用了哪個模式？有沒有被正確的使用？
這個設計遵循紅線（red line）了嗎？這個設計有沒有能夠可持續（uncontrolled growth）？
有沒有一個清晰的結構和各自領域的單獨關注有沒有分布合理？
(2) 開發實踐 :
代碼指引手冊有沒有到位？遵循了嗎？
代碼版本管理怎么做的？有沒有版本化？
部署是怎么分布的？
(3) 質量保障 :
自動化測試覆蓋率怎么樣?
靜態代碼分析有沒有做？分析結果怎么樣？交叉檢查有沒有做？
(4) 安全 :
有哪些安全概念到位？
內置安全？
滲透測試或自動安全分析工具是否到位，經常在用嗎？

(8) 權衡（balance）

質量是有代價的 ：早先我談到過質量和非功能性需求。如果你過度設計架構，則會增加成本，并可能降低開發速度。你需要權衡架構和功能需求。應避免過度設計。
解決矛盾目標：一個典型的矛盾目標的例子就是短期和長期目標。項目往往趨向于構建一個最簡單的方案來解決問題而架構師則具有長期的眼光和愿景。一般情況下，最簡單的方案往往都不能滿足長期目標和愿景。為了避免技術實現步入錯誤的方向，有兩件事情需要考慮：
(1) 開發人員和業務需要明白長期愿景和目標，知道調整成新的解決方案可以帶來好處。
(2) 負責預算的管理人員需要知道對財務的影響，沒有必要 100%站在長期愿景一邊。
沖突管理：架構師經常是多個不同背景的團隊的粘合劑（膠水）。有時候在不同的 level 之間的交流會發生沖突，需要你去找到一個平衡的解決方案，這可能會對長期戰略的目標造成影響。我的解決之道是 Schulze von Thun 的四眼模型（ “Four-Ears Model” of Schulze von Thun）。基于這個模型，可以幫你搞定一些事情。但這個理論需要多實踐幾次才能熟練掌握，可以在交流研討會上多用幾次。

(9) 顧問和教練

主動詢問，而不是被動等待，而且你需要有預見，預見接下來的幾周內會發生什么，然后規劃相應的步驟。

有遠見：如果你被分配入一個項目，不管是傳統的瀑布式方法還是敏捷方法，你總是需要有一個你要完成的中期和長期目標。這不是一個具體的涉及到細節的概念，更多的是一個 road-map，可以引導每個人進行工作。由于你不可能一次完成所有事情，它是一個長期持續的過程，我傾向使用成熟度模型（maturity models）。它可以給出一個清晰的結構，這個結構容易落地而且每次都能給出當前進度所處的狀態。對于不同的方面，我使用不同的模型。比如，開發實踐或持續交付。在成熟度模型中，每個 level 都有清晰的指標，這些指標都遵循 SMART 原則，這樣就能衡量你是否完成了目標。一個不錯的例子就是持續交付，這個你可以看看有關持續交付的文章，其中就用到了成熟度模型來衡量持續交付的水平。
構建實踐社區 (CoP：community of practice)：在一個有共同興趣愛好的組織中，交換經驗和知識有助于分享想法和統一方法。比如你可以把所有的 Java 開發和架構師們聚集起來在一個屋子里，每隔三個月，討論過去和現在面臨的挑戰并且分享他們是如何解決問題的，他們的一些新的方法論和解決方法。架構師們可以分享、討論和對齊他們的愿景，開發人員可以分享經驗經歷，然后相互學習。這樣的回合非常有利于公司，也有利于個人自己的發展。因為它有助于建立更強大的網絡和傳播思想。可以去看看這篇來自 SAFe Framework 的 Communities of Practice，它解釋了在敏捷環境中的 CoP 的概念。
進行公開討論：造成誤解和模棱兩可的源頭之一就是缺乏溝通。每周花三十分鐘的時間來和同伴交換熱門主題。這樣的討論可以沒有議程，任何事情都可以討論。也可以嘗試總是當場解決小事。對于更復雜的主題則需要專門安排時間。

(10) 營銷

你的點子和架構再好，當你講給別人聽的時候，沒人響應你，那么說明你可能缺乏一些營銷技能。

激勵并說服：別人憑什么買你的產品？你需要展示產品的價值和好處。你可以說出幾個核心的點，比如 5 個點或 3 個點，你需要包裝的好，而且讓別人容易理解（這里不是讓你過分（虛假）包裝，但包裝是必要的）。沒人喜歡一個整天穿著不整的人。
(1) 原型：為你的 idea 搞個原型。這樣讓別人一眼就知道你的產品最終的形態。這里說的產品指的是你的架構。
(2) 小短片： PPT 有時候會讓人煩躁，有時候你可以祭出一些小短片來表達你的觀點和方向。但是還是請不要過度營銷，否則未來沒人會理你的。
為你的 idea 堅持到底：人們有時候不喜歡你的觀點或他們沒時間 follow 你。如果你真的對你自己的 idea 有信心，那么你需要有屢戰屢敗，屢敗屢戰的心態。這個有時候很有用。架構決策有時候涉及到長期目標，往往沒那么容易：開發人員不愿意改，因為他們覺得開發起來復雜。管理者也不喜歡，在他們看來，對短期效益來說成本很高。這時候你要愈挫愈勇。
找到同盟：有時候你需要尋找盟友，使用你的網絡。如果你沒有網絡，那么現在就開始構建你的網絡。一開始你可以和你的同伴分享你的 idea，如果他們喜歡，那么你可以在向其他人推銷的時候，你至少可以說你的觀點目前被哪幾個人支持。如果他們不喜歡，你可以問問原因，你可以獲得更多然后改進 idea，或者你的故事沒有足夠的說服力。下一步你可以找一些具有決定權的盟友，進行公開的討論。如果你害怕討論，請盡量克服它，有時候你需要離開你的舒適區。
重復它，相信它：有一項研究表明重復不斷的廣播一個觀點，可以讓人們相信這個觀點，即使是只有一個人給你廣播這個觀點 (來源: The Financial Brand)。這也是很多那些西方的新聞報紙重復的發布有關川普的丑聞的奧秘所在，時間久了，人們就會相信川普是個大壞蛋。但這個策略要謹慎使用，畢竟你不是在搞政治，你需要道德。

相信本文會成為你在架構師道路上的一篇工具文，本文從作者的親身經歷以及綜合業界大佬們的見解，最終梳理出了成為架構師所必備的技能清單并給出建議，希望此文可以改善你的工作！

備注：文中部分場景結合了一些譯者本人的經歷。