軟體架構可能不是你想象的那個樣子

作者 | 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/