1.1、退款
1.2、金额计算
1.3、售后逆向账
2.1、重构思路
-
把握好重构时机 :当我发现售后退款、金额计算等业务模块代码存在质量问题、可读性差、可维护性差或存在坏味道时,并且在项目需求排期并不紧张的情况下,是进行重构的好时机; -
前期梳理很重要 ,先找到痛点 ; 不宜长线作战 ,不宜和业务并行; -
明确出目标和价值 : 售后退款、金额计算重构后能提高开发效率、降低维护、开发成本等; -
确定重构的目标 : 首先要明确需要进行重构的代码块或功能,并明确重构的目标是什么。 例如,可能需要提高代码的可读性、可维护性或性能; -
分析代码坏味道 :使用代码静态分析工具或手动检查代码,识别出可能存在的代码坏味道 ;例如退款业务中存在1000多行的类、600多行的方法,过多的变量参数、诸多重复代码等代码坏味道 ; -
选择适当的重构技术 :根据售后代码坏味道 的种类和重构的目标,选择适当的重构技术。我采用的重构手法是:小规模重构-->大规模重构-->顶层设计模式;采用先小后大,从大到全的思路进行重构设计。小规模重构:提取方法、消除超大类或函数方法、提取类、重命名、合并重复代码等方法;大规模重构:采用的是分层、模块化、解耦、抽象可复用性等手法;设计模式:退款业务采用策略模式+抽象工厂;金额计算业务采用策略模式+抽象工厂+责任链模式; -
编写测试用例 : 在进行重构之前,编写适当的测试用例来验证重构后的代码的正确性。 测试用例应该覆盖重构的代码块或功能的各种情况; -
执行重构 : 根据选择的重构技术,逐步修改代码。 确保每次修改后的代码仍然通过之前编写的测试用例; -
运行测试用例 : 在每次重构之后,运行之前编写的测试用例,确保重构后的代码仍然正确; -
重构后的代码评估 : 评估重构后的代码是否达到了预期的目标,例如是否提高了代码的可读性、可维护性或性能。
2.2、重构方案
2.2.1、重构前系统交互图
2.2.3、重构前金额计算流程图
2.3、重构设计类图
2.3.1、抽象工厂+策略模式类图
3.1、小步重构
3.2、逐步验证
3.3、监控和性能测试
3.4、团队代码审查和测试
3.5、灰度步骤
3.5.1、bcp持续比对校验
-
降低开发、维护成本 -
提升代码质量、系统稳定性 -
系统扩展性和灵活性的加强; -
系统应用、业务边界定位更加清晰 -
统一和规范售后核心业务脉络,降低业务学习成本,提升开发效率 -
提升自己的技术能力、代码质量意识、问题解决能力、团队合作和沟通能力; 经典著作《重构》这本书中有这么一段话:
5.1、重构前金额计算
参考资料
[1] 代码的坏味道:https://www.qinglite.cn/doc/87036476d565d55f9
[3] 《敏捷软件开发》:[美]RobertC.Martin
-end-
本文分享自微信公众号 - 京东云开发者(JDT_Developers)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
{{o.name}}
{{m.name}}