【譯】軟件架構師之路

今天給你們帶來一篇本身翻譯的乾貨《軟件架構師之路》。本週Github上升很快的項目。其內容對致力於成爲軟件架構師（不論先後端）的同窗應該都會有極大的幫助。

項目地址:

中文地址 https://github.com/gamedilong...

原文地址 https://github.com/justinamil...

若是有看完英文原文，發現本文翻譯內容中存在問題或者錯誤的歡迎到中文Git地址PR，如可以對你們起到必定的幫助也歡迎star

內容

• 什麼是軟件架構
• 軟件架構的層次
• 軟件架構師的典型工做內容
• 軟件架構師的重要技能
• 架構師的技術路線圖
• 相關書籍

什麼是軟件架構?

• 軟件架構師是一名軟件開發專家，他能夠進行高層設計選擇並決定技術標準，包括軟件編碼標準，工具和平臺。

(出處: 維基百科:軟件架構師)

• 軟件架構（architecture）是一個系統的基本組織，由其組件、它們之間的相互關係和環境以及決定系統設計和演化的原則來表示。

(出處: 軟件架構手冊)

軟件架構的層次

軟件架構能夠被抽象的分爲幾個層次，不一樣的層次對技能的要求不一樣。對層次有不少不一樣的劃分，我最喜歡以下這三種劃分:

• 應用級: 最低層次的架構。聚焦單個具體的應用。 很是注重細節, 底層設計。 溝通僅限入單個開發團隊。
• 解決方案級: 中級別的架構. 聚焦解決業務需求（業務解決方案）的一個或多個應用。進行一些高層次可是主要以低層次的設計爲主，須要在多個開發團隊之間的溝通。
• 企業層級: 最高級別的架構。專一於多種解決方案。高層次的抽象設計，須要將解決方案對應用架構師進行詳細說明。 須要在整個組織溝通。查看 連接 得到更多相關信息。

有時架構師也被看做是不一樣利益相關者之間的「粘合劑」。 三個例子:

• 水平方向: 架起業務與開發人員或不一樣開發團隊之間的溝通橋樑。
• 垂直方向: 架起開發人員和管理人員之間的溝通橋樑。
• 技術方向: 不一樣的技術棧或應用程序的集成和融合。

軟件架構師的典型工做內容

要了解架構師所需的必要技能，咱們首先須要瞭解架構師平時主要幹什麼。如下是我認爲最重要的一些工做內容:

• 定義和肯定開發技術和平臺。
• 定義開發標準，如編碼標準、工具、評審過程、測試方法等。
• 支持認識和理解業務需求。
• 根據需求設計系統並作出決策。
• 記錄並傳達架構定義、設計和決策。
• 檢查和評審架構與代碼等，檢查是否符合約定的設計模式和編碼標準。
• 與其餘架構師和相關方協做。
• 負責開發的指導和諮詢。
• 細化、細化上級設計爲下級設計。

  注意: 架構是一項持續的工做，尤爲當項目採起敏捷開發的模式，上述工做應該也是反覆迭代進行的。

軟件架構師的重要技能

爲了支撐上述工做須要不少重要的能力。就我我的的經驗，每一個軟件架構師應該具有以下十項技能:

• 設計能力
• 決策能力
• 化繁爲簡能力
• 編碼能力
• 文檔架構能力
• 溝通能力
• 評估能力
• 平衡能力
• 指導、答疑能力
• 營銷能力

(1) 設計能力

什麼是好的設計？這多是最重要和最具挑戰性的問題。要把理論和實踐區別開來。根據個人經驗，二者兼而有之是最有價值的。讓咱們從理論開始:

