不久前，高級架構師 Justin Miller 在 GitHub 上建立項目，介紹本身關於如何成爲更好的軟件架構師的想法。該項目發佈一天即得到 1.4K star，如今已有近 5K star 量。java
幾年前有人問我：你是怎麼成爲一名軟件架構師的？咱們就此探討了必備技能、經驗，以及儲備相關知識所需的時間和精力。git
軟件架構師是什麼？github
在進行深層次的探討以前，咱們先來看兩個定義：web
軟件架構師是指那些制定高級設計決策，並肯定技術標準（包括軟件編程標準、工具和平臺）的軟件專家。這之中的首席專家就是總架構師。數據庫
軟件架構是系統的基本組織構成，這種組織主要體如今其組件、組件之間的關係、組件與環境之間的關係，以及決定系統設計與演化的原則。編程
架構的「層級」設計模式
應用級：最低層級的架構。只關注單一的應用。層級低，可是很詳細。這方面的交流通常是在一個開發團隊內展開。安全
解決方案級：架構的中間層。關注一或多個知足業務需求的應用（也就是商業方案）。這之中有些設計是高層次的，但大部分仍是低層次的設計。這種層級架構的交流就開始涉及多個團隊了。微信
企業級：架構的最高層級。關注多個方案。這種架構的設計層次高且抽象，所以也須要方案級和應用級的架構師對此進行細化。這種層次的架構就須要多個組織進行溝通了。網絡
橫向：在業務部和開發人員或是不一樣的開發團隊之間架起溝通的橋樑。
縱向：在管理者和開發人員之間架起橋樑。
技術：將不一樣的技術或應用整合在一塊兒。
軟件架構師的平常
定義和肯定所需的開發技術與平臺。
定義開發標準，如編程標準、工具、審覈流程、測試方法等。
對肯定和理解業務需求提供支持。
設計系統並根據需求作出決策。
對架構定義、設計和決策進行討論記錄。
檢查並審覈架構與代碼，好比檢查前期肯定的模式與編程標準是否被正確實施。
與其餘部門和架構師合做。
對開發人員的引導及諮詢。
將高級設計細化，並轉化爲較低級的設計。
軟件架構師必備技能
爲了支撐上述工做須要不少重要的能力。就我我的的經驗，每一個軟件架構師應該具有以下十項技能:
設計能力
決策能力
化繁爲簡能力
編碼能力
文檔架構能力
溝通能力
評估能力
平衡能力
指導、答疑能力
營銷能力
設計能力
①瞭解基本的設計模式：設計模式是架構師設計開發可維護、可擴展系統的一項最重要工具。
經過設計模式你能夠設計解決通用問題的可重用方案。由 John Vlissides，Ralph Johnson，Richard Helm，Erich Gamma 撰寫的《設計模式：可重用面向對象軟件的要素》一書，每一個從事軟件開發的人都有必要閱讀一番。
儘管上述模式發佈於 20 多年前，其仍然是現代軟件架構的重要基礎。例如，本書描述了模型-視圖-控制器（MVC）模式，該模式應用於許多領域，也是一些新模式（如 MVVM）的基礎。
②深耕模式和反模式：若是你已經知道了全部的基本 GoF 模式，那麼能夠用更多的軟件設計模式擴展你的知識或者深刻你感興趣的領域。
我最喜歡的應用程序集成相關的內容之一是 Gregor Hohpe 編寫的《企業集成模式》一書。
本書適用於兩個不一樣環境的應用程序須要交換數據時，不管是一些傳統系統的舊式文件交換仍是現代微服務體系結構。
③瞭解質量測量：定義架構遠不是終點。指引手冊和編碼標準的定義、應用和管理是有緣由的，這麼作是由於質量和非功能性需求。
你想擁有一個可維護、可靠、可適應、安全、可測試、可擴展、可用等的系統，而實現全部這些質量屬性的一個方法就是應用好的架構工做。
你能夠在維基百科上了解更多關於質量衡量的信息。理論很重要。若是你不想成爲一名站在空中樓閣上的架構師，那麼實踐一樣重要，甚至更重要。
④嘗試瞭解不一樣的技術棧：這是成爲一個更好的架構師的一項重要工做。嘗試新的技術棧並至上而下的學習他們。
不一樣的技術能夠給你帶來不一樣的設計理念和模式。對新技術的學習最好不要浮於表面，應該去多實踐深刻感覺解決的痛點和其存在的問題。
架構師不只須要涉獵普遍，在某些領域也要有深厚的知識。固然並不須要掌握全部的技術，你須要對你所在領域最核心的技術有紮實的瞭解。
你也能夠嘗試其餘領域的技術，例如，若是你深刻 SAP R/3，你就應該也去嘗試一下 JavaScript，反正亦然。時刻保持好奇心並付諸實踐。還能夠去試一些你討厭了不少年的技術。
⑤分析和理解應用模式：看一下當前的任一比較流行的框架，例如 Angular。能夠在實踐中研究不少模式，例如「觀察者模式」。
嘗試瞭解它如何在框架中應用，爲何要這樣作。若是真的頗有時間且認真，能夠更深刻地瞭解代碼並瞭解其實現方式.
⑥加入一些用戶組，例如 Meetup。
決策能力
①知道重點：不要把時間浪費在不重要的決定或者行爲上。學會抓住重點。據我所知，目前尚未一本書講這方面的內容。
我的評估某件事是否重要，一般考慮以下兩點：
概念完整性：即便您決定以一種方式作到這一點，堅持下去，即便有時以其餘方式更好地作到這一點也是如此。一般，這會讓概念總體上更簡單，簡化可理解性並簡化維護性。
一致性：例如，若是您定義並應用命名約定，它就無關於大小寫，而是以相同的方式在任何地方應用它。
②優先級：有些決定是很是關鍵的。若是不盡早決策，會產生不少冗餘到後期不太能刪除的方案，致使維護困難，甚至於致使開發人員沒法繼續開發，直到給出決策。
這種時候，每每給出壞的決定好於沒有決定。固然，遇到這種狀況時優先選擇當前方案中的最優解。
這裏我建議看看在敏捷軟件開發中普遍使用的加權最短做業優先（WSJF）模型。尤爲是時間關鍵性和風險下降是評估體系結構決策優先級的關鍵。
③明確本身的職責：不要決策在你能力或者職責範圍以外的事情。這是相當重要的，若是不考慮的話，它可能會嚴重破壞你架構師的地位。
爲了不這種狀況，必定要與你的夥伴們明確你承擔的責任及角色。若是架構師不止一個，那麼你應該尊重當前的組織架構。
做爲級別低的一方，最好是給出建議不是決策。此外，我建議始終和同伴一塊兒評審關鍵決策。
④評估多個選項：在決策時，必定要有一個以上的選擇。在我參與的大多數案例中，有不止一個（好的）選擇。
只有一個選擇是很差的，兩個方面：首先，彷佛你沒有作好你的工做，其次，它阻礙了作出正確的決定。
經過定義度量標準，能夠基於事實而不是直覺（例如許可證成本或成熟度）比較選項。這一般會致使更好、更可持續的決策。
此外，向不一樣的利益相關者推銷決策也更容易。此外，若是沒有正確評估選項，則在討論時可能會遺漏一些因素。
化繁爲簡能力
①方案規整：爲了簡化解決方案，從不一樣的位置角度評估它們一般有助於清理、規整解決方案。嘗試經過自上而下和自下而上的思考來造成解決方案。
若是您有一個數據流或進程，那麼首先考慮從左到右，再從右到左。能夠提出一些問題，好比：在一個完美的世界裏，你的解決方案會怎麼樣？或者：「X 公司/我的會怎麼作？
其中 X 可能不是你的競爭對手，而是 BAT（百度、阿里、騰訊）之一。這兩個問題都迫使你減小 Occam 的 Razor 建議的假設。
②退一步：通過激烈和長時間的討論，得出的結果每每是高度複雜的草案。你永遠不該該把這些看做是最終的結果。
退一步：再看一眼大局（抽象層面）。仍是有意義的嗎？而後在抽象的層次上再進行一次重構。
有時，中止討論並在次日繼續討論會有幫助。至少個人大腦須要一些時間來處理和想出更好、更優雅和更簡單的解決方案。
③分而治之：把問題分紅小塊來簡化。而後獨立解決。而後驗證這些小塊是否匹配在一塊兒。退一步看一下這個的總體狀況。
④重構不是壞事：若是找不到更好的主意，從更復雜的解決方案開始徹底能夠。若是解決方案遇到麻煩，您能夠稍後從新考慮解決方案並應用您的學習。
重構不是邪惡的，可是在開始重構以前，請記住要進行如下工做：
進行足夠的自動化測試，以確保系統的正確功能。
從利益相關者獲得的支持。要了解有關重構的更多信息，建議閱讀《重構 改進現有代碼的設計》，做者是 Martin Fowler。
編碼能力
開發者不會接受你的嘴炮。
不瞭解開發人員的實踐需求和麪臨的困難。
①有一個輔助項目：這樣作的目的是嘗試新技術和工具，以瞭解當今和將來的開發方式。
經驗是觀察，情感和假設的結合（Kurt Schneider 的「軟件工程中的經驗和知識管理」）。
閱讀教程或一些利弊是好的。但這僅僅是「書籍知識」。僅當你本身嘗試事物時，才能體驗到情緒並創建關於事物好壞的假設。
並且，使用某項技術的時間越長，你的評估就會越準確。這將幫助您在平常工做中作出更好的決定。
當我開始編程時，我沒有代碼完成，只有一些實用程序庫能夠加快開發速度。顯然，在這種背景下，我今天會作出錯誤的決定。
今天，咱們擁有大量的編程語言，框架，工具，過程和實踐。只有您對主要趨勢有必定的經驗和粗略的瞭解，才能參與對話並引導開發朝正確的方向發展。
②找到合適的東西去嘗試：您沒法嘗試全部內容。這根本是不可能的。您須要一種更有條理的方法。
我最近發現的一種來源是 ThoughtWorks 的 Technology Radar。他們將技術，工具，平臺，語言和框架分爲四類：採用，試用，評估和保留。
經過這種分類，更容易得到新事物的概述及其準備狀況，以更好地評估下一步要探索的趨勢：
採用：已經準備好提供企業級服務。
試用：可以在一個承擔必定風險的項目中嘗試。
評估：還需進一步評估其對業務的影響。
保留：謹慎處理。
文檔架構能力
①代碼整潔：若是作對的話，代碼是最好的文檔。一個好的架構師應該可以區分好的代碼和壞的代碼。
羅伯特·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 的想法頗有趣。」）。
若是他們不喜歡，問爲何：也許你錯過了什麼？或者你的故事不夠有說服力？下一步是找到有決策權的盟友。
要求開誠佈公的討論。若是你懼怕討論，記住有時候你須要離開你的溫馨區。
④重複一遍，相信它：「 研究代表，反覆接觸某個觀點會令人們相信該觀點更爲廣泛，即便該觀點僅來自一我的也是如此。」（來源：《金融品牌》）若是您常常發佈不多的信息，則能夠幫助您說服人們更容易。
但請注意：從個人角度來看，應該明智地使用這種策略，由於它可能拔苗助長，成爲糟糕的營銷技巧。
做者：Justin Miller
出處：https://github.com/gamedilong/SoftwareArchitect-CN
原文：https://github.com/justinamiller/SoftwareArchitect
精彩文章推薦：
喜歡就點個"在看"唄^_^
本文分享自微信公衆號 - 江南一點雨（a_javaboy）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。