退款業務強耦合到售後系統中，並且業務代碼分散到各個業務層，嚴重缺乏系統的領域邊界和分層設計，重構後退款業務邏輯不強依賴售後核心業務邏輯，做到可以獨立部署。 ...

一、重構背景

1.1、退款

到家、小時購、天選退款有2套結構，代碼邏輯混亂；

其中小時購、天選部分售後單是和平生pop交互退款，部分是和售後中台交互退款；並且相容3套邏輯；

痛點：代碼繁重，缺乏合理性的設計，後續迭代開發以及維護成本高，同時增加了系統的風險和不穩定性

1.2、金額計算

到家、小時購兩套獨立的邏輯結構計算，在此基礎上針對退差和非退差又實現了2套邏輯；

針對商品件維度、商品行維度、售後單維度計算金額混亂，缺乏領域邊界和分層設計；

痛點：售後單維度、商品行維度、拆分件維度金額計算混亂，代碼缺乏層次結構；代碼易讀性、維護成本、後續擴展性存在問題

1.3、售後逆向賬

售後單詳情介面、申訴單詳情介面，針對到家和小時購做了兩套邏輯；

其中售後單詳情介面針對小時購黑名單、小時購白名單、天選、到家退差、到家非退差做了5套邏輯處理；

並且這兩個介面都是實時從拆分獲取金額進行售後逆向拆分計算，可以直接從資料庫中進行取值賦值，不需要進行售後單維度的拆分計算；

痛點：代碼大量冗餘、改動成本高****、增加了系統的風險和不穩定性

二、重構思路和方案

2.1、重構思路

什麼是重構呢？

名詞：對軟體內部結構的一種調整，目的是在不改變軟體觀察行為的的前提下提高其可理解性、降低其修改成本；

動詞：使用一系列手法，在不改變軟體可觀察行為的前提下，調整其結構

重構的目的是使系統或代碼更容易被理解、修改、迭代

重構秘訣：膽大心細

膽大（意味著有勇氣和決心去改變和改進現有的代碼。重構可能涉及對複雜的代碼結構進行修改，甚至可能需要重寫部分代碼。膽大的開發者願意麵對這些挑戰，相信通過改變可以帶來更好的結果）

心細（指的是在進行重構時保持細緻入微的思考和行動。這包括仔細分析代碼的結構和邏輯，理解代碼的功能和依賴關係，以及考慮每個重構步驟可能帶來的潛在影響。心細的開發者會在重構過程中小心翼翼地處理每個細節，以確保代碼的正確性和可維護性）

把握好重構時機：當我發現售後退款、金額計算等業務模塊代碼存在質量問題、可讀性差、可維護性差或存在壞味道時，並且在項目需求排期並不緊張的情況下，是進行重構的好時機；
前期梳理很重要，先找到痛點；不宜長線作戰，不宜和業務並行
明確出目標和價值：售後退款、金額計算重構後能提高開發效率、降低維護、開發成本等
確定重構的目標：首先要明確需要進行重構的代碼塊或功能，並明確重構的目標是什麼。例如，可能需要提高代碼的可讀性、可維護性或性能。
分析代碼壞味道：使用代碼靜態分析工具或手動檢查代碼，識別出可能存在的代碼壞味道；例如退款業務中存在1000多行的類、600多行的方法，過多的變數參數、諸多重覆代碼等代碼壞味道。
選擇適當的重構技術：根據售後代碼壞味道的種類和重構的目標，選擇適當的重構技術。我採用的重構手法是：小規模重構-->大規模重構-->頂層設計模式；採用先小後大，從大到全的思路進行重構設計。小規模重構：提取方法、消除超大類或函數方法、提取類、重命名、合併重覆代碼等方法；大規模重構：採用的是分層、模塊化、解耦、抽象可復用性等手法；設計模式：退款業務採用策略模式+抽象工廠；金額計算業務採用策略模式+抽象工廠+責任鏈模式
編寫測試用例：在進行重構之前，編寫適當的測試用例來驗證重構後的代碼的正確性。測試用例應該覆蓋重構的代碼塊或功能的各種情況。
執行重構：根據選擇的重構技術，逐步修改代碼。確保每次修改後的代碼仍然通過之前編寫的測試用例。
運行測試用例：在每次重構之後，運行之前編寫的測試用例，確保重構後的代碼仍然正確。
重構後的代碼評估：評估重構後的代碼是否達到了預期的目標，例如是否提高了代碼的可讀性、可維護性或性能。