譯者 | 劉汪洋
審校 | 重樓
一種常見但不完美的比喻是將軟件系統(tǒng)中的架構漂移和侵蝕與物理建筑的架構相比。雖然這個比喻很直觀，但它存在一個根本性的誤解，這也常常引發(fā)軟件開發(fā)中的架構問題。
試想一下，一個設計良好的摩天大樓或房屋建成后，我們期望它基本保持不變，頂多因為偶爾的現(xiàn)代化或擴建而發(fā)生變化。
令人驚訝的是，如今許多工程師（甚至可能是無意識地）將同樣的邏輯套用到軟件架構上：認為一旦系統(tǒng)架構設計完成，如果設計得當，它就不需要進一步修改，直到需求變化和遺留代碼迫使進行大規(guī)模重寫。
這是一個關鍵的誤解。與物理結構不同，軟件本質(zhì)上是動態(tài)的，不斷變化，需要定期更新以保持活力。一旦軟件停止演變，就會開始衰亡。
此外，這種比喻通常強調(diào)軟件系統(tǒng)的結構和行為，但忽略了同樣重要的決策、權衡和妥協(xié)，這些因素共同塑造了架構。理解架構決策背后的原因?qū)τ谖磥淼男薷囊约肮芾砗脱葑冘浖軜嬛陵P重要。
本文旨在加深你對架構技術債務的理解，并強調(diào)有效管理架構漂移和侵蝕的關鍵因素。
架構技術債務概述
“在軟件密集型系統(tǒng)中，技術債務指的是那些在短期內(nèi)權宜的設計或?qū)崿F(xiàn)，這些構造設置了一個技術背景，使得未來的變更更為昂貴甚至不可能。技術債務是一種或有負債，其影響主要限于系統(tǒng)內(nèi)部質(zhì)量，特別是可維護性和可演化性。” ——Avgeriou等人，2016年
技術債務總結了軟件開發(fā)中過去決策和捷徑累積的后果，包括低質(zhì)量代碼、缺失的文檔和嚴重耦合等問題。這些問題可能源自多種原因，如戰(zhàn)略性權衡或需求的意外變化等。
盡管許多工程團隊記錄了他們管理技術債務的策略——如谷歌和 ThoughtWorks 的做法——但關于特定類型的技術債務，即架構技術債（ADT），討論較少。
ADT 源于系統(tǒng)設計過程中的有意或無意決策，導致維護性降低、復雜性增加、性能下降和可擴展性受限等問題。由于軟件架構定義了系統(tǒng)的關鍵屬性和約束，ADT 對系統(tǒng)演變及組織實現(xiàn)目標的能力構成重大風險。
ADT 是不可避免的，特別是在目標是快速交付和后續(xù)迭代時，有時甚至是必要的。因此，團隊必須識別 ADT 并實施有效管理策略，以防止架構退化——即逐漸變得過時、不可靠，無法適應不斷變化的業(yè)務需求或技術進步。
首先，關鍵的是在 ADT 的廣泛范圍內(nèi)區(qū)分兩個獨特的現(xiàn)象：系統(tǒng)架構漂移和系統(tǒng)架構侵蝕。
架構漂移與架構侵蝕
架構漂移指的是在系統(tǒng)中引入不在原始架構計劃中的設計決策，但這些決策并不一定會違反基礎架構原則。架構侵蝕是指引入的新設計直接與系統(tǒng)的預期架構相沖突，破壞了系統(tǒng)的指導原則。
以建筑架構為比喻，架構漂移就像是建造一棟地中海風格的房子，然后添加一個哥特式的塔樓和一個后現(xiàn)代的擴建。這雖然導致了風格混雜（可能并不美觀），但不會破壞結構的完整性。
在軟件工程中，一個系統(tǒng)可能以干凈的架構開始，但由于架構漂移，最終演變成包含多種架構范式、不一致編碼實踐、冗余組件和依賴項的復雜結構。
深入探討架構漂移 by Vladi Stevanovic
另一方面，架構侵蝕類似于進行改造時破壞了房屋的結構完整性。例如，為了創(chuàng)建開放式布局而拆除承重墻卻沒有適當?shù)闹危蛘咴跊]有考慮原始墻體承重能力的情況下加建一層樓。
在軟件架構中，架構侵蝕引入了違反系統(tǒng)基礎原則和預期設計模式的行為，使系統(tǒng)變得脆弱，最終導致劣質(zhì)架構，未來出現(xiàn)問題。
這些違規(guī)行為可能表現(xiàn)為緊密耦合的模塊、繞過安全協(xié)議、忽略性能約束，或在無狀態(tài)系統(tǒng)中引入有狀態(tài)組件等。
DALL-E 對架構侵蝕的詮釋
應對架構技術債務的策略
架構技術債務積累過多會導致架構全面退化。團隊通常會采取兩種策略之一：不斷調(diào)整代碼以應對突發(fā)問題，或者進行大規(guī)模重構。不幸的是，這兩種策略常常失敗，甚至可能加劇現(xiàn)有的技術債務。
調(diào)整代碼通常只是表面解決方案。如果團隊缺乏對系統(tǒng)架構的全面了解或?qū)栴}根源的理解，他們只能被動應對，這難以解決根本問題。
另一方面，即使是有意的重構——無論是漸進式還是一次性重構——如果不解決導致債務的根本原因，仍可能失敗，技術債務也會再次出現(xiàn)。
最有效的方式是摒棄這些被動措施，轉(zhuǎn)向整體的、主動的方法。在開發(fā)過程中整合持續(xù)的、前置的系統(tǒng)設計審查，使團隊能夠更持續(xù)地管理技術債務。例如，與其通過快速修復強行將新需求加到現(xiàn)有系統(tǒng)架構中，或不斷替換遺留系統(tǒng)，不如采取更有效的方法，使系統(tǒng)設計始終包含新特性，然后無縫集成實際特性。
正如敏捷宣言的簽署者之一、極限編程創(chuàng)始人 Kent Beck 所言：“對于每一個期望的變更，先讓變更變得容易（警告：這可能很難），然后再進行容易的變更。”
架構恢復的可持續(xù)策略
許多團隊誤以為采用敏捷方法就能確保持續(xù)的系統(tǒng)設計審查，并防止架構技術債務的積累。然而，現(xiàn)實情況往往與這種期望存在差距。
敏捷團隊注重頻繁交付功能增量，可能無意中忽視了長期的架構完整性。快速交付模式還可能導致文檔和設計不夠清晰，使開發(fā)人員難以理解系統(tǒng)的整體架構及其組件的交互方式。這種疏忽會使系統(tǒng)維護和擴展越來越困難，最終導致技術債務的積累。
應對已累積的架構技術債務（ADT）并防止其進一步增加，需要采取以下關鍵步驟：
- 實施架構可觀測性。首先，對現(xiàn)有架構進行徹底檢查，了解應用程序在生產(chǎn)環(huán)境中的行為，并列出其最關鍵的問題。這一步對于評估系統(tǒng)設計的架構漂移程度至關重要。
- 現(xiàn)代化開發(fā)流程。架構漂移和侵蝕往往源于缺乏有效的流程，而不是缺乏技能。隨著業(yè)務環(huán)境和軟件需求的演變，缺乏系統(tǒng)化的方法來引入新變化以及處理團隊成員的入職和離職，會使軟件架構偏離其預期設計。制定系統(tǒng)設計、管理和文檔的最佳實踐，對于長期維護架構完整性至關重要。
最后的思考
在技術變革加速和競爭加劇的背景下，適應性是現(xiàn)代技術世界的關鍵。擁有一個積累了大量技術債務的復雜系統(tǒng)，就像是背負沉重的枷鎖。在依賴關系和錯誤的迷宮中穿梭，使得適應變化的世界變得越來越困難，機會也因此流失。
從財務角度來看，修改負擔沉重的架構債務系統(tǒng)的成本，總是高于那些經(jīng)過深思熟慮的前期設計的系統(tǒng)。
雖然適量的技術債務是可管理的，并且可以通過戰(zhàn)略性方法解決，但過度積累往往會導致系統(tǒng)癱瘓，帶來重大挑戰(zhàn)。
駕馭架構技術債務的復雜性，必須采取有意識且主動的策略。團隊必須優(yōu)先進行持續(xù)的架構評估，并整合強大的可觀測性工具，以準確監(jiān)控系統(tǒng)演變。此外，通過嚴格的設計、管理和文檔實踐來現(xiàn)代化開發(fā)流程，這對于維護系統(tǒng)的完整性和可擴展性至關重要。
管理技術債務的最有效方法是將軟件變更和演化置于開發(fā)過程的核心。
譯者介紹
劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗的某大廠高級 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
