一、重構背景

1.1、退款

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

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

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

1.2、金額計算

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

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

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

1.3、售後逆向賬

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

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

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

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

二、重構思路和方案

2.1、重構思路

什麼是重構呢？

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

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

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

重構祕訣：膽大心細

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

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

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