背景
订单是电商服务的核心场景之一，微商城客户端的订单模块已经服务了商家多年，功能和体验上和 PC 端有一定的差距。为了弥补不足，提升商家的体验，产品经过一系列数据调研，发起了微商城订单模块的重构项目。
作为“乐于重构”的开发者，在此次重构中以增强代码维护性以及线上稳定性为目的，接受了这次挑战。接下来将从业务代码架构、历史代码改造两方面，简单地聊一聊我们在此次重构中的一些经验。
一、业务代码架构的改进
1.1 组件拆分
上图为旧订单列表和新订单列表的截图
上图是新订单列表中订单状态配置和筛选项配置的截图
不论是新订单列表还是旧订单列表，页面核心功能区域 UI 均分为订单状态、订单类型、及订单卡片列表三个部分。这部分基础的逻辑并没有变更，但是每个部分的可选项增多了，灵活性增加了，在旧订单列表上进行变更代价较大。
在代码逻辑方面：
Android 侧订单列表过去的多个列表入口均继承自 AbsTradesListFragment，具体继承关系可见下图
各个实现类的页面只是提供了不同的网络请求参数，这种设计好处是对于订单的通用变更，只需要改 AbsTradesListFragment 即可。但缺点也很明显：由于每次变更范围是订单列表，修改时往往又是局部变更，每次需求回归时都需要重新回归整个各个影响，为了减小 UI 变更影响的范围，只能在 AbsTradesListFragment 里写上各种判断逻辑，所以维护成本比较高。同时由于所有业务都堆在 AbsTradesListFragment内，导致代码行数已经达到了 1000 行，这给开发人员维护老的订单逻辑也带来了不少的问题。
原文链接:【https://www.infoq.cn/article/6sqK1yiqEMh2eO7IggPM】。未经作者许可，禁止转载。