幾年前，我被問到“你是如何變成一名架構師的？”。基於這個話題，我們討論了很多，比如必要的技術、經驗以及所需要的知識儲備等。這一次討論促使我開始思考要成爲一名架構師應該具備和學習的東西有哪些，成爲一個優秀的架構師應該具備哪些能力和做哪些事情。爲此我查閱資料，走訪各位大佬，當然也結合自己的經歷，最終我輸出了今天這樣一篇文章，希望通過閱讀此文，你可以從此知道自己的架構師之路該怎麼走。
什麼是架構師？
在開始具體的細節之前，我們先來理清兩個定義。
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、設計
什麼是好的設計？這個可能是一個非常重要同時又要挑戰性的問題。分爲理論和實踐。就我的經驗，二者的結合是最有價值的。
1）知道基礎的設計模式：模式是一個非常重要的工具，是架構師開發可維護系統的重要工具之一。記住，你要想開發出可維護的系統，請記得適當地運用設計模式。通過模式你可以重用那些已經被證明可以解決常見問題的設計思路。去看看GoF（Gang of Four）寫的有關設計模式的書吧，儘管這些模式已經20多年了，但依然是現代軟件架構的基礎。比如Model-View-Controller (MVC) 模式就可以用於多個領域，甚至是一些更新的模式的基礎，比如MVVM。
2）對模式和反模式進一步鑽研：如果你已經知道了所有基礎的GoF設計模式，接下來可以擴展自己的知識儲備去學習更多的軟件設計模式，或對你感興趣的領域進行垂直鑽研。我個人比較喜歡Gregor Hohpe寫的一本書叫：Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions。這本書主要的內容是系統之間的數據交換（應用集成方面）。
3）知道質量度量（quality measures）：確定和定義架構不是終點。你還需要讓你的系統可維護、可靠、適應性好、安全、可測試、可擴展、可重用等。所有這些都滿足了，纔算是一個好的架構。你可以去百科上去看看有關quality measures的內容。不過理論固然重要，但實戰同樣重要，甚至更重要。千萬不要變成“象牙塔架構師”（http://www.gitshah.com/2011/01/ivory-tower-architect.html）。
4）嘗試並瞭解不同的技術棧：我認爲這是非常重要的，如果你想變成一個更好的架構師的話。嘗試去了解新的技術棧，然後學習下這些技術是怎麼實現的。不同的新的技術一般是使用不同的設計思路和模式。簡單地去看看PPT之類的你可能並不能學到什麼，你只有親自去實踐了，纔會感受到痛苦和甜蜜。一個架構師不能只是面廣，在某些領域還要扎得深。也許hold住所有的技術棧不是最重要的，但你需要在你的某個最重要的領域要有獨到和紮實的見解。同時你也學習一下不屬於你領域的技術，比如你是Java，那麼你也要學習一下JavaScript等前端語言或技術，反之亦然。
5）分析和了解框架中應用的設計模式：你可以去研究當前任何開源的或正在使用的框架，比如Angular. 你可以學習到在實踐中的很多設計模式，比如Observables。嘗試去搞懂該模式在這個框架中是如何被使用的，爲什麼它這麼做。如果你真的狂熱，也可以看看源碼並且搞懂它是如何實現的。
6）保持好奇並去參加各種技術聚會：在德國，我們有個Java User Group (JUG) 組織，這個組織在每個大點的城市都有。我們會討論各種topic，從low level的編碼到上層的有關架構的主題。我真的熱愛這些活動，因爲它可以增強你的思維能力和擴大你個人的社交網絡。
2、決策（決定）
架構師需要能夠做決定並且引導項目或整個組織朝着正確的方向邁進。
1）知道什麼是重要的：不要浪費時間在那些不重要的決定或活動上，學會認識什麼是重要的。目前看來也沒什麼書籍教你識別這些。我個人有個原則，每當我要評價一件事是否重要我就會考慮這兩個方面：
-
概念完整性（Conceptional Integrity）: 如果你決定以某種方式去做，那麼就幹，即使有時候會有更優的方案。通常來說，這會使得你有一個直接的全局的概念，使得更容易理解和更容易維護。
-
統一性（Uniformity）:比如如果你有名稱的一些約定，當然無論是小寫還是大寫，至少讓每個地方都是用同樣的方式，比較統一。
2）優先級： 有關這方面建議去看一下Weighted Shortest Job First (WSJF) 模型，這個模型被廣泛用於敏捷軟件開發中。尤其是時間緊迫性（ time criticality）和降低風險（risk reduction）對於評估架構決策優先級至關重要。
3）知道自己的能力： 不要對你不瞭解的事情做決策和決定。各級幹各級的事情，要理清每一層的責任，然後對你所負責的層去做決策。如果有多個架構師，那麼你應該遵循目前你所安排的架構級別。作爲一個lower level架構師，如果對higher level的架構不滿意，可以提建議，而不是做決定。此外，我建議始終與同伴一起檢查關鍵決策。
4）評估多個選項：應該總是給出多種方案，這樣才能進行做出決策和決定。不要只給一個方案，聽着感覺就是你沒有認真工作一樣。另外只有一個方案的時候，也沒法做出一個合理的選擇，因爲只有一個方案。另外就是要定義一些指標和標準，通過這個來衡量哪個方案好，哪個方案不好，最好不要去憑感覺。比如：license花費或成熟度（本文有講到成熟度模型）。這樣才能做出一個更好的決策。
3、簡化（化繁爲簡）
記住一個解決問題的原則Occam’s Razor。 這個原則告訴你解決問題要簡單。這個原則裏有一句話叫：最簡單的那個solution往往是最好的。我總結這個原則的核心是：如果你對某個問題有多個假定解決方案，這很有可能就是錯的，或者導致沒必要的複雜的解決方案。多個假定方案應該被簡化到只有一個好的解決方案。別提出來一大堆解決方案，說這個也可以，那個也可以，說明是有問題的。
1）矯正解決方案：通過對解決方案的矯正，有助於你發現最簡單的那個方案，通過從不同的角度和位置去看，往往會得到不錯的效果。你可以從上到下的想一遍，然後再從下到上的想一遍。如果你有一個數據流（data flow）或流程，那麼你可以先從左往右想一遍，然後從右往左想一遍。與此同時問自己一個問題：“在理想的世界裏，你的解決方案會發生什麼？” 或：“公司或指定人員會做什麼？” 這兩個問題會強迫你把解決方案減少到如Occam’s Razor建議的那樣。
2）退一步海闊天空: 經過了激烈而漫長的討論，通常會得出一個高度複雜的塗鴉。但千萬也永遠都不應將這個視爲最終結果。這時候，你需要後退一步：再次查看全局（抽象級別）。回到最初的本心，還是有意義嗎？然後再次在抽象級別上進行遍歷並進行重構。做這一步有時候讓結論更加清晰，而不至於第二天繼續進行方案的討論。至少我的大腦需要一些時間來處理並提出更好，更優雅，更簡單的解決方案。人的腦子是需要時間來思考的。
3）分解成一個個小問題（Divide and Conquer）: 簡化問題的一個好辦法就是把問題切分成多個小問題然後挨個解決。這讓我想起了自己小時候打掃院落的場景，看着偌大一個院子，看着就煩，於是我決定把院子劃分成三個小塊，然後一個個去打掃，這讓我的心理負擔減輕了不少。一個個小塊打掃完了，最後再整體查看下整個院子還有沒有邊邊角角的地方需要打掃。總覽一下全局，然後整個院子就打掃完了。再枯燥的生活，都可以發現一些樂趣。
4）重構並不可恥: 有時候，你可能一時半會想不到更簡單的方案，你不妨就從一個複雜的方案開始做起，先做着，等到之後再進行重構，這時候再去重新思考解決方案。重構並不可恥，但重構之前要注意一件事情：足夠的自動化測試以確保你所重構的地方的功能正確和滿足利益相關者的需求。學習更多重構的知識，我建議你可以讀讀《重構、改善既有代碼的設計》 “Refactoring. Improving the Design of Existing Code” ，這本書是 Martin Fowler寫的。
4、代碼
即使你是一個企業級別的架構師，就最頂層的那種架構，你依然應該知道開發人員在他們每天的工作中主要做些什麼。如果你不能明白某個東西如何實現的，你可能會面臨兩個主要問題：
-
開發人員有可能不會接受你說的。
-
你也不會明白開發人員要什麼和麪臨的挑戰。
1）有個輔助項目（Have a side project）: 跟進一個輔助項目，可以讓你瞭解到新的技術和工具，以瞭解到當今和未來的開發方式。Kurt Schneider寫的“Experience and Knowledge Management in Software Engineering”（軟件工程中經驗和知識管理）一書中說經驗是所見、情感和假設的結合。看書固然是好事，但這只是書本知識（book knowledge）。只有當你自己嘗試去做事情本身，然後你感受到情感和發生情緒，然後有了對事物好壞的判斷。你使用技術的時間越長越能做出正確的評判。這有助於你在日常的工作中做出正確的判斷。當前有大量的語言和框架，只有你對這些有一定的經驗和了解後才能做出正確的決策，從而引導開發人員朝着正確的方向邁進。還是那句話，記住經驗的定義：所見、情感和假設。要想有經驗就要去動手！
2）找到正確的事去嘗試：你不可能去嘗試所有事情。這是不可能的。你需要一個更加結構化的方法。有一個來自ThoughtWorks不錯的方法是技術雷達（Technology Radar）。他們把技術、工具、平臺、語言和框架分爲四類：Adopt，Trial，Assess 和 Hold。Adopt（採用） 意思是 “強烈的感覺到已經可投入到生產中使用了”，Trial（試用） 意思是 “可以先在某個項目中做嘗試，在這個項目中做到風險可控”， Assess（調研） 意思是“可以探索下對公司有哪些影響”， Hold（保留） 意思是 “謹慎使用”。通過這種分類，更容易獲得新技術的整體情況及其準備情況，以更好地評估下一步要幹什麼。
5、文檔
架構文檔有時候很重要，但有時候又不重要。重要的文檔比如架構決策或編碼指導手冊。編碼開始之前通常需要初始文檔，並且需要不斷完善。其他文檔可以自動生成，因爲代碼也可以是文檔，例如UML類圖。
1）Clean Code：代碼是最好的文檔，如果你寫得足夠好。一個好的架構師要有能力分辨出好代碼和爛代碼。著名的書：“Clean Code”。
2）如果可能的話，儘可能自動生成文檔：手動寫文檔的壞處不多說，把 Swagger 和 RAML 或者公司內部開發的文檔系統快點用起來吧。
3）文檔儘可能少（As much as necessary, as little as possible）：文檔儘量少。無論您需要寫什麼文檔（例如決策文檔），都應嘗試一次只關注一件事，並且僅包含關於這件事的必要信息。大量的文檔很難閱讀和理解。附加信息應放在附錄中。特別是對於決策文件，講一個有說服力的故事更爲重要而不是僅僅發表大量的論證。而且，這可以爲你和你的同事節省很多時間，因爲他們要閱讀你的文檔。看看你過去輸出過的一些文檔（源代碼，模型，決策文件等），然後問自己以下問題：“是否包含所有必要的信息才能理解它？”，“確實需要哪些信息？可以省略嗎？”和“文檔中是否有紅線？”。一句話，不要廢話。
6、溝通
不多說，溝通很重要。
1）學習怎麼和別人溝通你的觀點： 推薦一本書 “UZMO — Thinking With Your Pen” 。作爲架構師你經常參會，甚至主持會議，所以你得學會如何和人們溝通你的想法。
2）通過演講宣貫：一開始你可以向你身邊的朋友表達，然後範圍慢慢擴大，最後向衆多人演講來表述你的觀點。如果你對此感到不適，你需要走出舒適區來加強提高這一點。保持耐心，這個可能需要一些時日。（有時候大佬的一句鼓勵，會讓你釋放掉過往的不自信，開始相信即使最差發揮大家都會感覺到還不錯。）
3）確定溝通的人羣level：不同的利益相關者有不同的興趣和視角。不同的人羣需要單獨的針對某一級別的人羣去定向溝通。在溝通之前，請確認你要溝通的人羣，比如抽象性、內容、目標、動機等。比如開發人員關注一些解決方案的微小細節，而管理者更傾向怎麼省錢。
4）經常溝通：一個再好的架構沒人知道它的價值依然爲零。分發對應級別的架構，然後安排會議與開發者、架構師和管理者分享未來的和已經在踐行的架構。
5）要透明：定期的溝通只能部分緩解透明度問題。你需要把決策的原因透明化。特別有的人可能沒有參加決策過程的情況下會很難理解決策以及其背後的原因。
6）隨時準備演講：把常見問題放在一個顯眼（易找到）的地方，隨時應對人們提出的問題，這樣有時候會保護你。
7、估算和評估
1）知道基本的項目管理和原則： 作爲架構師你經常會被問到如下問題，多久完成？得花多少錢？需要幾個人？用到哪些技術？等。你需要學習一些估算技能。比如敏捷中的估算法等，建議到網上查閱這部分的資料。
2）評估未知架構（Evaluate “unknown” architecture）：作爲一個架構師你也要能夠去評估架構的適用性，針對目前和將來的適用性。這不是一個簡答的事情，但你可以準備一些問題，然後去使用，以下是一些通用的問題：
①設計實踐：
-
這個架構用了哪個模式？有沒有被正確的使用？
-
這個設計遵循紅線（red line）了嗎？這個設計有沒有能夠可持續（uncontrolled growth）？
-
有沒有一個清晰的結構和各自領域的單獨關注有沒有分佈合理？
②開發實踐：
-
代碼指引手冊有沒有到位？遵循了嗎？
-
代碼版本管理怎麼做的？有沒有版本化？
-
部署是怎麼分佈的？
③質量保障：
-
自動化測試覆蓋率怎麼樣?
-
靜態代碼分析有沒有做？分析結果怎麼樣？交叉檢查有沒有做？
④安全：
-
有哪些安全概念到位？
-
內置安全？
-
滲透測試或自動安全分析工具是否到位，經常在用嗎？
8、權衡（balance）
1）質量是有代價的：早先我談到過質量和非功能性需求。如果你過度設計架構，則會增加成本，並可能降低開發速度。你需要權衡架構和功能需求。應避免過度設計。
2）解決矛盾目標：一個典型的矛盾目標的例子就是短期和長期目標。項目往往趨向於構建一個最簡單的方案來解決問題而架構師則具有長期的眼光和願景。一般情況下，最簡單的方案往往都不能滿足長期目標和願景。爲了避免技術實現步入錯誤的方向，有兩件事情需要考慮：
-
開發人員和業務需要明白長期願景和目標，知道調整成新的解決方案可以帶來好處。
-
負責預算的管理人員需要知道對財務的影響，沒有必要100%站在長期願景一邊。
3）衝突管理：架構師經常是多個不同背景的團隊的粘合劑（膠水）。有時候在不同的level之間的交流會發生衝突，需要你去找到一個平衡的解決方案，這可能會對長期戰略的目標造成影響。我的解決之道是Schulze von Thun的四眼模型（ “Four-Ears Model” of Schulze von Thun）。基於這個模型，可以幫你搞定一些事情。但這個理論需要多實踐幾次才能熟練掌握，可以在交流研討會上多用幾次。
9、顧問和教練
主動詢問，而不是被動等待，而且你需要有預見，預見接下來的幾周內會發生什麼，然後規劃相應的步驟。
1）有遠見：如果你被分配入一個項目，不管是傳統的瀑布式方法還是敏捷方法，你總是需要有一個你要完成的中期和長期目標。這不是一個具體的涉及到細節的概念，更多的是一個road-map，可以引導每個人進行工作。由於你不可能一次完成所有事情，它是一個長期持續的過程，我傾向使用成熟度模型（maturity models）。它可以給出一個清晰的結構，這個結構容易落地而且每次都能給出當前進度所處的狀態。對於不同的方面，我使用不同的模型。比如，開發實踐或持續交付。在成熟度模型中，每個level都有清晰的指標，這些指標都遵循SMART原則，這樣就能衡量你是否完成了目標。一個不錯的例子就是持續交付，這個你可以看看有關持續交付的文章，其中就用到了成熟度模型來衡量持續交付的水平。
2）構建實踐社區 (CoP：community of practice)：在一個有共同興趣愛好的組織中，交換經驗和知識有助於分享想法和統一方法。比如你可以把所有的Java開發和架構師們聚集起來在一個屋子裏，每隔三個月，討論過去和現在面臨的挑戰並且分享他們是如何解決問題的，他們的一些新的方法論和解決方法。架構師們可以分享、討論和對齊他們的願景，開發人員可以分享經驗經歷，然後相互學習。這樣的回合非常有利於公司，也有利於個人自己的發展。因爲它有助於建立更強大的網絡和傳播思想。可以去看看這篇來自SAFe Framework的Communities of Practice，它解釋了在敏捷環境中的CoP的概念。
3）進行公開討論：造成誤解和模棱兩可的源頭之一就是缺乏溝通。每週花三十分鐘的時間來和同伴交換熱門主題。這樣的討論可以沒有議程，任何事情都可以討論。也可以嘗試總是當場解決小事。對於更復雜的主題則需要專門安排時間。
10、營銷
你的點子和架構再好，當你講給別人聽的時候，沒人響應你，那麼說明你可能缺乏一些營銷技能。
1）激勵並說服：別人憑什麼買你的產品？你需要展示產品的價值和好處 。你可以說出幾個核心的點，比如5個點或3個點，你需要包裝的好，而且讓別人容易理解（這裏不是讓你過分（虛假）包裝，但包裝是必要的）。沒人喜歡一個整天穿着不整的人。
-
原型：爲你的idea搞個原型。這樣讓別人一眼就知道你的產品最終的形態。這裏說的產品指的是你的架構。
-
小短片：PPT有時候會讓人煩躁，有時候你可以祭出一些小短片來表達你的觀點和方向。但是還是請不要過度營銷，否則未來沒人會理你的。
2）爲你的idea堅持到底：人們有時候不喜歡你的觀點或他們沒時間follow你。如果你真的對你自己的idea有信心，那麼你需要有屢戰屢敗，屢敗屢戰的心態。這個有時候很有用。架構決策有時候涉及到長期目標，往往沒那麼容易：開發人員不願意改，因爲他們覺得開發起來複雜。管理者也不喜歡，在他們看來，對短期效益來說成本很高。這時候你要愈挫愈勇。
3）找到同盟：有時候你需要尋找盟友，使用你的網絡。如果你沒有網絡，那麼現在就開始構建你的網絡。一開始你可以和你的同伴分享你的idea，如果他們喜歡，那麼你可以在向其他人推銷的時候，你至少可以說你的觀點目前被哪幾個人支持。如果他們不喜歡，你可以問問原因，你可以獲得更多然後改進idea，或者你的故事沒有足夠的說服力。下一步你可以找一些具有決定權的盟友，進行公開的討論。如果你害怕討論，請儘量克服它，有時候你需要離開你的舒適區。
4）重複它，相信它：有一項研究表明重複不斷的廣播一個觀點，可以讓人們相信這個觀點，即使是隻有一個人給你廣播這個觀點 (來源: The Financial Brand)。這也是很多那些西方的新聞報紙重複的發佈有關川普的醜聞的奧祕所在，時間久了，人們就會相信川普是個大壞蛋。但這個策略要謹慎使用，畢竟你不是在搞政治，你需要道德。
相信本文會成爲你在架構師道路上的一篇工具文，本文從作者的親身經歷以及綜合業界大佬們的見解，最終梳理出了成爲架構師所必備的技能清單並給出建議，希望此文可以改善你的工作！
ps：文中部分場景結合了一些譯者本人的經歷。
參考資料