譯者 | 劉汪洋

審校 | 重樓

一種常見但不完美的比喻是將軟件系統中的架構漂移和侵蝕與物理建筑的架構相比。雖然這個比喻很直觀，但它存在一個根本性的誤解，這也常常引發軟件開發中的架構問題。

試想一下，一個設計良好的摩天大樓或房屋建成后，我們期望它基本保持不變，頂多因為偶爾的現代化或擴建而發生變化。

令人驚訝的是，如今許多工程師（甚至可能是無意識地）將同樣的邏輯套用到軟件架構上：認為一旦系統架構設計完成，如果設計得當，它就不需要進一步修改，直到需求變化和遺留代碼迫使進行大規模重寫。

這是一個關鍵的誤解。與物理結構不同，軟件本質上是動態的，不斷變化，需要定期更新以保持活力。一旦軟件停止演變，就會開始衰亡。

此外，這種比喻通常強調軟件系統的結構和行為，但忽略了同樣重要的決策、權衡和妥協，這些因素共同塑造了架構。理解架構決策背后的原因對于未來的修改以及管理和演變軟件架構至關重要。

本文旨在加深你對架構技術債務的理解，并強調有效管理架構漂移和侵蝕的關鍵因素。

架構技術債務概述

“在軟件密集型系統中，技術債務指的是那些在短期內權宜的設計或實現，這些構造設置了一個技術背景，使得未來的變更更為昂貴甚至不可能。技術債務是一種或有負債，其影響主要限于系統內部質量，特別是可維護性和可演化性。” ——Avgeriou等人，2016年

技術債務總結了軟件開發中過去決策和捷徑累積的后果，包括低質量代碼、缺失的文檔和嚴重耦合等問題。這些問題可能源自多種原因，如戰略性權衡或需求的意外變化等。

盡管許多工程團隊記錄了他們管理技術債務的策略——如谷歌和 ThoughtWorks 的做法——但關于特定類型的技術債務，即架構技術債（ADT），討論較少。

ADT 源于系統設計過程中的有意或無意決策，導致維護性降低、復雜性增加、性能下降和可擴展性受限等問題。由于軟件架構定義了系統的關鍵屬性和約束，ADT 對系統演變及組織實現目標的能力構成重大風險。

ADT 是不可避免的，特別是在目標是快速交付和后續迭代時，有時甚至是必要的。因此，團隊必須識別 ADT 并實施有效管理策略，以防止架構退化——即逐漸變得過時、不可靠，無法適應不斷變化的業務需求或技術進步。

首先，關鍵的是在 ADT 的廣泛范圍內區分兩個獨特的現象：系統架構漂移和系統架構侵蝕。

架構漂移與架構侵蝕

架構漂移指的是在系統中引入不在原始架構計劃中的設計決策，但這些決策并不一定會違反基礎架構原則。架構侵蝕是指引入的新設計直接與系統的預期架構相沖突，破壞了系統的指導原則。

以建筑架構為比喻，架構漂移就像是建造一棟地中海風格的房子，然后添加一個哥特式的塔樓和一個后現代的擴建。這雖然導致了風格混雜（可能并不美觀），但不會破壞結構的完整性。

在軟件工程中，一個系統可能以干凈的架構開始，但由于架構漂移，最終演變成包含多種架構范式、不一致編碼實踐、冗余組件和依賴項的復雜結構。

深入探討架構漂移  by Vladi Stevanovic

另一方面，架構侵蝕類似于進行改造時破壞了房屋的結構完整性。例如，為了創建開放式布局而拆除承重墻卻沒有適當的支撐，或者在沒有考慮原始墻體承重能力的情況下加建一層樓。

在軟件架構中，架構侵蝕引入了違反系統基礎原則和預期設計模式的行為，使系統變得脆弱，最終導致劣質架構，未來出現問題。

這些違規行為可能表現為緊密耦合的模塊、繞過安全協議、忽略性能約束，或在無狀態系統中引入有狀態組件等。

DALL-E 對架構侵蝕的詮釋

應對架構技術債務的策略

架構技術債務積累過多會導致架構全面退化。團隊通常會采取兩種策略之一：不斷調整代碼以應對突發問題，或者進行大規模重構。不幸的是，這兩種策略常常失敗，甚至可能加劇現有的技術債務。

調整代碼通常只是表面解決方案。如果團隊缺乏對系統架構的全面了解或對問題根源的理解，他們只能被動應對，這難以解決根本問題。

另一方面，即使是有意的重構——無論是漸進式還是一次性重構——如果不解決導致債務的根本原因，仍可能失敗，技術債務也會再次出現。

最有效的方式是摒棄這些被動措施，轉向整體的、主動的方法。在開發過程中整合持續的、前置的系統設計審查，使團隊能夠更持續地管理技術債務。例如，與其通過快速修復強行將新需求加到現有系統架構中，或不斷替換遺留系統，不如采取更有效的方法，使系統設計始終包含新特性，然后無縫集成實際特性。

正如敏捷宣言的簽署者之一、極限編程創始人 Kent Beck 所言：“對于每一個期望的變更，先讓變更變得容易（警告：這可能很難），然后再進行容易的變更。”

架構恢復的可持續策略

許多團隊誤以為采用敏捷方法就能確保持續的系統設計審查，并防止架構技術債務的積累。然而，現實情況往往與這種期望存在差距。

敏捷團隊注重頻繁交付功能增量，可能無意中忽視了長期的架構完整性。快速交付模式還可能導致文檔和設計不夠清晰，使開發人員難以理解系統的整體架構及其組件的交互方式。這種疏忽會使系統維護和擴展越來越困難，最終導致技術債務的積累。

應對已累積的架構技術債務（ADT）并防止其進一步增加，需要采取以下關鍵步驟：

1. 實施架構可觀測性。首先，對現有架構進行徹底檢查，了解應用程序在生產環境中的行為，并列出其最關鍵的問題。這一步對于評估系統設計的架構漂移程度至關重要。
2. 現代化開發流程。架構漂移和侵蝕往往源于缺乏有效的流程，而不是缺乏技能。隨著業務環境和軟件需求的演變，缺乏系統化的方法來引入新變化以及處理團隊成員的入職和離職，會使軟件架構偏離其預期設計。制定系統設計、管理和文檔的最佳實踐，對于長期維護架構完整性至關重要。

最后的思考

在技術變革加速和競爭加劇的背景下，適應性是現代技術世界的關鍵。擁有一個積累了大量技術債務的復雜系統，就像是背負沉重的枷鎖。在依賴關系和錯誤的迷宮中穿梭，使得適應變化的世界變得越來越困難，機會也因此流失。

從財務角度來看，修改負擔沉重的架構債務系統的成本，總是高于那些經過深思熟慮的前期設計的系統。

雖然適量的技術債務是可管理的，并且可以通過戰略性方法解決，但過度積累往往會導致系統癱瘓，帶來重大挑戰。

駕馭架構技術債務的復雜性，必須采取有意識且主動的策略。團隊必須優先進行持續的架構評估，并整合強大的可觀測性工具，以準確監控系統演變。此外，通過嚴格的設計、管理和文檔實踐來現代化開發流程，這對于維護系統的完整性和可擴展性至關重要。

管理技術債務的最有效方法是將軟件變更和演化置于開發過程的核心。

譯者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師，擁有多個主流技術博客平臺博客專家稱號。

原文標題: Navigating Architectural Change: Overcoming Drift and Erosion in Software Systems Discover effective strategies for safely evolving your software's architecture as you tackle technical debt and requirement changes，作者：Thomas Johnson