Cs Refactor

# 重构方法库

scan 阶段匹配候选优化点的方法表，design 阶段每个执行步骤要引用一个方法号。

**方法号 `M-L{层}-{序号}`**。四层：

- **L1 行为等价迁移**——大改动有风险时把"改"拆成多步安全动作
- **L2 代码级重构**——Fowler 经典单次动作，单函数 / 局部改写
- **L3 结构拆分**——组件 / 模块 / 层级级别
- **L4 性能与异步**——行为等价但运行特征变（算复杂度 / 渲染次数 / IO 次数）

**统一字段**：适用 / 不适用 / 步骤 / 风险点 / 验证 / 前后端 / 配哪种 scan 项。前后端适用性大部分通用，特化的会在字段里标注。

---

## L1 行为等价迁移

### M-L1-01 Parallel Change 并行变更

- **适用**：要替换一个被多处调用的函数/接口/数据结构，直接改会波及太多地方
- **不适用**：只在一处用的内部函数（直接改就行）
- **步骤**：
  1. 新建 `newThing`，行为和 `oldThing` 完全一致（必要时做适配层）
  2. 调用方一个一个切到 `newThing`，每切一个跑一次测试
  3. 确认 `oldThing` 全局无引用（grep 可证）后删除
- **风险点**：步骤 2 期间如果有新代码被加进来继续调 `oldThing`，切换会漏。对 `oldThing` 加 deprecated 标注或 lint 规则防回流
- **验证**：每步跑测试 + 切换完 grep `oldThing` 全局 0 引用
- **前后端**：通用
- **配哪种 scan 项**：某函数 / 接口被 N 处调用，要改签名或实现

### M-L1-02 Strangler Fig 绞杀者模式

- **适用**：替换一整块老模块（甚至一整个子系统），老的不能立刻删、要长期共存
- **不适用**：单函数或小范围改动（用 Parallel Change 就够）
- **步骤**：
  1. 在老模块外围加一层路由/代理，默认仍走老实现
  2. 新实现逐个功能点接入，通过路由分流（新功能点走新实现，老功能点仍走老实现）
  3. 老功能点一个一个迁过来，每迁一个跑全量回归
  4. 全部迁完，删老模块和路由层
- **风险点**：路由层成为永久依赖；新老实现中间状态不一致（如共享数据库时 schema 冲突）
- **验证**：每次迁移后跑全量回归；监控老模块调用次数，应逐步归零
- **前后端**：通用，后端尤其常见
- **配哪种 scan 项**："这块老逻辑要整体替换"，不能一次性切

### M-L1-03 Branch by Abstraction 分支抽象

- **适用**：要替换一个被广泛使用的底层库 / 框架 / 核心数据结构
- **不适用**：改动只影响局部
- **步骤**：
  1. 在调用点和老实现之间插入一层抽象接口，调用点改为依赖接口
  2. 接口的默认实现仍指向老实现，跑测试验证行为不变
  3. 在接口下实现新版本，通过 feature flag 或配置切换
  4. 观察一段时间无问题，删除老实现和抽象层
- **风险点**：抽象层设计不好会泄漏老实现细节到接口；feature flag 忘记清理
- **验证**：每步跑测试；切换期间对比新老实现的输出
- **前后端**：通用
- **配哪种 scan 项**：要换底层依赖（如换 HTTP 客户端、换 ORM、换状态管理库）

### M-L1-04 Characterization Test 刻画测试

- **适用**：老代码没测试、行为不完全清楚，但马上要改——refactor 前置必做
- **不适用**：代码逻辑极简（< 10 行、无分支）、或已有充分测试
- **步骤**：
  1. 对目标函数喂一批真实输入（可从生产日志采样）
  2. 记录当前输出作为测试断言——不评价这个行为是否"正确"，只固化现状
  3. 跑测试确认通过，提交
  4. 之后的重构每步都跑这组测试，任何一条失败都是行为偏离
- **风险点**：固化的"现状"可能包含已知 bug——如果是故意要修 bug，走 issue 不走 refactor
- **验证**：重构后测试全通过 = 行为等价
- **前后端**：通用
- **配哪种 scan 项**：前置检查第 2 条命中时，用本方法补测试

---

## L2 代码级重构（Fowler 经典）

### M-L2-01 Extract Function 提取函数

