Categories
程式開發

微商城订单模块重构实践


背景

订单是电商服务的核心场景之一,微商城客户端的订单模块已经服务了商家多年,功能和体验上和 PC 端有一定的差距。为了弥补不足,提升商家的体验,产品经过一系列数据调研,发起了微商城订单模块的重构项目。

作为“乐于重构”的开发者,在此次重构中以增强代码维护性以及线上稳定性为目的,接受了这次挑战。接下来将从业务代码架构、历史代码改造两方面,简单地聊一聊我们在此次重构中的一些经验。

一、业务代码架构的改进

1.1 组件拆分

微商城订单模块重构实践 1

上图为旧订单列表和新订单列表的截图

微商城订单模块重构实践 2

上图是新订单列表中订单状态配置和筛选项配置的截图

不论是新订单列表还是旧订单列表,页面核心功能区域 UI 均分为订单状态、订单类型、及订单卡片列表三个部分。这部分基础的逻辑并没有变更,但是每个部分的可选项增多了,灵活性增加了,在旧订单列表上进行变更代价较大。

在代码逻辑方面:

Android 侧订单列表过去的多个列表入口均继承自 AbsTradesListFragment,具体继承关系可见下图

微商城订单模块重构实践 3

各个实现类的页面只是提供了不同的网络请求参数,这种设计好处是对于订单的通用变更,只需要改 AbsTradesListFragment 即可。但缺点也很明显:由于每次变更范围是订单列表,修改时往往又是局部变更,每次需求回归时都需要重新回归整个各个影响,为了减小 UI 变更影响的范围,只能在 AbsTradesListFragment 里写上各种判断逻辑,所以维护成本比较高。同时由于所有业务都堆在 AbsTradesListFragment内,导致代码行数已经达到了 1000 行,这给开发人员维护老的订单逻辑也带来了不少的问题。

原文链接:【https://www.infoq.cn/article/6sqK1yiqEMh2eO7IggPM】。未经作者许可,禁止转载。