一、重構背景
1.1、退款
京東秒送秒送退款有2套結構，代碼邏輯混亂；
其中秒送、天選部分售後單是和平生pop交互退款，部分是和售後中臺交互退款；並且兼容3套邏輯；
痛點：代碼繁重，缺乏合理性的設計，後續迭代開發以及維護成本高，同時增加了系統的風險和不穩定性
1.2、金額計算
京東秒送兩套獨立的邏輯結構計算，在此基礎上針對退差和非退差又實現了2套邏輯；
針對商品件維度、商品行維度、售後單維度計算金額混亂，缺乏領域邊界和分層設計；
痛點：售後單維度、商品行維度、拆分件維度金額計算混亂，代碼缺乏層次結構；代碼易讀性、維護成本、後續擴展性存在問題
1.3、售後逆向賬
售後單詳情接口、申訴單詳情接口，針對京東秒送秒送做了兩套邏輯；
其中售後單詳情接口針對秒送黑名單、秒送白名單、天選、秒送退差、秒送非退差做了5套邏輯處理；
並且這兩個接口都是實時從拆分獲取金額進行售後逆向拆分計算，可以直接從數據庫中進行取值賦值，不需要進行售後單維度的拆分計算；
痛點：代碼大量冗餘、改動成本高、增加了系統的風險和不穩定性
二、重構思路和方案
2.1、重構思路
什麼是重構呢？
名詞：對軟件內部結構的一種調整，目的是在不改變軟件觀察行爲的的前提下提高其可理解性、降低其修改成本；
動詞：使用一系列手法，在不改變軟件可觀察行爲的前提下，調整其結構
重構的目的是使系統或代碼更容易被理解、修改、迭代
重構祕訣：膽大心細
膽大（意味着有勇氣和決心去改變和改進現有的代碼。重構可能涉及對複雜的代碼結構進行修改，甚至可能需要重寫部分代碼。膽大的開發者願意面對這些挑戰，相信通過改變可以帶來更好的結果）
心細（指的是在進行重構時保持細緻入微的思考和行動。這包括仔細分析代碼的結構和邏輯，理解代碼的功能和依賴關係，以及考慮每個重構步驟可能帶來的潛在影響。心細的開發者會在重構過程中小心翼翼地處理每個細節，以確保代碼的正確性和可維護性）
1.把握好重構時機：當我發現售後退款、金額計算等業務模塊代碼存在質量問題、可讀性差、可維護性差或存在壞味道時，並且在項目需求排期並不緊張的情況下，是進行重構的好時機；
2.前期梳理很重要，先找到痛點 ；不宜長線作戰，不宜和業務並行
3.明確出目標和價值：售後退款、金額計算重構後能提高開發效率、降低維護、開發成本等
4.確定重構的目標：首先要明確需要進行重構的代碼塊或功能，並明確重構的目標是什麼。例如，可能需要提高代碼的可讀性、可維護性或性能。
5.分析代碼壞味道：使用代碼靜態分析工具或手動檢查代碼，識別出可能存在的代碼壞味道；例如退款業務中存在1000多行的類、600多行的方法，過多的變量參數、諸多重複代碼等代碼壞味道。
6.選擇適當的重構技術：根據售後代碼壞味道的種類和重構的目標，選擇適當的重構技術。我採用的重構手法是：小規模重構-->大規模重構-->頂層設計模式；採用先小後大，從大到全的思路進行重構設計。小規模重構：提取方法、消除超大類或函數方法、提取類、重命名、合併重複代碼等方法；大規模重構：採用的是分層、模塊化、解耦、抽象可複用性等手法；設計模式：退款業務採用策略模式+抽象工廠；金額計算業務採用策略模式+抽象工廠+責任鏈模式
7.編寫測試用例：在進行重構之前，編寫適當的測試用例來驗證重構後的代碼的正確性。測試用例應該覆蓋重構的代碼塊或功能的各種情況。
8.執行重構：根據選擇的重構技術，逐步修改代碼。確保每次修改後的代碼仍然通過之前編寫的測試用例。
9.運行測試用例：在每次重構之後，運行之前編寫的測試用例，確保重構後的代碼仍然正確。
10.重構後的代碼評估：評估重構後的代碼是否達到了預期的目標，例如是否提高了代碼的可讀性、可維護性或性能。
2.2、重構方案
2.2.1、重構前系統交互圖
2.2.2、重構後系統交互圖
退款業務強耦合到售後系統中，並且業務代碼分散到各個業務層，嚴重缺乏系統的領域邊界和分層設計，重構後退款業務邏輯不強依賴售後核心業務邏輯，做到可以獨立部署。
2.2.3、重構前金額計算流程圖
2.2.4、重構後金額計算流程圖
將2套金額計算業務邏輯利用設計模式將其合併爲1套金額計算業務邏輯，打造防腐層
2.3、重構設計類圖
依據上述制定的設計方案流程圖，我進行了UML類圖的繪製，以下是關於金額計算業務模塊的類圖
2.3.1、抽象工廠+策略模式類圖
2.3.2、責任鏈模式類圖
三、系統穩定性保障
3.1、小步重構
將售後重構分成退款、金額計算、逆向賬三個步驟，並在每個步驟之後運行測試用例。這樣可以及時發現並修復引入的錯誤，避免錯誤在整個系統中蔓延
3.2、逐步驗證
在每個重構步驟之後，進行系統的逐步驗證。分批次進行上線灰度，灰度配置絕對隔離，不能複用。確保系統的各個部分在重構過程中都能正常運行，並與其他部分協調良好。
3.3、監控和性能測試
在重構完成後，進行系統的監控和性能測試，確保重構沒有引入性能問題或影響系統的穩定性。如果發現問題，及時進行修復和優化。
3.4、團隊代碼審查和測試
在進行重構時，與團隊成員進行合作，並進行代碼審查。多個人的視角和經驗可以幫助發現潛在的問題，並提供改進的建議；針對重構代碼進行深度解刨，能更有效地保障重構的安全性。
重構業務及時通知測試人員，使測試人員能夠評估到測試點，更加完善測試用例
3.5、灰度步驟
3.5.1、bcp持續比對校驗
3.5.2、按照商家灰度
依據售後單量 小->中->大 的順序逐步進行灰度切量，觀察其退款、金額計算等售後單數據是否異常
四、重構成果
1.降低開發、維護成本
2.提升代碼質量、系統穩定性
3.系統擴展性和靈活性的加強；
4.系統應用、業務邊界定位更加清晰
5.統一和規範售後核心業務脈絡，降低業務學習成本，提升開發效率
6.提升自己的技術能力、代碼質量意識、問題解決能力、團隊合作和溝通能力；經典著作《重構》這本書中有這麼一段話：
一開始，我所做的重構都停留在細枝末節上。隨着代碼趨向簡潔，我發現自己可以看到一些設計層面的東西了，這些是我以前理解不到的，如果沒有重構，我達不到這種高度
五、code show
5.1、重構前金額計算
京東秒送售後單金額計算service方法
一個大的金額計算class類就有1000多行代碼，每個方法中都有幾百行代碼，以下是京東秒送售後單金額計算部分代碼
5.2、重構後金額計算
京東秒送售後單金額計算用同一個接口才承接業務實現，並且使用策略+抽象工廠模式實現秒送、天選業務的金額計算
策略模式獲取金額拆分結果集
金額計算核心方法只有4步驟
其中金額計算的核心則採用的是責任鏈業務進行計算
在件維度、sku維度針對不同的業務又採用了責任鏈模式進行金額計算
六、參考文獻
代碼的壞味道： https://www.qinglite.cn/doc/87036476d565d55f9
《重構改善既有代碼的設計》：[美]MartinFowler
《敏捷軟件開發》：[美]RobertC.Martin
作者：京東零售 高凱
來源：京東雲開發者社區