作者 | Pierre Pureur, Kurt Bittner譯者 | 平川策劃 | 丁曉昀軟件架構在敏捷社區中存在爭議。在許多人的經驗中 架構隻會導緻毫無價值的會議和無關緊要的文件 軟件架構可能不是你想象的那個樣子 - 趣味新聞網

作者 | Pierre Pureur, Kurt Bittner

譯者 | 平川

策劃 | 丁曉昀

軟件架構在敏捷社區中存在爭議。在許多人的經驗中，架構隻會導緻毫無價值的會議和無關緊要的文件，“地圖不是領土”的說法可以恰當地概括這一觀點。然而，架構不佳的應用程序很快就會變得像被遺棄在路邊的車輛一樣，破損且無法修復。那麼，在毫無意義的兩極之間是否有一個有用的中間地帶呢？

産生這個問題的一部分原因是，對於軟件係統架構工作的成果來說，建築設計是一個不恰當的比喻。對照建築設計師的工作，這個詞會讓人聯想到預示著烏托邦式美好未來的設計。但是，軟件係統的架構遠比建築架構更富於變化。建築物是靜態的，建築設計師的工作隻做一次。軟件，就其本質而言，是不斷變化的、動態的；當它停止變化時，就開始走嚮死亡瞭。

為瞭更好地理解軟件架構，我們有必要追溯下建築師（architect）這個詞的起源。它來自於古希臘詞 arkitekton，即 ρχι-（arkhi-，“chief”）+ τ κτων（téktōn，“builder”）。建築是由建造東西的人創造的。在建築設計師的工作中，這種意義已經消失瞭。他們中的許多人從未澆築過地基，也沒有為建築物搭過框架，更沒有安裝過水管或暖氣管。設計和建造已經被分開瞭。但在軟件領域卻不是這樣，構建方式會影響到構建內容，反之亦然。

1

軟件架構關乎決策，而非結構

以建築物作類比導緻一些軟件架構師過於關注結構和行為，而不是産生這些結構和行為的決策。這並不是說結構和行為不重要，而是它們是思想過程的結果。如果係統要隨著時間的推移持續演進，就必須保留這個思想過程。知道某人為什麼做某事與知道他們做瞭什麼同樣重要。如果代碼組織得很好並且有注釋的話，那麼它們所做的事情應該很容易從代碼中看齣來，但是為什麼要這樣做卻常常被忽略。

其原因是，軟件的架構決策很少是一目瞭然的；幾乎每一個架構決策都是在相互競爭的備選方案之間做齣妥協。而且，有一些備選方案，如果你不嘗試一下，看看它們是如何工作的，就很難看齣它們的優點。知道試過什麼，放棄瞭什麼，往往比知道什麼有效更有價值。有句老話說得好，好的判斷來自於經驗，而大部分的經驗來自於壞的判斷。

這也是為什麼軟件架構師必須仍然是開發人員的原因之一；如果不開發和測試一些東西，他們就無法理解或預測係統中的影響因素。軟件架構師不應該作為某種酬金，付給那些已經從活躍的開發中退齣，但擁有的知識被組織認為仍然有價值的人；它的意義應該不止於此。架構工作需要對係統有足夠的瞭解，以便能夠提齣有益於質量屬性的假設，還需要有編寫代碼和設計測試以評估假設的專業知識（或與能夠評估這些假設的團隊成員緊密閤作）。

2

架構是一項技能，而架構師不是一種角色

事實上，就工作性質而言，使用像軟件架構師這樣的頭銜傳達瞭錯誤的信息。現實情況是，很多軟件開發人員都在做架構工作，隻是他們沒有意識到這一點。隻要他們對如何滿足質量屬性做齣決策，就會影響到係統的架構。充分瞭解背後的決策如何影響係統實現質量目標的能力，是改進係統架構的第一步。

那麼，人們需要掌握什麼樣的技能來提高其架構工作的質量呢？有以下幾個方麵：

多關注質量屬性，這是好的架構應該解決的關鍵的橫切（cross-cutting）需求。功能需求很容易受到團隊關注，因為它們往往是有形的，甚至是係統幫其用戶做的一些肉眼可見的事情。但是，係統的質量屬性決定瞭它是否能長期存在下去，如可擴展性、性能、安全性、承載能力和可維護性，等等。

有能力將整個係統的問題概念化並加以解決。質量屬性往往是由能影響整個係統而不是僅僅影響某個部分的因素決定的。雖然模塊化設計和關注點分離對構建良好的係統至關重要，但它們也使團隊成員更難對係統有一個整體的認識。

理解係統的完整生命周期。這就要求我們不僅要有開發係統的經驗，還要有測試係統、部署係統、在生産環境中運行係統、長期維護係統的經驗，以及在係統需要重大創新時對其進行實質性的現代化改造。瞭解係統的生命周期以及它如何應對變化，對於做齣明智的決策，限製技術債務至關重要，因為隨著時間的推移，技術債務會威脅到係統的生存。

平衡關切以及調和摺中的能力。架構工作很少會有正確答案。架構經常涉及到在相互衝突的質量屬性要求（QAR）和約束條件之間做齣權衡。

從經驗中學習和閤成新方法的能力。這種能力是指直接進行嘗試（運行實驗），並將實驗結果概括為可以進一步指導實驗的原則。其中一些原則采取瞭“標準”形式。這個術語有點誤導性，因為標準需要不斷地通過實驗來檢驗，以確定它們何時不再有用。我們看到，許多開發人員對組織的“標準”感到沮喪，因為它們在過去某個時候是有意義的，但現在卻把團隊睏在瞭過去。

展示領導力的能力。能夠提齣關注點，能夠讓持有不同觀點的人展開討論並達成共識，這有助於團隊麵對並剋服復雜的架構問題。團隊中的任何人都可以這樣做，而任何負責架構設計的人都必須做到這一點。

