遺留代碼庫往往會變成錯綜複雜的依賴關係網，掩蓋了原始設計意圖。隨著時間推移，技術債務不斷累積，使得修改變得風險高且耗時。為了應對這種複雜性，開發人員需要清晰地了解軟件組件的內部結構。這正是UML組合結構圖（CSD）發揮價值之處。通過可視化內部架構，團隊能夠識別結構上的瓶頸，並精確規劃重構工作。
重構不僅僅是改變代碼語法；它是在保持外部行為不變的前提下，改善內部設計。CSD提供了足夠的細節層次，以觀察分類器內各部分如何協作。本指南詳細說明如何利用這種建模技術，有效地現代化遺留系統。
理解UML組合結構圖 📐
組合結構圖是統一建模語言（UML）中的一種特殊類型圖表。與展示類之間關係的標準類圖不同，CSD揭示了特定分類器的內部結構。它回答了這樣的問題：這個組件由哪些部分組成，它們之間如何互動？
此圖表專注於：
- 部分： 構成分類器的內部組件。
- 角色： 部分在結構中扮演的介面。
- 端口： 部分與外部世界或其他部分連接的互動點。
- 連接器： 將部分聯繫在一起的關係，通常用來定義資料流或控制信號。
當應用於遺留代碼時，CSD相當於逆向工程的藍圖。它不僅顯示類A調用類B，還揭示了此互動發生的具體情境。這種可見性對於理解邊界與責任至關重要。
關鍵元素說明
在開始重構過程之前，理解這些圖表中使用的符號至關重要。
- 部分： 以帶有「part」樣式符號的矩形表示。一個部分具有類型（類）和名稱（實例標識符）。
- 介面： 定義為棒棒糖符號。所需的介面以棒上帶球（插座）表示，提供的介面則以棒上帶圓圈（棒棒糖）表示。
- 協作： 展示部分如何協作以實現組合體的行為。
- 內部連接： 連接端口的實線。這些表示直接的通信路徑。
為什麼要在遺留重構中使用CSD？ 🧩
遺留系統經常遭受「意大利麵式代碼」的困擾，其中邏輯分散且依賴關係不透明。標準類圖無法捕捉複雜組件的內部層次結構。CSD正好彌補了這一缺口。
以下是採用這種建模方法的主要原因：
- 隱藏依賴關係的可見性： 它揭示了內部部分之間的相互依賴關係，這些關係可能在原始碼中隱藏著。
- 高耦合的識別： 通過映射連接關係，您可以發現那些過度依賴其他部分的模組。
- 边界定義： 它明確了哪些內容屬於組件內部，哪些屬於外部。
- 重構安全性： 理解內部結構可讓您在不破壞外部合約的情況下進行更安全的修改。
考慮一個遺留的支付處理模組。類圖可能顯示一個PaymentProcessor類。CSD會顯示此類由一個Validator部分、一個Gateway部分，以及一個Logger部分組成。這種區分會改變您進行優化的策略。
重構的逐步流程 🛠️
使用CSD進行重構需要有結構化的方法。以下步驟概述了一個工作流程，用於分析、建模和修改遺留程式碼。
步驟 1：逆向工程結構
第一階段涉及從現有的程式碼庫中提取內部架構。
- 識別目標分類器： 選擇需要重構的組件。這通常是導致最多錯誤或混淆的組件。
- 提取部分： 分析目標類別的欄位和方法，以識別內部組件。如果一個類別管理物件清單，這些物件可能就是部分。
- 映射介面： 判定哪些方法是公開的（提供者）以及哪些是內部的（需求者）。
- 記錄介面： 定義資料與控制的具體進入與離開點。
此步驟會建立組合結構圖的初步草圖。它不需要完美，但必須準確反映當前狀態。
步驟 2：定義內部協作
一旦識別出各部分，您必須定義它們如何協作。這包括分析類別內部的方法呼叫。
- 分析方法流程：追蹤從一個部分到另一個部分的執行路徑。
- 識別連接器：在各部分之間繪製線條以表示這些流程。標示它們以表明傳遞的資料類型或訊號。
- 檢查孤立部分：確保每個部分都已連接。孤立的部分可能表示未使用的程式碼或無效邏輯。
這種可視化通常能揭示出在原始程式碼中並不明顯的循環依賴或冗餘通訊路徑。
步驟 3：識別耦合與內聚
在圖表完成後，您可以評估設計的品質。使用以下標準來評估結構：
| 指標 | 描述 |
|---|---|
| 內部耦合 | 有多少部分直接相互依賴？ |
| 介面使用 | 介面是否被重複使用或重複定義？ |
| 介面粒度 | 介面是否過於寬泛（做所有事情）或過於狹窄？ |
| 資料流 | 資料是否經過了太多中間部分？ |
高內部耦合表示需要模組化。如果一個部分在沒有明確定義介面的情況下需要存取另一個部分的內部狀態，這表示違反了封裝原則。
步驟 4：應用結構重構模式
根據分析結果，應用特定的重構技術。CSD 指導哪些部分需要提取或移動。
- 提取介面： 如果一個部分被多個其他部分使用，則定義一個共同的介面以降低耦合度。
- 移動方法： 如果一個方法在邏輯上屬於某個部分而非組合體，則將其移動。
- 取代條件邏輯： 如果結構依賴複雜的條件判斷來導向行為，則以透過部分實現的策略模式來取代。
- 拆分組合體： 如果組合類別承擔了太多功能，則將其拆分為較小的組合體，並透過連接器將它們連結。
每次變更都應在修改程式碼之前反映在圖表中。這可確保架構意圖得以維持。
步驟 5：驗證與測試
重構後，圖表必須再次與程式碼相符。這可確保設計意圖得以保留。
- 更新圖表：修改CSD以反映新的結構。
- 執行回歸測試：確保外部行為保持不變。
- 程式碼審查：請同儕驗證新結構是否與圖表一致。
常見模式與情境 🚦
某些架構上的問題在舊有程式碼中經常出現。CSD能幫助識別並解決這些問題。
1. 神類
一個包含多個不同責任邏輯的類別。CSD會透過顯示過多的元件與連接器來揭示此問題。
- 解決方案：將該類別分解為多個組合元件。
- 視覺提示：一個內部埠過多的單一矩形。
2. 泄漏的抽象
當內部實作細節暴露給外部世界時。在CSD中，這表現為內部元件直接連接到外部埠。
- 解決方案：引入外觀或適配器元件，以隱藏內部複雜性。
- 視覺提示：內部元件直接連接到邊界。
3. 緊密的循環依賴
元件A呼叫元件B，而元件B又呼叫元件A。這會形成一個難以打破的循環。
- 解決方案：引入中介元件或基於事件的介面，以解耦互動關係。
- 視覺提示：元件之間形成閉合的連接迴路。
建模舊系統的挑戰 ⚠️
雖然CSD功能強大，但將其應用於遺留程式碼會帶來特定挑戰。
- 缺乏文件：遺留系統通常缺乏設計文件。圖表成為主要文件。
- 隱含知識：開發人員可能知道各部分如何互動，但這並未明確體現在程式碼中。
- 時間限制：製作詳細圖表需要時間。應先著重於高風險區域。
- 動態行為： 某些遺留程式碼依賴執行時反射。靜態圖表可能無法捕捉所有行為。
為降低這些問題，應採用分層方法。先從高階CSD開始，然後根據需要深入特定模組。
成功最佳實務 ✅
為確保流程高效且有效，請遵循以下指導原則。
- 從小處著手： 不要試圖一次建模整個系統。專注於一個有問題的模組。
- 保持更新： 將圖表視為活文件。只要程式碼有重大變更，就應更新圖表。
- 專注於行為： 不僅僅畫方框；應記錄資料流和控制訊號。
- 協作： 讓資深開發人員參與建模過程，以驗證假設。
- 盡可能自動化： 使用可從程式碼生成圖表的工具，以加快逆向工程階段。
與現代架構整合 🔄
重構遺留程式碼通常旨在遷移至微服務等現代架構。CSD在單體式遺留結構與分散式現代設計之間扮演橋樑角色。
透過在組合中隔離各部分，可以識別哪些部分可被提取為獨立服務。例如，若一個報表模組具有明確的介面，且與資料庫模組的依賴關係極少，則可能適合分離。
這種結構上的清晰性降低了遷移風險。你知道必須跨越哪些邊界，以及需要公開哪些介面。
結構重構總結 📝
重構遺留程式碼是一項細膩的過程，需要對現有架構有深入的理解。UML組合結構圖提供了必要的視角，以看見標準圖表所隱藏的內部複雜性。透過繪製元件、角色與連接器，團隊能夠識別耦合問題，規劃模組化，並有信心地執行變更。
雖然此過程需要投入努力，但長期效益包括降低技術負債、提升可維護性，並為未來的演進提供更清晰的路徑。將圖表視為指引而非限制，讓結構來引導程式碼的設計。
