重构的节奏：小步提交与随时可回滚

重构失败的典型剧本：开一个 refactor 分支改三周，越改越大，与主干的冲突越滚越多，最后要么硬合出事故，要么整个分支废弃。问题不在重构本身，在节奏。

小步原则的三个具体化

1. 每一步都可验证。

重构的每一小步 = 行为不变 + 测试通过 + 可独立提交。典型序列：

1. 补测试，锁定现有行为
2. 提取函数（行为不变）
3. 移动到新模块（行为不变）
4. 改内部实现（行为不变）
5. 重复

行为变更和结构调整永远不放在同一次提交。混在一起，出问题时无法二分定位。

2. 与主干保持小时级同步。

长分支是重构的头号杀手。每天至少 rebase 一次主干，冲突当场解决——积累一周的冲突足以摧毁继续重构的意愿。

3. 随时可停。

任何时刻放弃重构、直接上线，代码都应该处于可用状态。做到这点的前提是：功能开关隔离新旧路径，重构期间业务不依赖「重构完成」。

绞杀者模式：对付大泥球

整体重写风险太高时，用绞杀者模式（Strangler Fig）逐步替换：

旧服务 ──→ 网关按路由分流 ──→ 新服务（逐接口迁移）
              │
              └─ 未迁移的仍走旧服务

按接口粒度迁移，每迁一个验证一个，旧代码在流量归零后退役。全程可回滚——把路由切回去就行。

两个判断标准

该不该重构：这块代码的修改频率 × 每次修改的成本，是否已经超过重构本身的投入。低频改动的烂代码，放着不动是理性决策。

重构还是重写：行为是否有可靠的测试锚点。有，重构；没有，先补测试或用绞杀者重写。没有行为锚点的「重写」，本质是赌博。

最后一条经验

把「重构」写成独立的 commit message 前缀（refactor:），并在 PR 描述里明确「行为无变化、验证方式为回归测试全绿」。这让评审者把注意力放在结构上，也让 git 历史变成可信的证据链。