同城售后系统退款业务重构心得

一、重构背景

1.1、退款

到家、小时购、天选退款有2套结构，代码逻辑混乱；

其中小时购、天选部分售后单是和平生pop交互退款，部分是和售后中台交互退款；并且兼容3套逻辑；

痛点：代码繁重，缺乏合理性的设计，后续迭代开发以及维护成本高，同时增加了系统的风险和不稳定性

1.2、金额计算

到家、小时购两套独立的逻辑结构计算，在此基础上针对退差和非退差又实现了2套逻辑；

针对商品件维度、商品行维度、售后单维度计算金额混乱，缺乏领域边界和分层设计；

痛点：售后单维度、商品行维度、拆分件维度金额计算混乱，代码缺乏层次结构；代码易读性、维护成本、后续扩展性存在问题

1.3、售后逆向账

售后单详情接口、申诉单详情接口，针对到家和小时购做了两套逻辑；

其中售后单详情接口针对小时购黑名单、小时购白名单、天选、到家退差、到家非退差做了5套逻辑处理；

并且这两个接口都是实时从拆分获取金额进行售后逆向拆分计算，可以直接从数据库中进行取值赋值，不需要进行售后单维度的拆分计算；

痛点：代码大量冗余、改动成本高****、增加了系统的风险和不稳定性

二、重构思路和方案

2.1、重构思路

什么是重构呢？

名词：对软件内部结构的一种调整，目的是在不改变软件观察行为的的前提下提高其可理解性、降低其修改成本；

动词：使用一系列手法，在不改变软件可观察行为的前提下，调整其结构

重构的目的是使系统或代码更容易被理解、修改、迭代

重构秘诀：胆大心细

胆大（意味着有勇气和决心去改变和改进现有的代码。重构可能涉及对复杂的代码结构进行修改，甚至可能需要重写部分代码。胆大的开发者愿意面对这些挑战，相信通过改变可以带来更好的结果）

心细（指的是在进行重构时保持细致入微的思考和行动。这包括仔细分析代码的结构和逻辑，理解代码的功能和依赖关系，以及考虑每个重构步骤可能带来的潜在影响。心细的开发者会在重构过程中小心翼翼地处理每个细节，以确保代码的正确性和可维护性）

把握好重构时机：当我发现售后退款、金额计算等业务模块代码存在质量问题、可读性差、可维护性差或存在坏味道时，并且在项目需求排期并不紧张的情况下，是进行重构的好时机；
前期梳理很重要，先找到痛点；不宜长线作战，不宜和业务并行
明确出目标和价值：售后退款、金额计算重构后能提高开发效率、降低维护、开发成本等
确定重构的目标：首先要明确需要进行重构的代码块或功能，并明确重构的目标是什么。例如，可能需要提高代码的可读性、可维护性或性能。
分析代码坏味道：使用代码静态分析工具或手动检查代码，识别出可能存在的代码坏味道；例如退款业务中存在1000多行的类、600多行的方法，过多的变量参数、诸多重复代码等代码坏味道。
选择适当的重构技术：根据售后代码坏味道的种类和重构的目标，选择适当的重构技术。我采用的重构手法是：小规模重构-->大规模重构-->顶层设计模式；采用先小后大，从大到全的思路进行重构设计。小规模重构：提取方法、消除超大类或函数方法、提取类、重命名、合并重复代码等方法；大规模重构：采用的是分层、模块化、解耦、抽象可复用性等手法；设计模式：退款业务采用策略模式+抽象工厂；金额计算业务采用策略模式+抽象工厂+责任链模式
编写测试用例：在进行重构之前，编写适当的测试用例来验证重构后的代码的正确性。测试用例应该覆盖重构的代码块或功能的各种情况。
执行重构：根据选择的重构技术，逐步修改代码。确保每次修改后的代码仍然通过之前编写的测试用例。
运行测试用例：在每次重构之后，运行之前编写的测试用例，确保重构后的代码仍然正确。
重构后的代码评估：评估重构后的代码是否达到了预期的目标，例如是否提高了代码的可读性、可维护性或性能。