3

架構意味著持續探索

現代軟件應用程序架構設計是一項基礎性的探索活動。現如今，構建應用程序的團隊每天都會遇到新的挑戰：前所未有的技術挑戰，以及為客戶提供解決新問題和其他各種問題的新方法。這種持續性的探索意味著架構不能根據過去的經驗預先確定；團隊必須找到滿足質量要求的新方法。

關於探索對於架構發現的重要性，請考慮這樣一個例子：假設你是一個從事軟件係統開發工作的團隊的一員。根據最初的設計，該係統是為瞭處理存儲在 SQL 數據庫中的結構化錶格數據。現在，這個係統需要增強，以便可以處理非結構化數據，包括圖像和視頻，而且數據量預計會比係統目前處理的多得多。你考慮在技術棧中引入 NoSQL 數據庫來處理新的數據類型，但由於你的團隊在這項技術上沒有多少經驗，所以要選擇閤適的數據庫産品，進行配置並滿足新的數據量要求，實驗必不可少。

在團隊解決這些技術問題的過程中，關於哪些方法能最好地滿足所期望的 QAR，他們形成瞭自己的假設，這些假設會隨著時間變化。他們構建一部分解決方案來檢驗這些假設，並根據結果做齣決策。這些關於如何滿足 QAR 的決策疊加起來就是係統的架構。團隊可能會以不同的方式溝通這些決策，包括使用文檔和圖錶。但是，文檔和圖錶不是架構，重要的是決策以及做齣決策的原因。

關於這些決策，以下信息很重要：

如果有必要的話，說明推翻一項決策的成本。如果你必須更換一個服務、一個 DBMS、甚至一個框架，那麼要知道更換的代價有多大。在某些情況下，這可能意味著重寫應用程序。

清楚地闡明所有限製或假設。瞭解使用約束和假設可能會幫助到將來要對你的工作進行更新的團隊。例如，知道你做瞭並發用戶個數不超過 X 的假設，並導緻你對並發綫程或進程做齣某些決定，這有助於你未來的同事瞭解，如果超過這個約束，他們可能需要做齣什麼改變。

你是如何滿足具體的質量屬性要求（QAR）的。對於每個 QAR，你應該描述你做瞭什麼來確保它可以得到滿足，不僅僅是在理論上，還要說明你運行瞭什麼測試來證明。鏈接到具體的測試用例及其相關的自動測試。這樣，當 QAR 發生變化時，就能夠很容易地重新評估係統的架構質量。

在做齣決策之前，你考慮過哪些選項。知道你考慮瞭什麼以及放棄瞭什麼，往往比知道你最終的決策更有用；它展示瞭你的思考過程，其他人可以從中看齣你做決定時可能受到瞭什麼樣的限製。如果這些限製將來消失瞭，那麼知道你為什麼做齣某些決策將有助於未來的開發者做齣更好的決策。

圖 1：QAR、決策和技術債務的關係

在知情的情況下産生瞭哪些技術債務。有些決策將不可避免地導緻技術債務；例如，使用 SQL 數據庫來滿足可靠性目標的決策會對技術債務有一些副作用（見圖 1）。現在，早已成為過去式的“韆年蟲問題”就源於開發人員當時有意識的決策。為瞭減少瞭數據存儲、內存使用和處理時間，他們在存儲標準日期時沒有存儲世紀數據。産生這個問題的原因是，他們沒有想到應用程序會存在這麼久，在那些限製不閤時宜之後還存在很長時間。如果他們能更準確地傳達他們的決策並描述潛在的影響，可能人們就不會在上個世紀末齣現如此強烈的反應。

4

小結

作為一門學科，軟件架構需要做齣徹底的改變。人們對它的看法受製於很多關於它需要解決什麼問題以及它應該如何去解決這些問題的舊觀念。將軟件架構視為一項持續性活動，緻力於做齣關於係統如何滿足質量屬性的假設，然後通過實證來證明係統能滿足這些屬性，這是軟件架構持續性方法的根本所在。同樣需要改變的是，將軟件架構從與開發脫節的委員會中分離齣來，交到能夠真正實現並使其變成可執行程序的人（開發人員）手中。隻有這樣，我們纔能從如今的應用中獲得我們需要的彈性和可持續性。

作者簡介：

Pierre Pureur 是一位經驗豐富的軟件架構師，擁有廣泛的創新和應用開發背景，和金融服務行業有廣泛的接觸，擁有廣泛的谘詢經驗和全麵的技術基礎知識。他過去曾擔任一傢大型金融服務公司的首席企業架構師，領導大型架構團隊，管理大規模並發應用開發項目，指導創新舉措，以及製定戰略和商業計劃。他與人閤著瞭“Continuous Architecture in Practic”（2021）和“Continuous Architecture”（2015）。他還就這一主題發錶瞭許多文章，並在多個軟件架構大會上發錶演講。

Kurt Bittner 有超過 30 年在反饋驅動的短周期內交付可工作軟件的經驗。他曾幫助各種組織采用敏捷軟件交付實踐，包括大型銀行、保險、製造和零售組織，以及大型政府機構。他曾為甲骨文、惠普、IBM 和微軟等大型軟件交付機構工作或與之閤作，並曾擔任 Forrester Research 的科技行業分析師。他的主要工作是幫助企業建立強大的、自組織的高效團隊，提供客戶喜愛的解決方案。他寫瞭四本軟件開發主題相關的著作，其中包括 The Nexus Framework for Scaling Scrum。他在科羅拉多州博爾德市工作，擔任 Scrum.org 的企業解決方案副總裁。

https://www.infoq.com/articles/what-software-architecture/