下面是个人纯经验分享，希望对你有帮助。

重构目标：之前代码已成为屎山，维护起来牵一发而动全身，现在需要新写代码来提升代码的可维护性、可扩展性、可读性、可观测性。下面是一些技巧：
- 可维护性：避免过度抽象，类、方法、接口满足单一原则；统一规范（某个概念要全链路命名一致，DTO 、BO 、DO 每一层都要定义单独的对象出来便于后续不同层级加字段时不影响其他层级）；数据库表预留扩展性字段；
- 可扩展性：如果业务频繁变动，是否可以把业务流程抽象为「配置化 + 核心框架」，后续只需要变更配置和新实现一些约定的接口就行，而不需要改动核心框架，类似于 Spring 帮我们实现了 IoC 的核心框架，我们想扩展只需要配置化或实现扩展点接口（ BeanPostProcessor ）即可。
- 可读性：写方法要满足单一抽象层次；复杂流程注释写好 1 、2 、3 流程的 what 、why 、how ；
- 可观测性：打好日志；接口入口处统一做好基于错误码（业务异常抛出的特定错误码）的阈值监控，系统异常直接钉钉告警。

重构 SOP：
* 事前：
* 重构代码要对整个业务逻辑有全面的了解，多问几个 why 。
* 要彻底搞通「重构代码逻辑如何闭环、新老数据差异点、新老字段含义映射」这些方面，不能一知半解。
* 对使用的依赖（接口、工具方法）要熟悉它的逻辑。
* 日志打好、打全。
* 测试用例要覆盖全。
* 事中：
* 做好 360 无死角监控告警，且要有灰度策略。
* 灰度放量后仔细观察日志（错误日志）、DB 表中的核心字段（单号、金额、币种、状态），核查字段应不应该有值（有值都有值，要没值都没值）、值对不对（长度、格式、金额是最小单位还是原金额等要求）。
* 事后：
* 出现问题要优先考虑业务影响（统计受影响的订单数、金额，客户感知），然后再去想最坏的打算，如何补救。

重构注意事项
1. 重构时只搞一部分逻辑，不要把多个功能同时重构。要进行任务拆解，按照计划有节奏来。如果系统太复杂，可以拆分为多期，分几期去上线。
> 任务拆分： https://mp.weixin.qq.com/s/lY1djkQGK0e5yMIm4ZnkbQ
2. 重构的时间节奏是否和业务发展相匹配。
3. 先专注于跑通主流程，再钻研细节。
4. 以始为终，做的过程中始终回想重构的目标，避免偏离方向。