爲什麼你需要關注軟件架構？

作者 | Pierre Pureur, Kurt Bittner

譯者 | 明知山

策劃 | 丁曉昀

軟件開發團隊一直反對 “前期大設計”，而傾向於自組織團隊中出現的架構設計，這可能導致低估軟件架構重要性的心態。更多地意識到架構當中存在的隱式決策，並迫使這些決策變成顯式的，有助於開發團隊做出更好、更明智的決策。

1 關鍵要點

• 軟件開發人員通常不信任架構實踐，傾向於避開有意識的架構活動，並選擇在自組織團隊中出現的架構設計；

• 爲解決緊急架構的侷限性和滿足最初的質量屬性需求，進行有意識的架構設計是有必要的；

• 軟件架構是由質量屬性需求 (Quality Attribute Requirements，QAR) 驅動的，如果在最初的迭代中沒有考慮到它們，通常會在軟件系統被部署到初始試驗階段之後（只有少量的用戶）出現問題；

• 更多地意識到架構當中存在的隱式決策，並迫使這些決策變成顯式的，這有助於開發團隊利用他們從 Sprint 和迭代中獲得的經驗數據做出更好、更明智的決策；

• 重構和過度的組件化會導致解決方案的碎片化，以至於沒有人能完全理解發生了什麼；

• 現代架構實踐，如持續架構和演進架構，提供了可以幫助做出顯式架構決策的工具，讓開發人員能夠交付更可持續的軟件產品。

許多軟件開發人員不信任架構實踐，他們將這些實踐與嚴格和專橫的過程以及重要的前期規劃和設計聯繫在一起。

因此，他們相信，如果他們遵循這些實踐，可能需要很長時間才能交付一些甚至可能不是客戶想要的東西。

他們更願意專注於理解客戶的需求，並通過小而快速的敏捷迭代過程來交付產品。

他們當中有一些人相信，只要遵循了這些過程，架構自然會 “出現”，而不需要有意識地進行計劃或架構設計。因爲存在這些信念，他們可能不認爲軟件架構是重要的，甚至可能不關心它。

這種架構方法通常可以交付滿足客戶所需的產品，這是一個好的開始。

但是，如果不顯式考慮產品的可持續性，它就有可能衰退，導致產品在自然退役前無法維護。

通過關注關鍵的質量屬性，如性能、可伸縮性、安全性和彈性，有意識的軟件架構方法有助於延長產品的生命週期，使其在更長的時期內可持續。

預先架構和緊急架構對比

如果我們正在做的事情是我們非常瞭解的，並且已經做過很多次了，那麼預先設計方法就很有效。例如，建造摩天大樓、挖運河、生產產品或建造橋樑。我們可以應用 “最佳實踐”，並依賴過去已經在這些事情上驗證過的有效方法。

如果我們正在處理一些東西是全新的，並且我們不太瞭解，或者變化太快以至於還沒有 “最佳實踐”，那麼預先設計就不起作用了。在這種情況下，作爲科學革命基礎的可控性實驗可以幫助我們更深入地理解問題和可能的解決方案。最終的解決方案“出現” 了，只是它沿着有意識的實驗的路徑向我們招手。

這兩種方法都是有價值的，但適用的場景非常不同，一種可用於處理大部分已知的事情，而另一種可用於在變化的世界中探索新的機會和可能性。

第二種方法的問題在於，可控性實驗可能無法在合理的時間內產生可持續的解決方案，並且可能需要進行可接受的返工。軟件架構實踐可以通過更早地提出更好的問題來指導實驗，以減少交付可持續產品的時間和成本，並仍然可以保留敏捷方法的優勢。

2 架構是如何出現的

正如我們在前一篇文章中所討論的，架構的本質由一組定義和約束產品技術面的決策組成。無論團隊採用哪種方法，無論他們是有意識地還是心照不宣地做出決定，這些決定都是存在的。這些決策專注於產品如何處理質量屬性需求（QAR）。

QAR 也可以是顯式或隱式的，儘管顯式的更容易處理並可以確保產品契合它們。例如，用戶通常希望在使用產品時能夠得到及時響應，而不管有多少人也在使用該產品。顯式地聲明 “響應性” 需求以及產品可以支持多少併發用戶而不會變成 “無法應式” 的，將有助於開發團隊對他們的技術方法做出更好的決策，比如 “系統的速度必須夠快” 或“系統必須是可伸縮的”這樣的聲明並不能幫助團隊做出更好的技術決策。