• 瞭解基本的設計模式: 設計模式是架構師設計開發可維護、可擴展系統的一項最重要工具。經過設計模式你能夠設計解決通用問題的可重用方案。 由John Vlissides，Ralph Johnson，Richard Helm，Erich Gamma撰寫的《設計模式：可重用面向對象軟件的要素》一書每一個從事軟件開發的人都有必要閱讀一番。儘管上述模式發佈於20多年前，其仍然是現代軟件架構的重要基礎。例如，本書描述了模型-視圖-控制器（MVC）模式，該模式應用於許多領域，也是一些新模式（如MVVM）的基礎。
• 深耕模式和反模式: 若是你已經知道了全部的基本GoF模式，那麼能夠用更多的軟件設計模式擴展你的知識. 或者深刻你感興趣的領域。我最喜歡的應用程序集成相關的內容之一是Gregor Hohpe編寫的「企業集成模式」一書。本書適用於兩個不一樣環境的應用程序須要交換數據時，不管是一些傳統系統的舊式文件交換仍是現代微服務體系結構。
• 瞭解質量測量: 定義架構遠不是終點。指引手冊和編碼標準的定義、應用和管理是有緣由的，這麼作是由於質量和非功能性需求。你想擁有一個可維護、可靠、可適應、安全、可測試、可擴展、可用等的系統，而實現全部這些質量屬性的一個方法就是應用好的架構工做。你能夠在維基百科上了解更多關於質量衡量的信息。理論很重要。若是你不想成爲一名站在空中樓閣上的架構師，那麼實踐一樣重要，甚至更重要。
• 嘗試瞭解不一樣的技術棧: 這是成爲一個更好的架構師的一項重要工做。嘗試新的技術棧並至上而下的學習他們。不一樣的技術能夠給你帶來不一樣的設計理念和模式。對新技術的學習最好不要浮於表面，應該去多實踐深刻感覺解決的痛點和其存在的問題。架構師不只須要涉獵普遍，在某些領域也要有深厚的知識。 固然並不須要掌握全部的技術，你須要對你所在領域最核心的技術有紮實的瞭解。 你也能夠嘗試其餘領域的技術,例如, 若是你深刻SAP R/3，你就應該也去嘗試一下JavaScript，反正亦然。時刻保持好奇心並付諸實踐。還能夠去試一些你討厭了不少年的技術。
• 分析和理解應用模式: 看一下當前的任一比較流行的框架，例如Angular。 能夠在實踐中研究不少模式，例如「觀察者模式」。 嘗試瞭解它如何在框架中應用，爲何要這樣作。 若是真的頗有時間且認真，能夠更深刻地瞭解代碼並瞭解其實現方式.
• 加入一些用戶組. Meetup

(2) 決策能力

架構師須要可以作出決策並將項目或整個組織引導到正確的方向。

• 知道重點: 不要把時間浪費在不重要的決定或者行爲上。學會抓住重點。據我所知，目前尚未一本書講這方面的內容。我的評估某件事是否重要，一般考慮以下兩點:

  1. 概念完整性：即便您決定以一種方式作到這一點，堅持下去，即便有時以其餘方式更好地作到這一點也是如此。 一般，這會讓概念總體上更簡單，簡化可理解性並簡化維護性。
  2. 一致性：例如，若是您定義並應用命名約定，它就無關於大小寫，而是以相同的方式在任何地方應用它。
• 優先級: 有些決定是很是關鍵的。若是不盡早決策，會產生不少冗餘到後期不太能刪除的方案，致使維護困難，甚至於致使開發人員沒法繼續開發，直到給出決策。這種時候，每每給出壞的決定好於沒有決定。固然，遇到這種狀況時優先選擇當前方案中的最優解。這裏我建議看看在敏捷軟件開發中普遍使用的加權最短做業優先（WSJF）模型。尤爲是時間關鍵性和風險下降是評估體系結構決策優先級的關鍵。
• 明確本身的職責: 不要決策在你能力或者職責範圍以外的事情。這是相當重要的，若是不考慮的話，它可能會嚴重破壞你架構師的地位。爲了不這種狀況，必定要於你的夥伴們明確你承擔的責任及角色。若是架構師不止一個，那麼你應該尊重當前的組織架構。做爲級別低的一方，最好是給出建議不是決策。此外，我建議始終和同伴一塊兒評審關鍵決策。
• 評估多個選項: 在決策時，必定要有一個以上的選擇。在我參與的大多數案例中，有不止一個（好的）選擇。只有一個選擇是很差的，兩個方面:首先，彷佛你沒有作好你的工做，其次，它阻礙了作出正確的決定。經過定義度量標準，能夠基於事實而不是直覺（例如許可證成本或成熟度）比較選項。這一般會致使更好、更可持續的決策。此外，向不一樣的利益相關者推銷決策也更容易。此外，若是沒有正確評估選項，則在討論時可能會遺漏一些因素。

