面对一团糟的祖传代码，别急着骂娘，也别一上来就重构。先活下来，再搞明白，最后才动手改。
1. 让代码跑起来是第一要务
- 能编译、能运行、能看到日志，比看100遍源码都强
- 先配好环境，哪怕是在本地 hack 数据库连接字符串也要跑通
- 小技巧：在
main或接口入口加个打印，确认这行代码真的会执行
2. 从"入口"往"里"追，别从"里"往"入口"猜
- 找 HTTP 接口、定时任务、MQ 消费者这些触发点
- 用 IDE 的"查找用法"（Find Usages）反向追踪，别靠全文搜索猜调用关系
- 画一张简单的调用链：Controller → Service → DAO，先理主干，不管细节
3. 先找"边界"和"契约"
- 关注输入输出：这个方法接收什么参数？返回什么？抛哪些异常？
- 关注外部依赖：调了哪些数据库表？发了什么 MQ？调了第三方接口吗？
- 把这些外部交互点列出来，你就掌握了 70% 的业务逻辑
4. 用"特征测试"（Characterization Test）锁定行为
- 在改动前，先写个单元测试把当前输出记录下来（哪怕结果是错的）
- 目的不是验证正确性，而是确保你改完后，输出没变（或明确知道变了哪里）
- 示例：原来代码返回
null，你的测试就断言返回null，重构后再改正确逻辑
5. 打印日志比断点更管用
- 在关键路径插临时日志：
log.info("=== 进入xx方法，参数：{}", param) - 跑一遍业务场景，看日志流向，比静态看代码效率高 10 倍
- 用完记得删或改 debug 级别，别留垃圾
6. 别试图一次看懂全部
- 第一次梳理只关注你要改的那个小功能涉及的路径
- 其他分支标注"TODO：黑盒，暂不关心"
- 代码是渐进的，改一次懂一块，三个月后就全熟了
7. 善用 Git 历史当"文档"
git blame看最后谁改的，直接去找人问（如果还在职）- 看提交信息里的需求单号，去 Jira/禅道找原始需求背景
- 对比半年前版本的代码，看哪些是被"临时修补"坏的
8. 边读边写"脏文档"
- 准备一个 markdown 文件，边读边记：坑点、魔法数字含义、奇怪的 if 条件
- 不用写得漂亮，关键词就行，比如：
// 这里 if(x==3) 是因为历史数据兼容 - 下次再来改时，你会感谢自己
9. 重构前先复制一份
- 对要改的方法，先整体复制命名为
xxx_old，注释掉备用 - 改崩了能瞬间回滚，心理有底才敢动手
- 确认没问题后，再删旧代码
10. 承认有些代码就是屎山，别幻想洗干净
- 只要业务还在跑，能不动就不动
- 核心业务逻辑外面包"防腐层"，别钻进去改
- 记住：你的目标是完成需求，不是获得代码洁癖奖状
一句话总结：遗留代码面前，"胆小甚微"是美德，"大胆假设"是找死。先当考古学家，再当建筑师。