chuxinneko/nekocodedesktop/refactor-safely

安全重构

重构的定义是改变结构、不改变行为。一旦顺手改了行为，出问题时就分不清是重构错了还是新逻辑错了。

要改行为就单独做，并且说明白。

动手前的三个前提

缺一个就先补上，不要跳过：

1. 有可验证的基线。跑一遍现有测试并记下结果。没有测试覆盖到要改的部分时，先补一个刻画当前行为的测试（characterization test）——哪怕当前行为看起来是错的，也先把它钉住，重构完再单独讨论要不要改。
2. 工作区是干净的。git status 确认没有未提交的无关改动，这样出问题可以一键回退。
3. 知道调用方是谁。改函数签名前先全局搜引用（包括测试、字符串形式的动态调用、注释里的文档）。

小步走

每一步都应该小到：改完能立刻跑测试，出错能立刻回退。

典型的安全步骤：

• 改名（先用工具/全局替换，一次只改一个符号）
• 提取函数（把一段连续逻辑原样搬走，参数和返回值照抄，不顺手改逻辑）
• 内联（只有一个调用点的间接层，搬回去）
• 移动（把函数挪到更合适的模块，先不改内容）
• 替换实现（新旧并存 → 切换调用方 → 删旧的，分三次）

不要一次做两种。改名和提取同时做，diff 就没法读了。

每步之后：跑测试 → 通过 → 继续。失败就立刻回退这一步，而不是在错误的基础上继续改。

消除重复的判断

看到相似代码先别急着合并。问：

• 这两处将来会不会一起变？会，才该合并；不会一起变的相似代码合并后，下次改动要加参数把它们劈开，比重复更糟。
• 合并后的函数需要几个布尔参数来区分行为？需要两个以上，说明它们本来就是不同的东西。

三处以上的重复、且逻辑确实同源，才值得抽象。两处相似，通常先留着。

不要顺手做的事

重构时最容易失控的几件事，明确不做：

• 不改公开 API 的行为（返回值形状、抛错时机、是否修改入参）。
• 不"顺便"修 bug。发现了就记下来，重构完单独提。
• 不扩大范围。为了让某处更整齐而改动十个文件，会让这次改动无法审查。
• 不删除看不懂的代码。先查 git log -S 弄清它为什么存在——看起来多余的判断常常是某次线上事故留下的。
• 不改格式和逻辑混在一起。格式化单独一次提交。

完成后的自检

• 测试结果和基线完全一致——通过数、失败数都一样。有新的失败就是行为变了。
• git diff 自己读一遍：每一处改动都能说出"这是哪一步"。说不出来的就是混进来的东西。
• 公开接口没有变化；如果变了，确认所有调用方都改了，并在报告里说明。
• 代码确实比之前好读了。说不清哪里更好，就说明这次重构没有必要。

报告

说明：改了什么结构、为什么、分了哪几步、测试前后的结果对比。 顺带发现但没有处理的问题（bug、坏味道、缺测试）单独列出来，交给用户决定要不要做。