同城售后系统退款业务重构心得 | 京东云技术团队
一、重构背景
1.1、退款
到家、小时购、天选退款有2套结构，代码逻辑混乱；
其中小时购、天选部分售后单是和平生pop交互退款，部分是和售后中台交互退款；并且兼容3套逻辑；
痛点：代码繁重，缺乏合理性的设计，后续迭代开发以及维护成本高，同时增加了系统的风险和不稳定性
1.2、金额计算
到家、小时购两套独立的逻辑结构计算，在此基础上针对退差和非退差又实现了2套逻辑；
针对商品件维度、商品行维度、售后单维度计算金额混乱，缺乏领域边界和分层设计；
痛点：售后单维度、商品行维度、拆分件维度金额计算混乱，代码缺乏层次结构；代码易读性、维护成本、后续扩展性存在问题
1.3、售后逆向账
售后单详情接口、申诉单详情接口，针对到家和小时购做了两套逻辑；
其中售后单详情接口针对小时购黑名单、小时购白名单、天选、到家退差、到家非退差做了5套逻辑处理；
并且这两个接口都是实时从拆分获取金额进行售后逆向拆分计算，可以直接从数据库中进行取值赋值，不需要进行售后单维度的拆分计算；
痛点：代码大量冗余、改动成本高、增加了系统的风险和不稳定性
二、重构思路和方案
2.1、重构思路
什么是重构呢？
名词：对软件内部结构的一种调整，目的是在不改变软件观察行为的的前提下提高其可理解性、降低其修改成本；
动词：使用一系列手法，在不改变软件可观察行为的前提下，调整其结构
重构的目的是使系统或代码更容易被理解、修改、迭代
重构秘诀：胆大心细
胆大（意味着有勇气和决心去改变和改进现有的代码。重构可能涉及对复杂的代码结构进行修改，甚至可能需要重写部分代码。胆大的开发者愿意面对这些挑战，相信通过改变可以带来更好的结果）
心细（指的是在进行重构时保持细致入微的思考和行动。这包括仔细分析代码的结构和逻辑，理解代码的功能和依赖关系，以及考虑每个重构步骤可能带来的潜在影响。心细的开发者会在重构过程中小心翼翼地处理每个细节，以确保代码的正确性和可维护性）
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
作者：京东零售 高凯
来源：京东云开发者社区 转载请注明来源
关注公众号 低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。
- 上一篇
查询平均提速 700%，奇安信基于 Apache Doris 升级日志安全分析系统
本文导读：数智时代的到来使网络安全成为了不可忽视的重要领域。奇安信作为一家领先的网络安全解决方案领军者，致力于为企业提供先进全面的网络安全保护，其日志分析系统在网络安全中发挥着关键作用，通过对运行日志数据的深入分析，能够对漏洞和异常行为生成关键见解，帮助企业建立有效的防御策略。本文将深入探讨奇安信在网络安全与日志分析解决方案的关键优势，了解基于 Apache Doris 构建的全新一体化日志存储分析平台如何实时监测和分析日志事件，加强对可疑活动的追踪与应对，提升系统安全性与快速响应能力。（作者｜奇安信 服务端技术专家 舒鹏） 奇安信是中国企业级网络安全市场的领军者，专注于为政府和企业用户提供新一代网络安全产品和服务。目前核心产品天擎终端安全系统在国内已有 4000 万政企用户部署、全国部署服务器超过 100 万台、服务超 40 万大型机构。作为网络安全国家队，奇安信立志为国家构建安全的网络空间，在终端安全、云安全、威胁情报、态势感知等领域的技术研发持续领先。 随着现代企业数字化转型的不断深化，大数据、物联网、5G 等创新技术的广泛应用加速了企业的数字化转型步伐，这使得原先的网络边界被打...
- 下一篇
【行云流水线实践】基于“OneBuild”方法对镜像进行快速装箱 | 京东云技术团队
在云原生领域，无论使用哪种编排调度平台，Kubernetes，DockerSwarm，OpenShift等，业务都 需要基于镜像进行交付，我们在内部实践“Source-to-image”和链式构建，总而总结出“OneBuild”模式。 其核心思想是：一处构建，多处使用。 问题 一般，我们会使用类似Jenkins CI系统来构建镜像，以满足持续集成，持续开发，持续交付等场景。事实上，如果我们在某一方面能够提升效率或者解决镜像交付实践。 长期来看，将能够带来不少的成本收益，并且对于平台来讲，这种收益是一种可度量收益。假设我们在当前交付（git）分支中，需要fix或者feature已经release分支的，如何进行？如果在已经交付给用户的镜像中存在漏洞，需要批量交付，如何进行？为了解决这些问题，我们的团队必须重新构建镜像，并且找出基本镜像，构建过程有那些依赖关系。然后基于这些成熟的流程和规范进行快速交付。 解决方案 Docker build是大家比较常用的镜像构建方法，并且在构建中只需要声明自己的Dockerfile即可，就可以实现快速构建。但是这并不满足大型企业实践以及快速交付。 所以需要...
相关文章
文章评论
共有0条评论来说两句吧...
微信收款码
支付宝收款码