評估質量屬性需求和設計一個架構來實現這些需求涉及到一些前期規劃，這些也是軟件系統取得成功的關鍵驅動因素，原因如下：

• 軟件架構是由質量屬性需求驅動的，如果在最初的迭代中沒有考慮到它們，通常會在軟件系統被部署到初始試驗階段之後（只有少量的用戶）出現問題。因此，當必須滿足關鍵的質量屬性需求 (如性能、安全性或可伸縮性) 時，可能需要進行重要的架構、設計和代碼重構，這可能會出現具有高度易變性的軟件架構。此外，如果架構設計沒有強有力地實現組件的抽象和隔離，重構的成本可能會飆升。

• 爲解決緊急架構的侷限性和滿足最初的質量屬性需求，進行有意識的架構設計是有必要的。例如，除了提供關於系統實際使用情況的有用信息以及關於架構設計的反饋迴路之外，在初始架構設計中加入一個簡單的監控框架，這對於確保軟件系統的彈性和正確性來說是至關重要的。

• 重構和過度的組件化會導致解決方案的碎片化，以至於沒有人能完全理解發生了什麼。有可能不知道正在使用的組件是什麼版本，也可能沒有記錄每個組件的服務水平協議 (Service Level agreement，SLA)。微服務架構爲每個服務使用了單獨的數據存儲，這可能會導致數據一致性問題。單體系統的可持續性較差，但具有高度的內部一致性。這兩種架構各有優缺點。

3 你的軟件系統是可持續的嗎?

廣義地說，實現 “可持續性” 是軟件產品架構工作的重點。如果軟件產品能夠滿足當前需求 (包括 QAR)，而不損害滿足未來需求的能力，則可以認爲該軟件產品是可持續的。正如我們在前一節中所述，質量屬性需求驅動了架構，滿足關鍵 QAR 對於創建可持續的架構設計來說是至關重要的。不幸的是，隨着功能增強的實現和新設計決策的制定，軟件系統會隨着時間的推移而 “磨損”，這可能會延展甚至破壞最初的架構設計。常見的“磨損” 原因包括：

• 由於維護系統的開發人員對系統缺乏理解，最初的設計決策也就過時了。與系統設計相關的決策和假設很少會被準確地記錄下來。當人們不再針對系統提出問題或回答問題時，軟件系統就開始衰退了。提出問題是評估軟件系統健康狀況的一種重要技術，如果有知識資源可以回答這些問題的話。

• 技術債務的累積會導致系統維護不再可行或不再具有成本效益，並且無法實現新的功能。

• 開發人員試圖重用不同組件的代碼塊，他們認爲可以通過對複用代碼進行微小的改動來實現新功能。遺憾的是，他們可能無法完全理解原始代碼所依賴的架構上下文，也意識不到在不同的組件中重用代碼可能會在以後產生不必要的副作用，例如性能、可伸縮性或可用性問題。這些軟件變更增加了技術債務，並降低了系統的整體質量，除非技術債務能夠迅速得到解決。

• 技術的發展導致一些軟件系統運行在不是爲它們設計的技術平臺上。一些較老的軟件系統經歷了 “災難性的成功”，因爲它們持續存在的時間比最初計劃的要長得多，而且它們的技術債務已經變得非常沉重、難以解決且代價巨大，“償還” 起來非常困難。償還技術債務的成本可能與完全替換該軟件系統的成本類似，甚至有過之而無不及。

• 失敗的假設。邏輯的主體，包括軟件系統，最終會因爲假設的失敗而崩潰，軟件開發人員可能沒有意識到他們所做的假設。隱藏的假設可以被認爲是對系統的約束。關鍵在於要清楚地闡明所有的假設，並保持信息的更新。質量屬性需求本身也是一種需要進行驗證的假設，它們的實現需要經過經驗的測試和確認，如果可能的話，可以使用自動化。性能、可伸縮性、彈性 (例如，使用類似於 Netflix 猴子軍團的框架) 和安全性都是很好的例子。質量屬性自動化測試的目標是持續對假設 (例如，實現 QAR 仍然是現實的嗎？) 進行測試，並用以指導軟件系統的演化。