(3) 化繁爲簡能力

請記住Occam剃刀的解決問題的原則，它表示更喜歡簡單。我把這個原則解釋爲：若是你對這個問題有太多的假設要解決，那麼你的解決方案多是錯誤的，或者致使沒必要要的複雜解決方案。爲了獲得一個好的解決方案，應該減小（簡化）假設。

• 方案規整:

爲了簡化解決方案，從不一樣的位置角度評估它們一般有助於清理、規整解決方案。嘗試經過自上而下和自下而上的思考來造成解決方案。若是您有一個數據流或進程，那麼首先考慮從左到右，再從右到左。能夠提出一些問題，好比：「在一個完美的世界裏，你的解決方案會怎麼樣？或者：「X公司/我的會怎麼作？「（其中X可能不是你的競爭對手，而是BAT（百度、阿里、騰訊）之一。）這兩個問題都迫使你減小Occam的Razor建議的假設。

• 退一步:

通過激烈和長時間的討論，得出的結果每每是高度複雜的草案。你永遠不該該把這些看做是最終的結果。退一步：再看一眼大局（抽象層面）。仍是有意義的嗎？而後在抽象的層次上再進行一次重構。有時，中止討論並在次日繼續討論會有幫助。至少個人大腦須要一些時間來處理和想出更好、更優雅和更簡單的解決方案

• 分而治之: 把問題分紅小塊來簡化。而後獨立解決。而後驗證這些小塊是否匹配在一塊兒。退一步看一下這個的總體狀況。
• 重構不是壞事: 若是找不到更好的主意，從更復雜的解決方案開始徹底能夠。若是解決方案遇到麻煩，您能夠稍後從新考慮解決方案並應用您的學習。重構不是邪惡的。 可是在開始重構以前，請記住要進行如下工做：（1）進行足夠的自動化測試，以確保系統的正確功能；以及（2）從利益相關者的支持。 要了解有關重構的更多信息，建議閱讀<<重構。 改進現有代碼的設計>>，做者是Martin Fowler。

(4) 編碼能力

即便做爲一個企業級架構師，最抽象的架構層次，你仍然應該知道開發人員天天都在作什麼。若是你不明白這是怎麼作到的，你可能會面臨兩大問題:

1. 開發者不會接受你的嘴炮。
2. 不瞭解開發人員的實踐需求和麪臨的困難.

• 有一個輔助項目: 這樣作的目的是嘗試新技術和工具，以瞭解當今和將來的開發方式。經驗是觀察，情感和假設的結合（Kurt Schneider的「軟件工程中的經驗和知識管理」）。閱讀教程或一些利弊是好的。但這僅僅是「書籍知識」。僅當你本身嘗試事物時，才能體驗到情緒並創建關於事物好壞的假設。並且，使用某項技術的時間越長，你的評估就會越準確。這將幫助您在平常工做中作出更好的決定。當我開始編程時，我沒有代碼完成，只有一些實用程序庫能夠加快開發速度。顯然，在這種背景下，我今天會作出錯誤的決定。今天，咱們擁有大量的編程語言，框架，工具，過程和實踐。只有您對主要趨勢有必定的經驗和粗略的瞭解，才能參與對話並引導開發朝正確的方向發展。

• 找到合適的東西去嘗試: 您沒法嘗試全部內容。 這根本是不可能的。 您須要一種更有條理的方法。 我最近發現的一種來源是ThoughtWorks的Technology Radar。 他們將技術，工具，平臺，語言和框架分爲四類：採用，試用，評估和保留。 經過這種分類，更容易得到新事物的概述及其準備狀況，以更好地評估下一步要探索的趨勢。

  • 採用: 「已經準備好提供企業級服務」
  • 試用: 「可以在一個承擔必定風險的項目中嘗試」
  • 評估: 「還需進一步評估其對業務的影響」
  • 保留: 「謹慎處理「

