14.2 批量代码重构技巧

当你面对成百上千处需要修改的重复代码模式（如统一修改日志格式、替换废弃API、调整命名规范）时，手动逐行修改既不现实也容易出错。以下是经过实战验证的批量重构方法：

1. 先锁定范围，再动手

不要全局搜索替换。先用 IDE 的"Find Usages"或git grep精确锁定影响范围，导出为文件列表。例如：

# 先列出所有包含目标模式的文件
git grep -l "oldFunction(" > target_files.txt

确认列表无误后，再针对这些文件操作，避免误伤第三方库或历史分支代码。

2. 结构化替换优于文本替换

避免简单字符串替换，优先使用基于 AST（抽象语法树）的工具：

• IntelliJ IDEA：使用 Structural Search and Replace（结构搜索替换），可精准匹配"函数调用但不在注释中"的场景
• VS Code：配合 AST 插件（如 jscodeshift for JS/TS）
• 命令行：comby（跨语言语法匹配工具）比 sed 更安全

示例：将 getUserName() 改为 getDisplayName()，但跳过注释中的提及：

# comby 语法
getUserName(:[args]) → getDisplayName(:[args])

3. 分批次提交，保持可回滚

即使工具提示"100%安全"，也要按业务模块分批次重构：

1. 先修改核心模块，跑通测试后立即提交（commit）
2. 再处理工具类
3. 最后处理边界 case

关键原则：每次批量修改后必须能通过编译和基础单元测试，避免一次性提交 500+ 文件导致代码审查困难。

4. 自动化脚本兜底

对于机械性修改（如添加 @Deprecated 注解、统一 import 顺序），编写一次性脚本比 IDE 操作更可控：

# 示例：批量添加方法注解（Python + libcst）
import libcst as cst

class AddDecorator(cst.CSTTransformer):
    def leave_FunctionDef(self, original_node, updated_node):
        if original_node.name.value == "legacy_api":
            new_decorator = cst.Decorator(cst.Name("Deprecated"))
            return updated_node.with_changes(
                decorators=[new_decorator] + list(updated_node.decorators)
            )
        return updated_node

5. 必须配套自动化检查

批量重构后，立即运行：

• 静态检查：ESLint/Checkstyle/Pylint 确保没有语法错误
• 快照测试：如有 Snapshot 测试，批量更新预期值（jest --updateSnapshot）
• 回归测试：至少跑一遍核心流程的集成测试

常见陷阱提醒

• 编码格式陷阱：Windows/Linux 换行符混用可能导致 diff 混乱，重构前统一 .gitattributes
• 正则贪婪匹配：. 可能跨行匹配，使用 [\s\S]? 或限定范围
• 注释与字符串：确保工具能区分代码与注释，避免把示例代码里的函数名也改了

实战建议：超过 50 处修改时，先用脚本处理 3-5 个样本，人工 Review 确认模式正确后，再全量执行。记住：慢即是快，一次错误的批量替换可能花费数小时回滚。