东莞市专注网站建设,广东深圳房价,公司网站能自己做吗,wordpress get一、重构背景
1.1、退款
到家、小时购、天选退款有2套结构#xff0c;代码逻辑混乱#xff1b;
其中小时购、天选部分售后单是和平生pop交互退款#xff0c;部分是和售后中台交互退款#xff1b;并且兼容3套逻辑#xff1b;
痛点#xff1a;代码繁重#xff0c;缺乏…一、重构背景
1.1、退款
到家、小时购、天选退款有2套结构代码逻辑混乱
其中小时购、天选部分售后单是和平生pop交互退款部分是和售后中台交互退款并且兼容3套逻辑
痛点代码繁重缺乏合理性的设计后续迭代开发以及维护成本高同时增加了系统的风险和不稳定性
1.2、金额计算
到家、小时购两套独立的逻辑结构计算在此基础上针对退差和非退差又实现了2套逻辑
针对商品件维度、商品行维度、售后单维度计算金额混乱缺乏领域边界和分层设计
痛点售后单维度、商品行维度、拆分件维度金额计算混乱代码缺乏层次结构代码易读性、维护成本、后续扩展性存在问题
1.3、售后逆向账
售后单详情接口、申诉单详情接口针对到家和小时购做了两套逻辑
其中售后单详情接口针对小时购黑名单、小时购白名单、天选、到家退差、到家非退差做了5套逻辑处理
并且这两个接口都是实时从拆分获取金额进行售后逆向拆分计算可以直接从数据库中进行取值赋值不需要进行售后单维度的拆分计算
痛点代码大量冗余、改动成本高、增加了系统的风险和不稳定性
二、重构思路和方案
2.1、重构思路
什么是重构呢
名词对软件内部结构的一种调整目的是在不改变软件观察行为的的前提下提高其可理解性、降低其修改成本
动词使用一系列手法在不改变软件可观察行为的前提下调整其结构
重构的目的是使系统或代码更容易被理解、修改、迭代
重构秘诀胆大心细
胆大意味着有勇气和决心去改变和改进现有的代码。重构可能涉及对复杂的代码结构进行修改甚至可能需要重写部分代码。胆大的开发者愿意面对这些挑战相信通过改变可以带来更好的结果
心细指的是在进行重构时保持细致入微的思考和行动。这包括仔细分析代码的结构和逻辑理解代码的功能和依赖关系以及考虑每个重构步骤可能带来的潜在影响。心细的开发者会在重构过程中小心翼翼地处理每个细节以确保代码的正确性和可维护性 把握好重构时机当我发现售后退款、金额计算等业务模块代码存在质量问题、可读性差、可维护性差或存在坏味道时并且在项目需求排期并不紧张的情况下是进行重构的好时机 前期梳理很重要先找到痛点 不宜长线作战不宜和业务并行 明确出目标和价值售后退款、金额计算重构后能提高开发效率、降低维护、开发成本等 确定重构的目标首先要明确需要进行重构的代码块或功能并明确重构的目标是什么。例如可能需要提高代码的可读性、可维护性或性能。 分析代码坏味道使用代码静态分析工具或手动检查代码识别出可能存在的代码坏味道例如退款业务中存在1000多行的类、600多行的方法过多的变量参数、诸多重复代码等代码坏味道。 选择适当的重构技术根据售后代码坏味道的种类和重构的目标选择适当的重构技术。我采用的重构手法是小规模重构–大规模重构–顶层设计模式采用先小后大从大到全的思路进行重构设计。小规模重构提取方法、消除超大类或函数方法、提取类、重命名、合并重复代码等方法大规模重构采用的是分层、模块化、解耦、抽象可复用性等手法设计模式退款业务采用策略模式抽象工厂金额计算业务采用策略模式抽象工厂责任链模式 编写测试用例在进行重构之前编写适当的测试用例来验证重构后的代码的正确性。测试用例应该覆盖重构的代码块或功能的各种情况。 执行重构根据选择的重构技术逐步修改代码。确保每次修改后的代码仍然通过之前编写的测试用例。 运行测试用例在每次重构之后运行之前编写的测试用例确保重构后的代码仍然正确。 重构后的代码评估评估重构后的代码是否达到了预期的目标例如是否提高了代码的可读性、可维护性或性能。
2.2、重构方案
2.2.1、重构前系统交互图 2.2.2、重构后系统交互图 退款业务强耦合到售后系统中并且业务代码分散到各个业务层严重缺乏系统的领域边界和分层设计重构后退款业务逻辑不强依赖售后核心业务逻辑做到可以独立部署。
2.2.3、重构前金额计算流程图 2.2.4、重构后金额计算流程图 将2套金额计算业务逻辑利用设计模式将其合并为1套金额计算业务逻辑打造防腐层
2.3、重构设计类图
依据上述制定的设计方案流程图我进行了UML类图的绘制以下是关于金额计算业务模块的类图
2.3.1、抽象工厂策略模式类图 2.3.2、责任链模式类图 三、系统稳定性保障
3.1、小步重构
将售后重构分成退款、金额计算、逆向账三个步骤并在每个步骤之后运行测试用例。这样可以及时发现并修复引入的错误避免错误在整个系统中蔓延
3.2、逐步验证
在每个重构步骤之后进行系统的逐步验证。分批次进行上线灰度灰度配置绝对隔离不能复用。确保系统的各个部分在重构过程中都能正常运行并与其他部分协调良好。
3.3、监控和性能测试
在重构完成后进行系统的监控和性能测试确保重构没有引入性能问题或影响系统的稳定性。如果发现问题及时进行修复和优化。
3.4、团队代码审查和测试
在进行重构时与团队成员进行合作并进行代码审查。多个人的视角和经验可以帮助发现潜在的问题并提供改进的建议针对重构代码进行深度解刨能更有效地保障重构的安全性。
重构业务及时通知测试人员使测试人员能够评估到测试点更加完善测试用例
3.5、灰度步骤
3.5.1、bcp持续比对校验 3.5.2、按照商家灰度
依据售后单量 小-中-大 的顺序逐步进行灰度切量观察其退款、金额计算等售后单数据是否异常
四、重构成果 降低开发、维护成本 提升代码质量、系统稳定性 系统扩展性和灵活性的加强 系统应用、业务边界定位更加清晰 统一和规范售后核心业务脉络降低业务学习成本提升开发效率 提升自己的技术能力、代码质量意识、问题解决能力、团队合作和沟通能力经典著作《重构》这本书中有这么一段话
一开始我所做的重构都停留在细枝末节上。随着代码趋向简洁我发现自己可以看到一些设计层面的东西了这些是我以前理解不到的如果没有重构我达不到这种高度
五、code show
5.1、重构前金额计算
到家售后单金额计算service方法 京东售后单金额计算service方法
一个大的金额计算class类就有1000多行代码每个方法中都有几百行代码以下是到家售后单金额计算部分代码 5.2、重构后金额计算
到家和京东售后单金额计算用同一个接口才承接业务实现并且使用策略抽象工厂模式实现到家、小时购、天选业务的金额计算 策略模式获取金额拆分结果集 金额计算核心方法只有4步骤 其中金额计算的核心则采用的是责任链业务进行计算 在件维度、sku维度针对不同的业务又采用了责任链模式进行金额计算 六、参考文献
代码的坏味道 https://www.qinglite.cn/doc/87036476d565d55f9
《重构改善既有代码的设计》[美]MartinFowler
《敏捷软件开发》[美]RobertC.Martin 作者京东零售 高凯 来源京东云开发者社区 转载请注明来源
