作者 | Pierre Pureur, Kurt Bittner

譯者 | 明知山

軟件架構的一個核心目標是提升系統在生命周期內的可維護性。在許多情況下，這種努力很大程度上具有較強的預判屬性，因為它面對的本質上是不確定的事件。人們經常會問“倘若后續要整改此處，難度會有多大？”這類問題，忽視了未來潛在的變更所帶來的影響，但經驗告訴我們，這種做法終將埋下隱患。

為了聚焦這種預判分析并減少團隊耗費在沒完沒了的假設討論上的時間，我們采用了一種叫做變更案例（Change Case）的方法。架構變更案例如同預測用的水晶球，可幫助我們推演各項架構決策會衍生出怎樣的潛在結果。

雖然架構決策記錄（ADR）用于記錄決策，有時也記錄權衡，但它們僅對決策內容做匯總，無法作為備選方案調研的起始依據。變更案例能夠明確一類潛在的需求，但不會闡述實現該需求的具體途徑。

與架構變更案例不同，架構權衡分析方法（ATAM） 的目標是評估現有軟件架構對當前質量屬性需求（QAR）的滿足程度。與之相對，架構變更案例用于研判系統未來所需的演化方向。

什么是架構變更案例？

架構變更案例會識別針對方案假設的潛在變更，這類變更有可能對軟件架構造成顯著影響。變更案例不需要定義替代解決方案；它的核心作用是厘清未來發生變更的可能性，并概述可能的備選方案。這種方法能夠輔助制定應急預案，促進設計靈活性，以此削弱變更帶來的影響。它的最終目標是衡量軟件架構的彈性。

架構變更案例可能包括以下信息：

• 質量屬性需求的潛在變更（提升或下調）或是業務方案發生變更

• 變更發生的可能性（概率）

• 因原有假設失效、需要調整的相關決策清單

• 各類可選的潛在解決方案

• 變更成本預估，也就是撤銷原有決策所需耗費的成本。這種成本可借助“T 恤尺碼分級”（S、M、L、XL 等）按數量級做粗略估算。

架構變更案例也是分析架構決策變更影響的有效方法，通過闡明一個替代決策以及如果原有決策被證實不合理時，廢止現有決策、落地備選方案所需投入的成本。

架構變更案例的來源包含“混沌猴子（Chaos Monkey）”測試，這類測試用于排查潛在故障與極易引發重大故障的系統配置變更。另一個有用的技術是進行 預驗尸評審（Pre-Mortem Review），預判系統架構有可能出現故障的各類情形。架構變更案例有助于梳理這些變更，并幫助團隊制定應對措施。

架構變更案例預判系統衰退

在實際落地過程中，許多軟件架構決策似乎假設要么事情不會發生變化，要么可以防止發生變更。這兩種假設都不現實。變更在所使用的技術、維護人員的技能以及最重要的——系統運營的業務環境中——都是不可避免的。持續架構 和 演化架構 等方法論就充分意識到了這類挑戰的存在。

架構變更案例能夠幫助采用上述方法論的團隊梳理各類潛在變更，包括 AI 模型的變更（如概念漂移）、環境配置、組件與框架版本、安全風險、帶寬等方面的變更。變更案例還考慮到了業務環境的變更，例如最小可行產品（MVP）失敗或因市場變化而過時。

實踐中的架構變更案例

以某大型保險公司新設子公司為例，這家公司計劃推出創新產品，借此和運營模式更靈活的競品展開競爭。他們初期打算上線按需度假房屋租賃保險，這是一款短期靈活險種，可以通過移動應用開啟或關閉。該產品初期僅在一個州提供。產品的目標客群為短期租住度假房源（數天至數周）的人，這類人群的隨身財物大多不在房主原有保險的保障范圍內。

公司管理層設想復用母公司的承保、會計和理賠應用程序可以降低成本和縮短上市周期。他們選擇使用 AI 編碼智能體快速將 MVP 推向市場。

他們的潛在變更案例包括低估 MVP 的采用率。實際用戶數量可能比預估上限高出 50%，因為根據初步使用統計，短期租賃者似乎十分青睞這種新產品帶來的靈活性。因此，MVP 可能會遇到可擴展性和性能問題。最小可行架構（MVA）需要快速迭代升級，預留冗余容量以支撐更高的訪問流量。

如果業務利益相關者希望將目標客戶群擴展到包括房車和船只租賃者呢？母公司的承保系統可能無法處理這些風險類別。如果業務利益相關者希望增加一個保險法規差異顯著的州呢？這個變更案例將檢驗這個方案的可維護性、性能與可擴展能力。

這些變更案例意味著團隊可能無法再復用母公司的承保系統。表 1 總結了團隊收集的變更案例信息。

表 1. 按需房屋租賃保險 MVP 的變更案例信息

架構變更案例是研判架構決策影響的工具。就像推演象棋落子后的可能后果一樣，它能夠幫助團隊評估某項架構決策的利弊。

架構變更案例有助于預判未來的架構決策。

通過最小可行架構來落地最小可行產品的一個挑戰是，架構變更案例需要被視為 MVA 成功標準的一部分，而不僅僅是解決即時業務問題的方案。

架構變更案例的類別

上面的例子主要關注功能變更，不過團隊還需要考慮其他類別的架構變更案例，包括：

• 外部系統接口發生變更，要求你的系統做出同步變更。

• 因需求變動、供應商整合或合作失敗、開源項目停更，或是原有選型不再適用等原因，需要替換核心子系統。

