重构基础

重构（Refactoring）是在 不改变外部行为 的前提下，改善代码内部结构。路线图 refactoring 节点强调 小步、可验证：每改一步跑测试，而不是「大手术一次改完」。没有绿测的重构是赌博。

学习目标

• 理解重构的定义与「小步提交」节奏
• 会使用提取方法、重命名、搬移类等常见手法
• 知道重构前需有 testing-essentials 提供的安全网

何时重构

适合时机：

• 刚写完功能、测试绿，结构仍乱（童子军规则：离开时比来时干净）
• 修 bug 时发现根因是结构问题
• 加新需求时，旧设计明显挡路

不适合：无测试、无需求、纯「看着不顺眼」大改。先补关键路径测试，或在新分支隔离实验。

小步安全流程

1. 确保测试绿（或先写 characterization test）
2. 做一步机械重构（如 Extract Method）
3. 跑测试 → 绿则 commit
4. 重复；行为变更另开 PR

与 git-essentials 的 atomic commit 一致：一个 commit 只做一类重构，方便 git bisect。

常用手法（直觉）

手法	场景
提取方法	长方法、重复块
重命名	误导性变量名
搬移方法	类职责错位
以多态取代条件	冗长 switch/if-else

Spring Service 里若业务逻辑与持久化缠在一起，可先提取纯函数再测，参考 spring-boot-essentials。用 AI 辅助重构时，务必人工 diff 每步，见 ai-coding-essentials（若有）或 ai-review 的「禁止一次改太多文件」原则。

与坏味道

重构常由 代码坏味道 触发——下一课 cq-smells 会列长方法、重复、过大类。记住：先识别 smell，再选手法，测试全程在线。

练习

• 在 backend 找一个 <30 行的 private 方法，练习 Extract Method 并跑 mvn test
• 用 git log --oneline -5 看最近提交粒度是否便于回滚
• 读一篇 diff，区分「行为变更」与「纯重构」各几处

小结

重构 = 行为不变 + 结构更好 + 测试守护 + 小步 commit。 下一课识别代码坏味道，决定「该不该动刀」。