(5) 文檔架構能力

架構文檔有時更重要，有時則不重要。重要的文檔例如體系結構決策或代碼指南。在開始編碼以前一般須要初始文檔，而且須要不斷改進。其餘文檔能夠自動生成，由於代碼也能夠是文檔，例如UML類圖。

• 代碼整潔: 若是作對的話，代碼是最好的文檔。 一個好的架構師應該可以區分好的代碼和壞的代碼。 羅伯特·C·馬丁（Robert C. Martin）所著的<<代碼整潔之道>>一書是瞭解更多關於好壞代碼的寶貴資源。.
• 儘量生成文檔: 系統變化很快，很難更新文檔。不管是關於api仍是以CMDBs（配置管理數據庫）形式出現的系統環境：底層信息一般變化太快，沒法手動更新相應的文檔。例如：對於api，若是您是模型驅動的，則能夠基於定義文件自動生成文檔，或者直接從源代碼生成文檔。有不少工具存在，好比Swagger和RAML是一一些不錯的初始選擇。
• 必要而精簡:不管您須要記錄什麼文件（例如決策文件），都應嘗試一次只關注一件事，而且僅包含關於這件事的必要信息。 大量的文檔很難閱讀和理解。 附加信息應存儲在附錄中。 特別是對於決策文件，講一個有說服力的故事而不是僅僅發表大量論據，更爲重要。 此外，這爲您和您的同事節省了不少時間，然後者須要閱讀。 看看您過去作過的一些文檔（源代碼，模型，決策文件等），而後問本身如下問題：「是否包含全部必要的信息才能理解它？」，「確實須要哪些信息，而且 能夠省略嗎？」和「文檔中是否有紅線？」。
• 瞭解有關架構框架的更多信息: 該點也能夠應用於全部其餘「技術」點。 我把它放在這裏，是由於TOGAF或Zachmann之類的框架正在提供「工具」，這些工具在文檔站點上感受很沉重，儘管它們的附加值並不限於文檔。 在這樣的框架中得到認證能夠教會您更系統地解決體系結構。

(6) 溝通能力

根據個人觀察，這是最被低估的技能之一。若是你在設計上很聰明，但不能傳達你的想法，你的想法可能會影響較小，甚至沒法成功。

• 學習如何傳達你的想法:

在會議上進行協做時，知道如何正確的溝通傳達你的想法，將其同步到你的同行是相當重要的。 我發現《 UZMO-用筆思考》是提升我在這一領域技能的好資源。 做爲架構師，你一般不只會參加會議，並且一般須要主持並主導會議。

• 大型的演講: 將你的想法呈現給小型或大型團體應該對您來講可行。 若是對此感到不舒服，請開始向你最好的朋友介紹。慢慢擴大小組。 這是你只能經過離開本身的溫馨區來學習的東西。 請耐心等待，此過程可能須要一些時間。
• 找到合適的溝通方式: 不一樣的利益相關者有不一樣的利益和觀點。它們須要在各自的層面上用不一樣的方式單獨解決。在你交流以前，退後一步，檢查你想分享的信息是否有正確的層次，關於抽象性、內容、目標、動機等。例如：開發人員一般對解決方案的很是小的細節感興趣，而經理則更喜歡知道哪一個選項能節省最多的錢。
• 常常溝通: 若是沒有人知道，再香的架構也是毫無心義的。按期在每一個組織級別上分發目標體系結構及其背後的思想。安排與開發人員、架構師和管理人員的會議，向他們展現所需或定義的方式。
• 透明: 按期交流只能部分緩解缺乏的透明度。 您須要使決策背後的緣由透明化。 特別是，若是人們不參與決策過程，則很難理解和遵循其背後的決策和理由。
• 隨時準備發表演講: 總有人有疑問，你想立刻給出正確的答案。儘可能把最重要的幻燈片放在一個統一的集合裏，你能夠展現和解釋。它爲你節省了不少時間，也給你本身帶來了安全感。

