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