如果對最初的架構沒有很好的理解，即使增加了新特性 (我們可以稱之爲 “架構熵定律”)，使用緊急架構創建的軟件系統最終也會失去架構完整性。因此，它們可能不再是可持續的。

4 評估軟件架構的適用性

如何知道你的軟件系統什麼時候磨損了，就像知道你的汽車輪胎什麼時候磨損了並需要更換一樣？就像醫生可能使用許多不同種類的工具來評估個體的健康狀況 (心電圖、MRI、CT、血液測試、體格檢查) 一樣，不同的工具可以幫助團隊評估軟件架構的適用性。舊的系統可能難以理解，因爲正如我們前面提到的，它們的設計決策和假設通常沒有文檔記錄，而即使存在文檔，也很可能是過時的。理解和評估系統的架構設計通常需要 “軟件考古” 工具和技能。總的來說，有很多工具可以用來評估軟件架構的適用性，包括：

• 架構評審 (特別是對等評審) 是評估軟件系統架構設計適用性的有效工具，特別是如果他們關注的權衡 (例如，來自 CMU/SEI 的架構權衡評估方法 (pdf))。

• 自動化的軟件質量評估工具 (例如 CAST)，但是人們需要接受它們生成的結果。

• 代碼評審 (特別是自動化代碼評審) 對於確保代碼質量來說非常重要。結對編程是實現這一目標的另一種方法。

• 適用性功能實現，例如自動化性能測試。

• 增強框架實現，包括 Web 服務監控工具，爲軟件架構提供反饋循環。

• 技術債務的識別和評估，包括標明會導致技術債務增加的決定。

• 自動化測試工具 (特別是負載 / 伸縮性 / 彈性測試)。

• 缺陷趨勢分析 (這是技術債務的代理)，需要使用一致的方式捕獲數據，目標是識別不穩定性。

• 生產事故趨勢分析——與缺陷趨勢分析具有相同的要求和目標。

• 安全測試工具。使用這些工具的目的是找出風險暴露點。

5 結論

在 “前期大設計” 和敏捷實踐之間長達 20 年的爭議中，軟件開發人員努力在這兩種方法之間找到一個有意義的平衡點，並從有意識的架構活動轉向自組織團隊的架構設計。因此，他們常常認爲軟件架構並不是那麼重要。更多地意識到架構當中存在的隱式決策，並迫使這些決策變成顯式的，這有助於開發團隊利用他們從 Sprint 和迭代中獲得的經驗數據做出更好、更明智的決策。現代架構實踐，如持續架構和演進架構，提供了可以幫助做出顯式架構決策的工具，讓開發人員能夠交付更可持續的軟件產品。

欲瞭解更多信息，請參考 Murat Erder、Pierre Pureur 和 Eoin Woods 合著的 “Continuous Architecture in Practice”，以及 Murat Erder 和 Pierre Pureur 合著的 “Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”。

作者簡介

Pierre Pureur 是一位經驗豐富的軟件架構師，擁有廣泛的創新和應用開發背景，豐富的金融服務行業經驗，廣泛的諮詢經驗和全面的技術基礎設施知識。他曾擔任一家大型金融服務公司的首席企業架構師，領導大型架構團隊，管理大型併發應用程序開發項目，指導創新活動，以及制定戰略和業務計劃。他是 “Continuous Architecture in Practice: Scalable Software Architecture in the Age of Agility and DevOps”(2021 年出版) 和 “Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”(2015 年出版) 的合著者，並發表了許多文章，還在多個軟件架構會議上做演講。

Kurt Bittner 擁有超過 30 年在短反饋驅動週期內開發軟件的經驗。他幫助許多組織採用敏捷軟件交付實踐，包括大型銀行、保險、製造和零售組織，以及大型政府機構。他曾爲包括 Oracle、HP、IBM 和微軟在內的大型軟件交付組織工作，曾是 Forrester Research 的技術行業分析師。他的工作重心是幫助企業建立強大的、自組織的、高性能的團隊，爲客戶提供他們喜愛的解決方案。他寫了四本關於軟件開發的書，包括 “The Nexus Framework for Scaling Scrum”。他現居科羅拉多州博爾德市，擔任 Scrum.org 的企業解決方案副總裁。

查看英文原文：

https://www.infoq.com/articles/care-about-architecture/?

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/JbsB7TxMSQh2gKrail9gWA