(7) 評估能力

• 瞭解基本項目管理原則:

做爲架構師或首席開發人員，您常常被要求估算實現您的想法：多長時間、多少人、多少人、哪些技能等。？固然，若是你計劃引入新的工具或框架，你須要對這些「管理」問題有一個答案。最初，你應該可以給出一個粗略的估計，如天，月或年。別忘了，它不只僅是關於實現，還有更多的因素要考慮，好比需求管理、測試和Bugfix。所以，您應該瞭解所使用的軟件開發過程當中的工做。經過過去的使用數據，你能夠獲得更好的評估，並從中得出你的預測。若是你沒有過去的數據，你也能夠嘗試一些方法，如巴里W鮑姆的COCOMO。若是你被分配在一個敏捷項目中，學習如何正確地進行評估和計劃：Mike Cohn的《敏捷評估和計劃》一書提供了這個領域的一個堅實的概述。

• 評估「未知」架構: 做爲架構師，您還應該可以評估體系結構對於當前或將來上下文的適用性。這不是一項簡單的任務，可是您能夠經過手頭的一組問題來準備，這些問題對於每一個架構都是常見的。它不只關乎體系結構，還關乎系統的管理方式，由於這也讓您瞭解了系統的質量。我建議老是準備好一些問題並準備好使用。通常問題的一些想法:

  1. 設計實踐: 架構遵循哪些模式？它們是否獲得正確使用？設計是否遵循紅線或是否存在不受控制的增加？是否有明確的結構和關注點的分離？
  2. 開發實踐: 制定並遵照規範指南？代碼的版本是怎樣的？部署實踐？
  3. 質量保證: 測試自動化覆蓋範圍？靜態代碼分析到位且效果良好？同行評議到位？
  4. 安全性: 有哪些安全概念？內置安全？滲透測試或自動安全分析工具到位並按期使用？

(8) 平衡能力

• 質量是有代價的: 早些時候我談到了質量和非功能性需求。若是過分使用架構，將會增長成本，並可能下降開發速度。你須要平衡架構和功能需求。應避免過分設計。
• 解決矛盾目標:

矛盾目標的典型例子是短時間和長期目標。項目每每傾向於構建最簡單的解決方案，而架構師考慮的是長期的遠景。一般，簡單的解決方案不適合長期的解決方案，而且有可能在之後被丟棄（沉沒成本）。爲了不實施方向錯誤，須要考慮兩件事:

1. 開發人員和業務部門須要瞭解長期願景及其好處，以便調整其解決方案。
2. 負責預算的經理須要參與進來，以瞭解財務影響。不必定要把100%的長遠眼光直接放在適當的位置，但開發出來的成本大致在預算範圍內。

• 衝突管理: 架構師每每是不一樣背景的多個羣體之間的粘合劑。這可能會致使不一樣層次的溝通衝突。爲了找到一個平衡的解決方案，同時也反映長期的戰略目標，架構師的角色每每是幫助克服衝突。 關於傳播理論的起點是舒爾茨·馮·圖恩的「四耳模型」。 基於此模型，能夠顯示並推論不少。 可是，該理論須要一些實踐，在交流研討會上應該有經驗。

(9) 指導、答疑能力

在諮詢和輔導方面，積極主動多是最好的選擇。若是有人問你，那就太晚了。架構重構是儘可能要避免的。你須要以某種方式預見將來幾周、幾個月甚至幾年，併爲下一步作好準備。

