京东秒送售后系统退款业务重构心得| 京东零售技术团队
一、重构背景
1.1、退款
京东秒送秒送退款有2套结构,代码逻辑混乱;
其中秒送、天选部分售后单是和平生pop交互退款,部分是和售后中台交互退款;并且兼容3套逻辑;
痛点:代码繁重,缺乏合理性的设计,后续迭代开发以及维护成本高,同时增加了系统的风险和不稳定性
1.2、金额计算
京东秒送两套独立的逻辑结构计算,在此基础上针对退差和非退差又实现了2套逻辑;
针对商品件维度、商品行维度、售后单维度计算金额混乱,缺乏领域边界和分层设计;
痛点:售后单维度、商品行维度、拆分件维度金额计算混乱,代码缺乏层次结构;代码易读性、维护成本、后续扩展性存在问题
1.3、售后逆向账
售后单详情接口、申诉单详情接口,针对京东秒送秒送做了两套逻辑;
其中售后单详情接口针对秒送黑名单、秒送白名单、天选、秒送退差、秒送非退差做了5套逻辑处理;
并且这两个接口都是实时从拆分获取金额进行售后逆向拆分计算,可以直接从数据库中进行取值赋值,不需要进行售后单维度的拆分计算;
痛点:代码大量冗余、改动成本高、增加了系统的风险和不稳定性
二、重构思路和方案
2.1、重构思路
什么是重构呢?
名词:对软件内部结构的一种调整,目的是在不改变软件观察行为的的前提下提高其可理解性、降低其修改成本;
动词:使用一系列手法,在不改变软件可观察行为的前提下,调整其结构
重构的目的是使系统或代码更容易被理解、修改、迭代
重构秘诀:胆大心细
胆大(意味着有勇气和决心去改变和改进现有的代码。重构可能涉及对复杂的代码结构进行修改,甚至可能需要重写部分代码。胆大的开发者愿意面对这些挑战,相信通过改变可以带来更好的结果)
心细(指的是在进行重构时保持细致入微的思考和行动。这包括仔细分析代码的结构和逻辑,理解代码的功能和依赖关系,以及考虑每个重构步骤可能带来的潜在影响。心细的开发者会在重构过程中小心翼翼地处理每个细节,以确保代码的正确性和可维护性)
2.2、重构方案
2.2.1、重构前系统交互图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-26-11-376gFGFKNu12gfcLVl.jpg)
2.2.2、重构后系统交互图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-14-36ObaevqtLBg9cVzc.jpg)
退款业务强耦合到售后系统中,并且业务代码分散到各个业务层,严重缺乏系统的领域边界和分层设计,重构后退款业务逻辑不强依赖售后核心业务逻辑,做到可以独立部署。
2.2.3、重构前金额计算流程图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-14-36iGWAfxWUQyTZ36p7.jpg)
2.2.4、重构后金额计算流程图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-14-36j10tVMXAKR9byPI10.jpg)
将2套金额计算业务逻辑利用设计模式将其合并为1套金额计算业务逻辑,打造防腐层
2.3、重构设计类图
依据上述制定的设计方案流程图,我进行了UML类图的绘制,以下是关于金额计算业务模块的类图
2.3.1、抽象工厂+策略模式类图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-26-20-06MV8CDpmNrSRORvC.jpg)
2.3.2、责任链模式类图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-19-53VbsjALJmOdmrz24d.jpg)
三、系统稳定性保障
3.1、小步重构
将售后重构分成退款、金额计算、逆向账三个步骤,并在每个步骤之后运行测试用例。这样可以及时发现并修复引入的错误,避免错误在整个系统中蔓延
3.2、逐步验证
在每个重构步骤之后,进行系统的逐步验证。分批次进行上线灰度,灰度配置绝对隔离,不能复用。确保系统的各个部分在重构过程中都能正常运行,并与其他部分协调良好。
3.3、监控和性能测试
在重构完成后,进行系统的监控和性能测试,确保重构没有引入性能问题或影响系统的稳定性。如果发现问题,及时进行修复和优化。
3.4、团队代码审查和测试
在进行重构时,与团队成员进行合作,并进行代码审查。多个人的视角和经验可以帮助发现潜在的问题,并提供改进的建议;针对重构代码进行深度解刨,能更有效地保障重构的安全性。
重构业务及时通知测试人员,使测试人员能够评估到测试点,更加完善测试用例
3.5、灰度步骤
3.5.1、bcp持续比对校验
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-18-21kccs6qUAZpiH6EU.jpg)
3.5.2、按照商家灰度
依据售后单量 小->中->大 的顺序逐步进行灰度切量,观察其退款、金额计算等售后单数据是否异常
四、重构成果
一开始,我所做的重构都停留在细枝末节上。随着代码趋向简洁,我发现自己可以看到一些设计层面的东西了,这些是我以前理解不到的,如果没有重构,我达不到这种高度
五、code show
5.1、重构前金额计算
京东秒送售后单金额计算service方法
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-09-48tXfxTmDVTYxiqL16.png)
一个大的金额计算class类就有1000多行代码,每个方法中都有几百行代码,以下是京东秒送售后单金额计算部分代码
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-09-50uDZh16VsDJXeOO9R.png)
5.2、重构后金额计算
京东秒送售后单金额计算用同一个接口才承接业务实现,并且使用策略+抽象工厂模式实现秒送、天选业务的金额计算
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-10-24-16-06zo6Ussx10DiTM9aZ.png)
策略模式获取金额拆分结果集
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-10-03O459NymhjZJRZPCe.png)
金额计算核心方法只有4步骤
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-09-51rMeVeJAC8tQ0Sws.png)
其中金额计算的核心则采用的是责任链业务进行计算
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-09-52Gl16VCqoLFQk9D9e.png)
在件维度、sku维度针对不同的业务又采用了责任链模式进行金额计算
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-16-09-53aO53XnioQ53GjRusI.png)
六、参考文献
代码的坏味道: https://www.qinglite.cn/doc/87036476d565d55f9
《重构改善既有代码的设计》:[美]MartinFowler
《敏捷软件开发》:[美]RobertC.Martin