code-simplify

代码简化

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：发现拉取请求中的代码质量问题；本技能在用户授权后负责实施代码级简化。