• 有遠見: 若是你參與在一個項目中，不管是傳統的瀑布式方法仍是敏捷方法，你始終須要對要實現的中長期目標有一個願景。 這不是一個詳細的概念，而是針對每一個人均可以落地的路線圖。 因爲沒法一次完成全部工做（這是一段旅程），所以我更喜歡使用成熟度模型。 它們給出了易於使用的清晰結構，而且每次都給出了當前的進度狀態。 對於不一樣的方面，我使用不一樣的模型，例如 開發實踐或持續交付。 成熟度模型中的每一個級別都有明確的要求，這些要求遵循SMART準則，以便輕鬆衡量是否已達到要求。 我發現一個很好的例子是持續交付。
• 創建實踐社區（CoP）: 在一個共同興趣小組之間交流經驗和知識有助於分發思想和標準化方法。 例如，你能夠每三個月左右將全部JavaScript開發人員和架構師彙集在一個房間中，討論過去和當前的挑戰以及如何解決它們或採用新的方法論和方法。 架構師能夠共享，討論和調整其願景，開發人員能夠共享經驗並向同行學習。 這樣的交流不只能夠爲企業帶來極大的好處，並且對我的自己也很是有利，由於它有助於創建更強大的網絡並傳播思想。 還能夠查看SAFe框架中的文章實踐社區，該文章在敏捷環境中解釋了CoP概念。
• 進行公開會議: 誤解或模棱兩可的一個緣由是缺少溝通。在固定的時間段內，例如每週30分鐘，與同事交流熱門話題。此次會議沒有議程，一切均可以討論。儘可能當場解決小事。安排對更復雜主題的跟進。

(10) 營銷推廣

你的想法很好，你已經很好地溝通了，可是仍然沒有人願意追隨？那麼你可能缺少營銷技巧。

• 激勵和說服: 公司如何說服你購買產品？ 他們證實了它的價值和好處。 但不止如此。 他們包裝得很好，並使其儘量容易消化。

  1. 原型: 展現你想法的原型。有不少建立原型的工具。在喜歡SAP的企業背景下，能夠查看build.me，在其中您能夠快速輕鬆地建立漂亮且可點擊的UI5應用程序。
  2. 視頻: 與「無聊的PPT」不一樣的是，你還能夠播放一段視頻，展現你的想法或至少方向。

但請不要過分營銷：從長遠來看，內容是王道。若是你的話沒有實現，從長遠來看，這將損害你的聲譽。

• 堅持本身的想法:

有些時候人們不喜歡你的想法，或者他們太懶了，不喜歡你的想法。若是你真的被本身的想法所說服，你就應該不斷地去追求它們，並「戰鬥」。有時這是必要的。具備長期目標的架構決策一般不是最簡單的：開發人員不喜歡它們，由於它們更復雜。經理們不喜歡他們，由於他們在短時間內更貴。這是你的工做，你要堅持和談判。

• 尋找盟友: 創建或執行你本身的想法多是困難的，甚至是不可能的。努力尋找可以支持和幫助說服他人的盟友。使用你的網絡。若是你尚未，如今就開始建造它。你能夠先和你的（思想開放的）同齡人談談你的想法。若是他們喜歡，或者至少部分喜歡，若是別人問他們，他們極可能會支持你的想法（「X的想法頗有趣。」）。若是他們不喜歡，問爲何：也許你錯過了什麼？或者你的故事不夠有說服力？下一步是找到有決策權的盟友。要求開誠佈公的討論。若是你懼怕討論，記住有時候你須要離開你的溫馨區。
• 重複一遍，相信它: 「[…] 研究代表，反覆接觸某個觀點會令人們相信該觀點更爲廣泛，即便該觀點僅來自一我的也是如此。」（來源：《金融品牌》）若是您常常發佈不多的信息，則能夠幫助您 說服人們更容易。 但請注意：從個人角度來看，應該明智地使用這種策略，由於它可能拔苗助長，成爲糟糕的營銷技巧。

架構師的技術路線圖

相關書籍

• Refactoring. Improving the Design of Existing Code by Martin Fowler
• Enterprise Integration Patterns written by Gregor Hohpe
• Design Patterns: Elements of Reusable Object-Oriented Software by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma
• Experience and Knowledge Management in Software Engineering by Kurt Schneider
• Clean Code by Robert C. Martin
• UZMO — Thinking With Your Pen
• Agile Estimating and Planning by Mike Cohn