- **适用**：函数内部有一段内聚逻辑可以命名（> 5 行、职责独立）
- **不适用**：短、命名困难、和外层逻辑强耦合的片段
- **步骤**：
  1. 识别要提取的片段，起一个说清"做什么"的名字
  2. 把用到的外部变量作为参数，把返回给外层的值作为返回值
  3. 替换原片段为函数调用
  4. 跑测试
- **风险点**：参数过多（> 4 个）说明耦合太深，可能要先做 M-L2-07 引入参数对象；副作用跨边界（读写 this / 全局）会让"函数"变成伪装的过程
- **验证**：跑单元测试
- **前后端**：通用
- **配哪种 scan 项**：函数过长 / 圈复杂度高 / 内部有可命名的段落

### M-L2-02 Inline Function 内联函数

- **适用**：函数体比名字更清楚 / 函数已经只剩包装作用 / 函数被调用次数极少
- **不适用**：函数被广泛使用
- **步骤**：
  1. 找出所有调用点
  2. 每个调用点用函数体替换
  3. 删函数定义
  4. 跑测试
- **风险点**：调用点很多时内联出一堆重复代码；递归函数不能内联
- **验证**：跑单元测试；grep 原函数名 0 引用
- **前后端**：通用
- **配哪种 scan 项**：空壳包装函数 / 抽象做过头的层

### M-L2-03 Extract Variable / Replace Temp with Query 提取变量 / 以查询取代临时变量

- **适用**：复杂表达式难以理解（长三元、多重计算）；同一计算在多处用到
- **不适用**：表达式已经清楚
- **步骤**：
  1. 把复杂表达式提取到命名变量
  2. 如果该计算在多处复用，进一步提取为纯函数（query）
  3. 跑测试
- **风险点**：过度提取反而让变量满天飞；提取为 query 时要保证无副作用
- **验证**：跑单元测试
- **前后端**：通用
- **配哪种 scan 项**：难懂的长表达式 / 重复计算

### M-L2-04 Move Function 搬移函数

- **适用**：函数更多使用另一个类/模块的数据；或函数和当前模块的主题不符
- **不适用**：当前位置仍是最自然的位置
- **步骤**：
  1. 确认函数在新位置的所有依赖都可达
  2. 在新位置创建函数，原位置改为转发调用（过渡期）或直接替换所有调用点
  3. 迁移所有调用点后删原函数
  4. 跑测试
- **风险点**：函数依赖原位置的私有状态时不能直接搬
- **验证**：跑测试；grep 原位置 0 引用
- **前后端**：通用
- **配哪种 scan 项**：函数位置错配 / 模块职责模糊

### M-L2-05 Decompose Conditional 分解条件

- **适用**：if / else 分支内部逻辑长，判断条件本身也复杂
- **不适用**：分支短且清楚
- **步骤**：
  1. 把判断条件提取为命名函数（如 `isEligibleForDiscount(user)`）
  2. 把各分支体提取为命名函数
  3. 主体只剩 `if (isX()) doA() else doB()` 的骨架
  4. 跑测试
- **风险点**：过度分解让调用链变深
- **验证**：跑单元测试
- **前后端**：通用
- **配哪种 scan 项**：嵌套 if-else / 复杂条件判断

### M-L2-06 Replace Conditional with Polymorphism 以多态取代条件

- **适用**：同一个 type / status 字段在多处触发相似的 switch/if-else 分发
- **不适用**：只在一处分发 / 类型数量不稳定
- **步骤**：
  1. 为每个类型建立子类或策略对象，把原分支逻辑放入对应实现
  2. 调用点改为调用多态方法
  3. 删除原 switch/if-else
  4. 跑测试
- **风险点**：类型爆炸；前端里过度 OO 反而不如 map 查表清晰
- **验证**：跑单元测试
- **前后端**：通用
- **配哪种 scan 项**：同一 type 字段在 3+ 处触发 switch

### M-L2-07 Introduce Parameter Object 引入参数对象

- **适用**：函数参数 > 4 个，或多处函数共享同一组参数
- **不适用**：参数少且无关
- **步骤**：
  1. 把相关参数聚成一个对象 / 结构体
  2. 函数签名改为接收该对象
  3. 所有调用点构造对象传入
  4. 跑测试
- **风险点**：对象字段和函数实