• 基礎設施變更，例如計算資源遷移至其他數據中心或云平臺、會造成延遲波動的網絡調整等。

• 業務模式出現重大調整，包括 MVP 落地不及預期、市場變動推翻原有業務假設等情形。

• 受外部環境影響，系統出現安全漏洞帶來的相關變更。

梳理變更案例的類別能夠幫助團隊評估系統未來是否需要做出變更，推動團隊對自身預設的前提提出審慎質疑。

何時定義架構變更案例

團隊在以下情況時應考慮創建架構變更案例：

• 引入主要依賴項

• 采用 AI 生成的代碼

• 硬編碼業務規則

• 為快速 MVP 交付進行優化

• 與外部平臺產生耦合綁定

• 在可擴展性與可維護性之間做出取舍

變更案例在后續撤銷決策成本高昂、運營風險偏大的場景下最有價值。

架構變更案例與規劃

定義變更案例非常適合在迭代規劃工作（例如 Scrum 中的 Sprint）中進行。正如我們在 之前的文章 中所描述的，每次迭代都會產生一個新的或增強的 MVP 和相關的 MVA。當團隊在規劃迭代工作時，他們需要考量正在做出的架構權衡以及如果業務或市場發生變化，或 QAR 發生變化，這些權衡后續會產生怎樣的變化。

僅梳理出潛在變更案例或許就足夠了，或者團隊可能需要更進一步，通過實驗來驗證他們對代碼適應未來變更能力的假設。這些實驗得出的結論能夠告訴他們需要投入多少工作量來改進代碼的模塊化，以便在必要時替換系統模塊。

AI 與架構變更案例

鑒于業界普遍傾向借助 AI 編碼智能體生成 MVP 的 部分代碼，有必要針對性制定適配 AI 場景的變更案例，以此研判相關方案對后續迭代變更的潛在影響。AI 智能體生成代碼普遍暗藏兩類隱患：其一，提供服務的 AI 廠商存在破產或被同業并購的可能性；其二，AI 模型版本若出現大幅迭代，過往生成的代碼或將無法復現。

為了讓 AI 編碼助手生成可接受的結果，團隊需要預先花時間定義目標并編寫規范，包括代碼示例，并定義驗收測試。這些比 AI 生成的代碼更為重要。想要降低 AI 模型變化所造成的風險，有效的策略是創建和維護一個用于為 AI 助手提供上下文信息的工件倉庫，包括需求、規范、設計文檔、架構 / 設計模型、先前的架構和設計決策、數據、接口規范、代碼片段和驗收測試。這個倉庫可以使用現有工具（如 GitHub）來維護。

使用 AI 編碼助手的團隊應當考慮定義預判以下情況的變更案例：

• 用 AI 智能體生成的代碼替換現有系統的某些部分（如微服務）。在這種情況下，架構仍由人工把控，具體編碼細節交給 AI 處理。

• 更換 AI 工具，或是選用當前 AI 工具的新版本來構建新的 MVP。如果你用 AI 編碼智能體生成了整個 MVP（因此也生成了隱含的 MVA），你需要確認這些結果是否可復現。

• AI 生成的代碼所對接的外部系統發生變更。大多數新系統必須與其他系統發生交互，而那些系統會發生變更。AI 生成的代碼必須能夠應對這類變更。

投入精力創建 AI 專屬變更案例和相關工件倉庫，是確保 AI 編碼助手構建的 MVP 能夠適應后續迭代的有效手段。

架構變更案例需要進行經驗評估

僅僅識別架構變更案例是不夠的。清楚潛在隱患固然有益，但僅憑主觀推演無法判定問題的嚴重程度。難點在于真正摸清問題對應的整改成本，你不會想去構建整個替代方案。借助實驗能夠獲取測算數據，無需構建整個替代方案。

正如我們在 之前的文章 中寫的，進行架構實驗是理解潛在變更的風險和復雜性以及驗證假設的重要技能。事實上，真正了解變更影響的唯一方法是先嘗試落地一小部分預期變更，評估其有效性，統計投入的工作量，再基于實測結果做推演。

適應度函數 可用于評估變更的有效性。適應度函數作為量化衡量手段，既可以為受變更案例影響的 QAR 劃定基準，還能檢驗實驗是否實現了預期優化，且不會給系統其他模塊帶來不良影響。例如，以表 1 中的第一個變更案例“產品采用率被低估”為例，性能與可擴展性相關的適應度函數可檢驗實驗版 MVA 在達成 QAR 優化目標的同時是否損害了 MVP 的可用性與可維護性。

當然，開展這類實驗是有成本的。架構變更案例是一個有用的工具，但應該適度使用，因為它們在時間與資金方面都可能產生較高開銷。但對于某些問題，想要得到結論，只能編寫（或生成）并測試部分代碼。

結 論

人們容易想當然地認為軟件架構是靜態的，一經確定就隨時間保持不變。我們從未見過一成不變的架構，所有架構都會發生變動。關鍵在于這種變化是有意還是偶然發生的。當架構決策會發生變更時，架構變更案例能夠幫助團隊更深思熟慮地對待他們的架構決策。

事實上，軟件系統的架構永遠無法真正定型，因為周圍的世界總是在發生變化。使用 AI 編碼智能體 生成代碼會引入隱性的變化，而這也加劇了這一問題。為了應對這些變更壓力，團隊需要考慮創建一種能夠持續預判和緩釋變更風險的架構，而架構變更案例可以為此提供幫助。

查看英文原文：

https://www.infoq.com/articles/architectural-change-cases/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。