不久前，高階架構師 Justin Miller 在 GitHub 上建立專案，介紹自己關於如何成為更好的軟體架構師的想法。該專案釋出一天即獲得 1.4K star，現在已有近 5K star 量。
幾年前有人問我：你是怎麼成為一名軟體架構師的?我們就此探討了必備技能、經驗，以及儲備相關知識所需的時間和精力。
除此之外，我也回顧了自己走過的路、使用或嘗試過的技術，以及我從那些五花八門的工作中學到的東西。
軟體架構師是什麼?
在進行深層次的探討之前，我們先來看兩個定義：
軟體架構師是指那些制定高階設計決策，並確定技術標準(包括軟體程式設計標準、工具和平臺)的軟體專家。這之中的首席專家就是總架構師。
軟體架構是系統的基本組織構成，這種組織主要體現在其元件、元件之間的關係、元件與環境之間的關係，以及決定系統設計與演化的原則。
架構的“層級”
架構主要可以抽象成以下幾個層級。不同層級所需的技能也不同。
儘管對層級的分類有很多種標準，但是我最喜歡把架構分成三個層級：
應用級：最低層級的架構。只關注單一的應用。層級低，但是很詳細。這方面的交流一般是在一個開發團隊內展開。
解決方案級：架構的中間層。關注一或多個滿足業務需求的應用(也就是商業方案)。這之中有些設計是高層次的，但大部分還是低層次的設計。這種層級架構的交流就開始涉及多個團隊了。
企業級：架構的最高層級。關注多個方案。這種架構的設計層次高且抽象，因此也需要方案級和應用級的架構師對此進行細化。這種層次的架構就需要多個組織進行溝通了。
有時候，架構師也被看做不同工作組之間的粘合劑。以下是三個例子：
橫向：在業務部和開發人員或是不同的開發團隊之間架起溝通的橋樑。
縱向：在管理者和開發人員之間架起橋樑。
技術：將不同的技術或應用整合在一起。
軟體架構師的日常
要了解架構師的必備技能，我們得先知道架構師主要做什麼。
我認為架構師最重要的活動包括：
定義和確定所需的開發技術與平臺。
定義開發標準，如程式設計標準、工具、稽核流程、測試方法等。
對確定和理解業務需求提供支援。
設計系統並根據需求做出決策。
對架構定義、設計和決策進行討論記錄。
檢查並稽核架構與程式碼，比如檢查前期確定的模式與程式設計標準是否被正確實施。
與其他部門和架構師合作。
對開發人員的引導及諮詢。
將高階設計細化，並轉化為較低階的設計。
PS：架構設計是一項持續性的工作，尤其是在敏捷軟體開發過程中。因此，我們會一遍又一遍地重複這些工作。
軟體架構師必備技能
為了支撐上述工作需要很多重要的能力。就我個人的經驗，每個軟體架構師應該具備如下十項技能:
設計能力
決策能力
化繁為簡能力
編碼能力
文件架構能力
溝通能力
評估能力
平衡能力
指導、答疑能力
營銷能力
設計能力
什麼是好的設計?這可能是最重要和最具挑戰性的問題。要把理論和實踐區別開來。
根據我的經驗，兩者兼而有之是最有價值的。讓我們從理論開始：
①瞭解基本的設計模式：設計模式是架構師設計開發可維護、可擴充套件系統的一項最重要工具。
通過設計模式你可以設計解決通用問題的可重用方案。由 John Vlissides，Ralph Johnson，Richard Helm，Erich Gamma 撰寫的《設計模式：可重用物件導向軟體的要素》一書，每個從事軟體開發的人都有必要閱讀一番。
儘管上述模式釋出於 20 多年前，其仍然是現代軟體架構的重要基礎。例如，本書描述了模型-檢視-控制器(MVC)模式，該模式應用於許多領域，也是一些新模式(如 MVVM)的基礎。
②深耕模式和反模式：如果你已經知道了所有的基本 GoF 模式，那麼可以用更多的軟體設計模式擴充套件你的知識或者深入你感興趣的領域。
我最喜歡的應用程式整合相關的內容之一是 Gregor Hohpe 編寫的《企業整合模式》一書。
本書適用於兩個不同環境的應用程式需要交換資料時，無論是一些傳統系統的舊式檔案交換還是現代微服務體系結構。
③瞭解質量測量：定義架構遠不是終點。指引手冊和編碼標準的定義、應用和管理是有原因的，這麼做是因為質量和非功能性需求。
你想擁有一個可維護、可靠、可適應、安全、可測試、可擴充套件、可用等的系統，而實現所有這些質量屬性的一個方法就是應用好的架構工作。
你可以在維基百科上了解更多關於質量衡量的資訊。理論很重要。如果你不想成為一名站在空中樓閣上的架構師，那麼實踐同樣重要，甚至更重要。
④嘗試瞭解不同的技術棧：這是成為一個更好的架構師的一項重要工作。嘗試新的技術棧並至上而下的學習他們。
不同的技術可以給你帶來不同的設計理念和模式。對新技術的學習最好不要浮於表面，應該去多實踐深入感受解決的痛點和其存在的問題。
架構師不僅需要涉獵廣泛，在某些領域也要有深厚的知識。當然並不需要掌握所有的技術，你需要對你所在領域最核心的技術有紮實的瞭解。
你也可以嘗試其他領域的技術，例如，如果你深入 SAP R/3，你就應該也去嘗試一下 JavaScript，反正亦然。時刻保持好奇心並付諸實踐。還可以去試一些你討厭了很多年的技術。
⑤分析和理解應用模式：看一下當前的任一比較流行的框架，例如 Angular。可以在實踐中研究很多模式，例如“觀察者模式”。
嘗試瞭解它如何在框架中應用，為什麼要這樣做。如果真的很有時間且認真，可以更深入地瞭解程式碼並瞭解其實現方式.
⑥加入一些使用者組，例如 Meetup。
決策能力
架構師需要能夠做出決策並將專案或整個組織引導到正確的方向。
①知道重點：不要把時間浪費在不重要的決定或者行為上。學會抓住重點。據我所知，目前還沒有一本書講這方面的內容。
個人評估某件事是否重要，通常考慮如下兩點：
概念完整性：即使您決定以一種方式做到這一點，堅持下去，即使有時以其他方式更好地做到這一點也是如此。通常，這會讓概念整體上更簡單，簡化可理解性並簡化維護性。
一致性：例如，如果您定義並應用命名約定，它就無關於大小寫，而是以相同的方式在任何地方應用它。
②優先順序：有些決定是非常關鍵的。如果不盡早決策，會產生很多冗餘到後期不太能刪除的方案，導致維護困難，甚至於導致開發人員無法繼續開發，直到給出決策。
這種時候，往往給出壞的決定好於沒有決定。當然，遇到這種情況時優先選擇當前方案中的最優解。
這裡我建議看看在敏捷軟體開發中廣泛使用的加權最短作業優先(WSJF)模型。尤其是時間關鍵性和風險降低是評估體系結構決策優先順序的關鍵。
③明確自己的職責：不要決策在你能力或者職責範圍之外的事情。這是至關重要的，如果不考慮的話，它可能會嚴重破壞你架構師的地位。
為了避免這種情況，一定要與你的夥伴們明確你承擔的責任及角色。如果架構師不止一個，那麼你應該尊重當前的組織架構。
作為級別低的一方，最好是給出建議不是決策。此外，我建議始終和同伴一起評審關鍵決策。
④評估多個選項：在決策時，一定要有一個以上的選擇。在我參與的大多數案例中，有不止一個(好的)選擇。
只有一個選擇是不好的，兩個方面：首先，似乎你沒有做好你的工作，其次，它阻礙了做出正確的決定。
通過定義度量標準，可以基於事實而不是直覺(例如許可證成本或成熟度)比較選項。這通常會導致更好、更可持續的決策。
此外，向不同的利益相關者推銷決策也更容易。此外，如果沒有正確評估選項，則在討論時可能會遺漏一些因素。
化繁為簡能力
請記住 Occam 剃刀的解決問題的原則，它表示更喜歡簡單。
我把這個原則解釋為：如果你對這個問題有太多的假設要解決，那麼你的解決方案可能是錯誤的，或者導致不必要的複雜解決方案。為了得到一個好的解決方案，應該減少(簡化)假設。
①方案規整：為了簡化解決方案，從不同的位置角度評估它們通常有助於清理、規整解決方案。嘗試通過自上而下和自下而上的思考來形成解決方案。
如果您有一個資料流或程式，那麼首先考慮從左到右，再從右到左。可以提出一些問題，比如：在一個完美的世界裡，你的解決方案會怎麼樣?或者：“X 公司/個人會怎麼做?
其中 X 可能不是你的競爭對手，而是 BAT(百度、阿里、騰訊)之一。這兩個問題都迫使你減少 Occam 的 Razor 建議的假設。
②退一步：經過激烈和長時間的討論，得出的結果往往是高度複雜的草案。你永遠不應該把這些看作是最終的結果。
退一步：再看一眼大局(抽象層面)。還是有意義的嗎?然後在抽象的層次上再進行一次重構。
有時，停止討論並在第二天繼續討論會有幫助。至少我的大腦需要一些時間來處理和想出更好、更優雅和更簡單的解決方案。
③分而治之：把問題分成小塊來簡化。然後獨立解決。然後驗證這些小塊是否匹配在一起。退一步看一下這個的整體情況。
④重構不是壞事：如果找不到更好的主意，從更復雜的解決方案開始完全可以。如果解決方案遇到麻煩，您可以稍後重新考慮解決方案並應用您的學習。
重構不是邪惡的，但是在開始重構之前，請記住要進行以下工作：
進行足夠的自動化測試，以確保系統的正確功能。
從利益相關者得到的支援。要了解有關重構的更多資訊，建議閱讀《重構 改進現有程式碼的設計》，作者是 Martin Fowler。
編碼能力
即使作為一個企業級架構師，最抽象的架構層次，你仍然應該知道開發人員每天都在做什麼。
如果你不明白這是怎麼做到的，你可能會面臨兩大問題：
開發者不會接受你的嘴炮。
不瞭解開發人員的實踐需求和麵臨的困難。
①有一個輔助專案：這樣做的目的是嘗試新技術和工具，以瞭解當今和未來的開發方式。
經驗是觀察，情感和假設的結合(Kurt Schneider 的“軟體工程中的經驗和知識管理”)。
閱讀教程或一些利弊是好的。但這僅僅是“書籍知識”。僅當你自己嘗試事物時，才能體驗到情緒並建立關於事物好壞的假設。
而且，使用某項技術的時間越長，你的評估就會越準確。這將幫助您在日常工作中做出更好的決定。
當我開始程式設計時，我沒有程式碼完成，只有一些實用程式庫可以加快開發速度。顯然，在這種背景下，我今天會做出錯誤的決定。
今天，我們擁有大量的程式語言，框架，工具，過程和實踐。只有您對主要趨勢有一定的經驗和粗略的瞭解，才能參與對話並引導開發朝正確的方向發展。
②找到合適的東西去嘗試：您無法嘗試所有內容。這根本是不可能的。您需要一種更有條理的方法。
我最近發現的一種來源是 ThoughtWorks 的 Technology Radar。他們將技術，工具，平臺，語言和框架分為四類：採用，試用，評估和保留。
通過這種分類，更容易獲得新事物的概述及其準備情況，以更好地評估下一步要探索的趨勢：
採用：已經準備好提供企業級服務。
試用：能夠在一個承擔一定風險的專案中嘗試。
評估：還需進一步評估其對業務的影響。
保留：謹慎處理。
文件架構能力
架構文件有時更重要，有時則不重要。重要的文件例如體系結構決策或程式碼指南。
在開始編碼之前通常需要初始文件，並且需要不斷改進。其他文件可以自動生成，因為程式碼也可以是文件，例如 UML 類圖。
①程式碼整潔：如果做對的話，程式碼是最好的文件。一個好的架構師應該能夠區分好的程式碼和壞的程式碼。
羅伯特·C·馬丁(Robert C. Martin)所著的《程式碼整潔之道》一書是瞭解更多關於好壞程式碼的寶貴資源。
②儘可能生成文件：系統變化很快，很難更新文件。無論是關於 API 還是以 CMDBs(配置管理資料庫)形式出現的系統環境：底層資訊通常變化太快，無法手動更新相應的文件。
例如：對於 API，如果您是模型驅動的，則可以基於定義檔案自動生成文件，或者直接從原始碼生成文件。有很多工具存在，比如 Swagger 和 RAML 是一些不錯的初始選擇。
③必要而精簡：無論您需要記錄什麼檔案(例如決策檔案)，都應嘗試一次只關注一件事，並且僅包含關於這件事的必要資訊。大量的文件很難閱讀和理解。附加資訊應儲存在附錄中。
特別是對於決策檔案，講一個有說服力的故事而不是僅僅發表大量論據，更為重要。此外，這為您和您的同事節省了很多時間，而後者需要閱讀。
看看您過去做過的一些文件(原始碼，模型，決策檔案等)，然後問自己以下問題：“是否包含所有必要的資訊才能理解它?”，“確實需要哪些資訊，並且可以省略嗎?”和“文件中是否有紅線?”。
瞭解有關架構框架的更多資訊: 該點也可以應用於所有其他“技術”點。我把它放在這裡，是因為 TOGAF 或 Zachmann 之類的框架正在提供“工具”。
這些工具在文件站點上感覺很沉重，儘管它們的附加值並不限於文件。在這樣的框架中獲得認證可以教會您更系統地解決體系結構。
溝通能力
根據我的觀察，這是最被低估的技能之一。如果你在設計上很聰明，但不能傳達你的想法，你的想法可能會影響較小，甚至無法成功。
①學習如何傳達你的想法：在會議上進行協作時，知道如何正確的溝通傳達你的想法，將其同步到你的同行是至關重要的。
我發現《 UZMO-用筆思考》是提高我在這一領域技能的好資源。作為架構師，你通常不僅會參加會議，而且通常需要主持並主導會議。
②大型的演講：將你的想法呈現給小型或大型團體應該對您來說可行。如果對此感到不舒服，請開始向你最好的朋友介紹。
慢慢擴大小組。這是你只能通過離開自己的舒適區來學習的東西。請耐心等待，此過程可能需要一些時間。
③找到合適的溝通方式：不同的利益相關者有不同的利益和觀點。它們需要在各自的層面上用不同的方式單獨解決。
在你交流之前，退後一步，檢查你想分享的資訊是否有正確的層次，關於抽象性、內容、目標、動機等。
例如：開發人員通常對解決方案的非常小的細節感興趣，而經理則更喜歡知道哪個選項能節省最多的錢。
④經常溝通：如果沒有人知道，再香的架構也是毫無意義的。定期在每個組織級別上分發目標體系結構及其背後的思想。
安排與開發人員、架構師和管理人員的會議，向他們展示所需或定義的方式。
⑤透明：定期交流只能部分緩解缺少的透明度。您需要使決策背後的原因透明化。
特別是，如果人們不參與決策過程，則很難理解和遵循其背後的決策和理由。
⑥隨時準備發表演講：總有人有疑問，你想馬上給出正確的答案。儘量把最重要的幻燈片放在一個統一的集合裡，你可以展示和解釋。它為你節省了很多時間，也給你自己帶來了安全感。
評估能力
①瞭解基本專案管理原則：作為架構師或首席開發人員，您經常被要求估算實現您的想法：多長時間、多少人、哪些技能等。
當然，如果你計劃引入新的工具或框架，你需要對這些“管理”問題有一個答案。最初，你應該能夠給出一個粗略的估計，如天，月或年。
別忘了，它不僅僅是關於實現，還有更多的因素要考慮，比如需求管理、測試和 Bugfix。
因此，您應該瞭解所使用的軟體開發過程中的工作。通過過去的使用資料，你可以得到更好的評估，並從中得出你的預測。
如果你沒有過去的資料，你也可以嘗試一些方法，如巴里 W 鮑姆的 COCOMO。
如果你被分配在一個敏捷專案中，學習如何正確地進行評估和計劃：Mike Cohn 的《敏捷評估和計劃》一書提供了這個領域的一個堅實的概述。
②評估“未知”架構：作為架構師，您還應該能夠評估體系結構對於當前或未來上下文的適用性。
這不是一項簡單的任務，但是您可以通過手頭的一組問題來準備，這些問題對於每個架構都是常見的。
它不僅關乎體系結構，還關乎系統的管理方式，因為這也讓您瞭解了系統的質量。
我建議總是準備好一些問題並準備好使用。一般問題的一些想法：
設計實踐：架構遵循哪些模式?它們是否得到正確使用?設計是否遵循紅線或是否存在不受控制的增長?是否有明確的結構和關注點的分離?
開發實踐：制定並遵守規範指南?程式碼的版本是怎樣的?部署實踐?
質量保證：測試自動化覆蓋範圍?靜態程式碼分析到位且效果良好?同行評議到位?
安全性：有哪些安全概念?內建安全?滲透測試或自動安全分析工具到位並定期使用?
平衡能力
①質量是有代價的：早些時候我談到了質量和非功能性需求。如果過度使用架構，將會增加成本，並可能降低開發速度。你需要平衡架構和功能需求。應避免過度設計。
②解決矛盾目標：矛盾目標的典型例子是短期和長期目標。專案往往傾向於構建最簡單的解決方案，而架構師考慮的是長期的遠景。
通常，簡單的解決方案不適合長期的解決方案，並且有可能在以後被丟棄(沉沒成本)。
為了避免實施方向錯誤，需要考慮兩件事：
開發人員和業務部門需要了解長期願景及其好處，以便調整其解決方案。
負責預算的經理需要參與進來，以瞭解財務影響。不一定要把 100% 的長遠眼光直接放在適當的位置，但開發出來的成本大體在預算範圍內。
③衝突管理：架構師往往是不同背景的多個群體之間的粘合劑。這可能會導致不同層次的溝通衝突。
為了找到一個平衡的解決方案，同時也反映長期的戰略目標，架構師的角色往往是幫助克服衝突。
關於傳播理論的起點是舒爾茨·馮·圖恩的“四耳模型”。基於此模型，可以顯示並推論很多。但是，該理論需要一些實踐，在交流研討會上應該有經驗。
指導、答疑能力
在諮詢和輔導方面，積極主動可能是最好的選擇。如果有人問你，那就太晚了。架構重構是儘量要避免的。
你需要以某種方式預見未來幾周、幾個月甚至幾年，併為下一步做好準備：
①有遠見：如果你參與在一個專案中，無論是傳統的瀑布式方法還是敏捷方法，你始終需要對要實現的中長期目標有一個願景。
這不是一個詳細的概念，而是針對每個人都可以落地的路線圖。由於無法一次完成所有工作(這是一段旅程)，因此我更喜歡使用成熟度模型。
它們給出了易於使用的清晰結構，並且每次都給出了當前的進度狀態。對於不同的方面，我使用不同的模型，例如開發實踐或持續交付。
成熟度模型中的每個級別都有明確的要求，這些要求遵循 SMART 準則，以便輕鬆衡量是否已達到要求。我發現一個很好的例子是持續交付。
②建立實踐社群(CoP)：在一個共同興趣小組之間交流經驗和知識有助於分發思想和標準化方法。
例如，你可以每三個月左右將所有 JavaScript 開發人員和架構師聚集在一個房間中，討論過去和當前的挑戰以及如何解決它們或採用新的方法論和方法。架構師可以共享，討論和調整其願景，開發人員可以共享經驗並向同行學習。
這樣的交流不僅可以為企業帶來極大的好處，而且對個人本身也非常有利，因為它有助於建立更強大的網路並傳播思想。
還可以檢視 SAFe 框架中的文章實踐社群，該文章在敏捷環境中解釋了 CoP 概念。
③進行公開會議：誤解或模稜兩可的一個原因是缺乏溝通。在固定的時間段內，例如每週 30 分鐘，與同事交流熱門話題。
這次會議沒有議程，一切都可以討論。儘量當場解決小事。安排對更復雜主題的跟進。
營銷推廣
你的想法很好，你已經很好地溝通了，但是仍然沒有人願意追隨?那麼你可能缺乏營銷技巧。
①激勵和說服：公司如何說服你購買產品?他們證明了它的價值和好處。但不止如此。他們包裝得很好，並使其儘可能容易消化：
原型：展示你想法的原型。有很多建立原型的工具。在喜歡 SAP 的企業背景下，可以檢視 build.me，在其中您可以快速輕鬆地建立漂亮且可點選的 UI5 應用程式。
視訊：與“無聊的 PPT”不同的是，你還可以播放一段視訊，展示你的想法或至少方向。
但請不要過度營銷，從長遠來看，內容是王道。如果你的話沒有實現，從長遠來看，這將損害你的聲譽。
②堅持自己的想法：有些時候人們不喜歡你的想法，或者他們太懶了，不喜歡你的想法。
如果你真的被自己的想法所說服，你就應該不斷地去追求它們，並“戰鬥”。有時這是必要的。
具有長期目標的架構決策通常不是最簡單的：開發人員不喜歡它們，因為它們更復雜。
經理們不喜歡他們，因為他們在短期內更貴。這是你的工作，你要堅持和談判。
③尋找盟友：建立或執行你自己的想法可能是困難的，甚至是不可能的。努力尋找能夠支援和幫助說服他人的盟友。使用你的網路。
如果你還沒有，現在就開始建造它。你可以先和你的(思想開放的)同齡人談談你的想法。
如果他們喜歡，或者至少部分喜歡，如果別人問他們，他們很可能會支援你的想法(“X 的想法很有趣。”)。
如果他們不喜歡，問為什麼：也許你錯過了什麼?或者你的故事不夠有說服力?下一步是找到有決策權的盟友。
要求開誠佈公的討論。如果你害怕討論，記住有時候你需要離開你的舒適區。
我自己建了個群，對 JAVA 開發有興趣的朋友歡迎加入QQ群：322708204進行技術討論，裡面資深架構師會分享一些整理好的BATJ面試題：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。
④重複一遍，相信它：“ 研究表明，反覆接觸某個觀點會使人們相信該觀點更為普遍，即使該觀點僅來自一個人也是如此。”(來源：《金融品牌》)如果您經常釋出很少的資訊，則可以幫助您說服人們更容易。
但請注意：從我的角度來看，應該明智地使用這種策略，因為它可能適得其反，成為糟糕的營銷技巧。