重构的铁律是“不改变外部行为”：改动只优化内部结构，功能必须保持不变。因此测试是不可或缺的安全网——没有测试，重构就是裸奔。
重构要小步进行：一次一个小改进，跑通测试再继续，避免大范围改动一次翻车。
判断标准：重构后功能完全相同、代码更易读更易改，才是成功的重构。
代码不是写一次就完事，而是持续重构出来的。好代码的共同特征是“易读、易改、易测”——这些都不是写出来的，是改出来的。
重构的核心红线是“不改变外部行为”：所有改动都要在测试的保驾护航下小步进行，让代码质量与业务演进并行不悖。
识别这些信号，就知道该重构了。
职责不清，拆解。
提取复用。
重命名表达意图。
用对象封装。
拆分职责。
提前返回、扁平化。
让重构有保障地进行。
重构前确保关键路径有测试兜底，没有先补。
把重构拆成小步，一次一个改动，保持可运行。
每步跑测试验证行为不变，出问题及时回退。
重构融入日常，随手清理坏味道，避免积重难返。
高频重构技巧。
| 手法 | 用途 |
|---|---|
| 提取函数 | 拆分过长函数 |
| 重命名 | 表达真实意图 |
| 提炼变量 | 消除魔法值 |
| 引入对象 | 封装数据泥团 |
| 减少嵌套 | 提前返回 |
核心逻辑没有测试时，先补测试再重构，否则改动的风险不可控。测试是重构的前提。
两个原则：重构不夹带功能，加功能不顺手重构。分开做，各自可控、易于回溯。
有小步验证与测试兜底，风险可控。出了问题回退上一步，损失很小。
即将重写/废弃的代码、一次性脚本，不值得投入。重构要花在有长期价值的代码上。
重构不改变行为、小步进行、持续可用；重写推倒重来、周期长、风险高。能重构就别重写。
用“可维护性债”说话：坏味道导致的需求改动成本、Bug 率、新成员上手成本，都是可量化的账。
“把重构融入日常，坏味道随手清理，代码库再没出现过“不敢动”的模块。”
— 某中大型团队 · 技术负责人“没有测试时我坚决不重构，先补测试再动手，风险完全可控。”
— 某研发团队 · 资深工程师“一次一个小步、每步跑测试，重构几个月从没引入过线上故障。”
— 某金融系统 · 后端工程师把相关知识串成体系，继续深入。
