爲何說咱們須要軟件架構圖？

軟件架構是一門學科，開始於 20 世紀 70 年代。面對不斷增長的複雜性和開發複雜實時系統的壓力，做爲主流系統工程和軟件開發的基本構造，軟件架構應運而生。與任何其餘久經考驗的學科同樣，軟件架構在誕生之初也面臨許多挑戰！

爲何說咱們須要軟件架構圖？軟件架構圖能幫咱們解決什麼問題？

• 經過建立和維護架構圖來提供準確且有價值的內容並不是易事。大多數狀況下，咱們要麼建立了太多的文檔，要麼太少，或者不相關，由於咱們沒能準確地定位文檔的受益人及其實際的需求。

• 咱們常犯的最大的一個錯誤是爲系統中具備高波動性的部分建立詳細的架構圖。除非是自動生成的，不然手動維護它們對咱們來講就是一種負擔。

• 在實踐中，大多數利益相關者對詳細架構圖不感興趣，但會對一兩個反映系統模塊和邊界的高級架構圖感興趣。除此以外，要深刻理解系統，代碼纔是事實的來源，但在大多數狀況下，只有開發人員會對代碼感興趣。

• 架構圖的主要目的應該是促進協做、加強溝通、提供願景和指導。

• 爲了建立具有必定質量的架構圖，能夠進行頭腦風暴，並與團隊就什麼對他們來講纔是真正有用的東西上達成一致。不要嘗試爲源代碼中不言自明的東西或爲了迎合架構方法而建立架構圖。

• 在牆上繪製一兩個高級架構圖並在會議（站會等）期間使用它們。做爲一名架構師，你應該讓它們可見，變得有價值，並做爲項目文化的一部分。不要將它們隱藏起來或放在利益相關者不易接觸到的地方。

    咱們嘗試經過建立架構圖（做爲技術文檔的一部分）來反映應用程序的內部狀態，但大多數時候咱們都沒能作對。由此產生的架構圖可能很是全面，也可能很是模糊。有時，架構圖根本就是不相關的。

    即便建立了相關的架構圖，咱們也不多更新它們，做爲持續開發過程的一部分。實際上，咱們只是時不時地更新文檔，多是在某些 sprint 期間（當有時間更新文檔時）或在發佈特定版本以前。另外一方面，大多數開發人員（參加個人軟件架構課程的同事或學生）不同意建立和維護技術文檔，他們認爲這些任務乏味、耗時，並且價值不如其餘任務，他們甚至認爲若是源代碼寫得足夠好，文檔不是必需的。雖然總會有例外，但我很肯定，在架構圖方面，對於大多數項目來講幾乎都是同樣的。

那麼，咱們用架構圖來作什麼？

    通常而言，架構圖和文檔應該主要用於團隊內部和團隊之間的協做、溝通、願景和指導。它們還應該包含項目的重要設計決策（在某個特定時刻採起）。

    架構圖應該幫助每一個人看到大局，瞭解周圍的環境。在我看來，這應該是建立和維護架構圖背後的根本緣由。

例如，上下文架構圖徹底知足了這種需求，並提供了關於系統邊界的大量細節，從而能夠看到全局。它有助於團隊在不一樣的利益相關者之間達成共識，並簡化溝通。我參加了不少會議，當大屏幕上出現這樣的上下文架構圖時，省去了不少問題，並消除了關於高級系統架構的不肯定性。

    不過，咱們常常會嘗試建立綜合性的文檔來反映系統的內部狀態，它們能夠是狀態圖、活動圖、類圖、實體圖、併發圖等形式。但這些很快就會過期，除非它們是基於源代碼經過一些「神奇」的工具自動生成的。

    所以，建立有意義的小型架構圖，並將它們加到技術文檔中。對於大多數應用程序，可能須要兩三種架構圖。最多見的是上下文圖、組件圖、系統圖或部署圖。

項目實例在項目中，我主要使用兩種類型的架構圖

上下文圖

應用程序或軟件組件圖

    

    請將這些圖視爲簡單的示例，主要做爲每種圖應該提供哪些合理信息的指導。圖中的信息應該與相應的抽象級別相關，還必須知足利益相關者的需求。

    在實踐中，你可能傾向於向圖中添加愈來愈多的細節，可是若是它們對利益相關者沒有真正的用處，就會致使額外的噪音，增長維護成本，並且容易過期。這些圖中的一些細節，例如協議和數據格式，可能對技術利益相關者來講比較方便，由於它們是必要的實現細節。然而，正如以前所述，並不存在精確的方法來肯定圖中包含多少數量的細節纔算是恰當的，這徹底取決於不一樣的項目。不過，架構師須要知道對利益相關者來講真正有用的是什麼，並建立和維護架構圖來正確地反映這一點。

    除了這些架構圖以外的任何額外細節，我能夠在源代碼中找到，或者經過某些工具自動生成（例如運行時視圖、開發視圖、系統或基礎設施視圖等）。

另外，請記住，團隊應該是架構圖的主要受益者。若是它們沒有表現出任何興趣，那麼你應該中止建立它們，由於這多是在浪費時間。咱們不該該只是「爲了擁有它們」，或者爲了遵循綜合性的架構方法，或者純粹爲了證實咱們做爲架構師的角色而去建立架構圖