---
name: code-simplify
description: 简化函数、类、文件内部及局部协作代码，降低真实维护成本。当用户明确要求重构、简化、清理代码、处理代码质量评审意见，或对指定目录或模块做坏味道普查时使用。
---

# 代码简化

`code-simplify` 处理不改变外部可观察行为的代码级简化。目标是让相关代码更容易理解、修改和排查，而不是减少行数或套用某种重构手法。

## 边界

- 函数、类、文件内部，以及它们之间的局部职责搬移属于本技能。
- 模块边界、分层、依赖方向或领域职责需要变化时，转到 `arch-design`。
- 已知或怀疑存在缺陷时，先由 `systematic-debugging` 建立问题验证路径；缺陷修复不是代码简化。
- 改动需要改变用户可观察行为、公共接口或数据契约时，退出本技能并进入相应的需求澄清流程。
- 代码已经清楚，或目标区域即将被替换时，不为形式完整而重构。

## 授权边界

用户明确要求简化、重构或执行目录普查时，可以在指定范围内推进。

如果只是在其他任务中偶然发现坏味道，先报告具体位置、维护成本、建议方向和预计影响范围，取得用户确认后再修改。不要把顺手清理混入用户没有授权的改动。

## 核心约束

1. **保持外部行为。** 输入、输出、副作用、错误语义和边界情况应保持不变。行为契约测试原则上不因重构而改变；绑定内部结构的测试可以随实现调整，但必须说明外部契约为何仍被保护。
2. **从真实代码和项目规则出发。** 阅读调用方、依赖、错误路径、相关测试和邻近实现。只有当代码意图或历史约束仍不清楚时，才使用 `git blame`、`git log` 或提交记录补充上下文。
3. **处理具体维护成本。** 给问题准确命名，并说明它如何增加理解、修改、排查或回归风险。不要按个人风格偏好制造清理任务。
4. **做最小连贯改动。** 一次完成一个可独立理解和回退的结构改进；按风险选择验证节点，始终保持代码处于可构建、可测试的状态。
5. **清晰优先。** 更短不等于更简单。只有当改后版本在当前代码库语境下更容易理解和维护时，改动才成立。

## 流程

### 1. 框定问题

- 明确目标文件、类型或目录，以及不在本次处理范围内的内容。
- 阅读实际代码、调用点、相关测试和项目指令。
- 写清具体问题及其维护成本。可参考改动频率、缺陷历史、依赖范围和理解难度，但不要把固定行数或嵌套层数当作结论。
- 若问题实际属于缺陷、行为变更或架构边界调整，按前述边界退出。

### 2. 确认行为保护

- 找到能够保护相关外部行为的现有测试或其他有效验证路径。
- 保护网不足且存在有效自动化接缝时，先交给 `test-driven-development` 补充特征测试。
- 无法建立足够保护时，缩小改动范围；剩余风险不清楚则停止并报告，不用猜测证明安全。

### 3. 选择简化方向

- 选择能直接消除已命名问题的最小结构变化。
- 需要回忆坏味道名称或可用重构手法时，读取 `references/smells-and-refactorings.md`。它是提醒列表，不是必须逐项执行的检查表。
- 若处理过程中暴露出新的、超出授权范围的问题，记录并交回用户，不继续扩张。

### 4. 修改与验证

- 以最小连贯步骤修改代码，在与风险匹配的节点运行相关测试、构建、类型检查或静态检查。
- 出现行为差异时，先判断是实现错误还是测试绑定了内部结构；不能证明外部契约保持不变就回退该变化。
- 最后检查完整差异：没有无关改动，错误处理和边界行为没有被削弱，改后的职责与命名比原来更清楚。

如果验证通过，但改后版本没有降低已命名的维护成本，就撤销这次简化；“代码不同了”不是完成证据。

## 目录或模块普查

普查只在用户明确要求或确认后执行：

1. 划定目录或模块范围，逐文件识别具体维护性问题。
2. 按维护成本与改动风险排序，记录位置、证据、建议方向和影响范围。
3. 先把清单交给用户选择，不直接批量修改。
4. 对用户选中的项目分别执行本技能流程。

## 与其他技能的关系

- `arch-design`：处理模块边界、依赖方向、分层与领域职责。
- `systematic-debugging`：处理错误、异常行为和性能退化的根因定位与修复。
- `test-driven-development`：在结构改动前补足行为保护网。
- `deep-review`：发现拉取请求中的代码质量问题；本技能在用户授权后负责实施代码级简化。