烂代码维护重构方法

原则
- 能运行就不要乱动，升级时谨慎观察异常并随时回滚，保证逐渐变好而不是更糟
- 先通过通过系列方式摸清情况：问人、解析代码、加注释、加 log、加 metric
  - 解析代码输出文档：外部架构(上游、下游、依赖组件)、内部分层和模块设计图、性能瓶颈点、逻辑易错点、未来可优化点
  - 关键点加 log：请求的入口 request、出口 response，向外调用的 request、response，数据量大至少要记录 size/offset
  - 关键 metric：请求(路由、调用者、状态码、耗时)、调下游(路由、状态码、耗时)、关键逻辑点监控(频率、分类、告警)
重写
- 如果代码太烂、预计维护重构成本远高于重写，这种代码往往复杂度过高导致不易维护所以本身代码量不算多(重复逻辑和自动生成除外)，可以考虑直接重写
- 确定规模：解析代码和文档，搞清文件夹结构、自动生成结构、基本功能，用工具统计计算有效代码行数，预估工作量
- 确定规模有可行性后，需重新分析需求、设计，做好可观察性的处理以便及时发现问题回滚
- 利用好 Copilot 等代码辅助工具，先写好全部关键注释，预计可自动生成 1/3 代码
逐步重构
- 总体思路是将服务分层、分业务模块，在不同层不同模块内逐步重构替换函数、类、模块
- 服务分层：路由(域名、多层 TLB)、Handler(接入)、Service(业务模块)、Model(封装存储操作)、各种存储的 schema(MySQL、Redis、Kafka)
- 业务划分主要看相关的字段是否紧密耦合，常见的模块：外部依赖、用户、xx 管理…
- 掌握了情况后，可以按问题的”发生频率+破坏程度+恢复难度+紧迫程度”来处理优先级高的模块