背景
訂單是電商服務的核心場景之一，微商城客戶端的訂單模塊已經服務了商家多年，功能和體驗上和 PC 端有一定的差距。爲了彌補不足，提升商家的體驗，產品經過一系列數據調研，發起了微商城訂單模塊的重構項目。
作爲“樂於重構”的開發者，在此次重構中以增強代碼維護性以及線上穩定性爲目的，接受了這次挑戰。接下來將從業務代碼架構、歷史代碼改造兩方面，簡單地聊一聊我們在此次重構中的一些經驗。
一、業務代碼架構的改進
1.1 組件拆分
上圖爲舊訂單列表和新訂單列表的截圖
上圖是新訂單列表中訂單狀態配置和篩選項配置的截圖
不論是新訂單列表還是舊訂單列表，頁面核心功能區域 UI 均分爲訂單狀態、訂單類型、及訂單卡片列表三個部分。這部分基礎的邏輯並沒有變更，但是每個部分的可選項增多了，靈活性增加了，在舊訂單列表上進行變更代價較大。
在代碼邏輯方面：
Android 側訂單列表過去的多個列表入口均繼承自 AbsTradesListFragment，具體繼承關係可見下圖
各個實現類的頁面只是提供了不同的網絡請求參數，這種設計好處是對於訂單的通用變更，只需要改 AbsTradesListFragment 即可。但缺點也很明顯：由於每次變更範圍是訂單列表，修改時往往又是局部變更，每次需求迴歸時都需要重新迴歸整個各個影響，爲了減小 UI 變更影響的範圍，只能在 AbsTradesListFragment 裏寫上各種判斷邏輯，所以維護成本比較高。同時由於所有業務都堆在 AbsTradesListFragment內，導致代碼行數已經達到了 1000 行，這給開發人員維護老的訂單邏輯也帶來了不少的問題。
原文鏈接:【https://www.infoq.cn/article/6sqK1yiqEMh2eO7IggPM】。未經作者許可，禁止轉載。