用 Claude Code 重构遗留代码：不是让它重写，是让它引路

让 Claude 直接重写一个 2000 行的遗留文件，十次有九次会出问题。正确的用法是把 Claude 当向导，而不是替代品。

错误方式：

# 这会产生一个"干净但不可信"的版本
claude "重写这个文件，用现代 Go 风格"

问题：Claude 不了解所有的历史边界条件、未记录的业务规则、和其他模块的隐式依赖。

正确方式：分层推进

第一步：理解层

claude "分析 legacy_payment.go，列出：
1. 所有公共接口
2. 每个函数的依赖（它调用了什么，谁调用了它）
3. 看起来像 workaround 的代码，标注可能的原因
不要修改任何代码。"

第二步：测试层（在重构之前）

claude "为 ProcessRefund 函数写测试：
- 覆盖所有 return 路径
- 特别关注错误分支
目标：重构后这些测试全部通过"

第三步：小步重构

claude "只重构 processRefundInternal 这一个私有函数：
- 提取魔法数字为常量
- 拆分超过 20 行的语句块
- 不改变任何可观测行为
改完后对比测试结果"

识别"不能动"的代码：

claude "在 legacy_payment.go 里，哪些代码：
1. 有明显的非技术原因（注释提到合规/审计/银行要求）
2. 处理的是边缘案例（但没有测试覆盖）
3. 看起来错误但可能是故意的

列出来，我来决定是否重构这些部分。"

重构进度追踪（TASK.md 模式）：

## 重构 legacy_payment.go

### 不能动的部分
- [ ] L234-267：银行对账格式，合规要求精确匹配
- [ ] L445：金额取整方式，历史数据兼容

### 可以重构
- [x] processRefundInternal：已拆分
- [ ] validatePaymentMethod：过长，待拆分
- [ ] error handling：当前用 panic，改为返回 error

关键原则：测试先于重构

如果没有足够的测试，Claude 的重构是在黑暗中改管道。先投 2 小时写测试，换来的是可信的重构窗口。这不是额外开销，是必要前提。