code-refactor

Files (5)

• SKILL.md
• analysis-report.md · templates/
• case-studies.md · templates/
• evaluation.md · templates/
• strategy-pattern.md · templates/

SKILL.md (first lines)

# 代码重构方法论

从软件设计本质层面提炼可复用的重构方法论，指导代码质量改进。

## 适用场景

- 代码出现明确坏味道，需要改善结构
- 技术债累积影响迭代效率
- 重构前需要评估风险与收益

## 前置条件

1. 已有可执行的测试或可复现的验证手段；没有测试时先补测试再重构。
2. 明确本次重构的目标与边界，不与其他需求混做。
3. 通过 skill `code-review` 或 `code-detect-problem` 获得问题清单。

## 执行步骤

1. 识别退化信号，确认根因属于类型、数据、行为还是关系退化。
2. 按三问分析法确定目标设计。
3. 选择重构策略，评估影响范围与回滚方式。
4. 小步实施，每一步保持可编译、可测试。
5. 用测试与指标验证效果，记录前后对比。
6. 分步提交，每次提交只包含一个可回退的改动。

## 一、设计哲学与原理

### 1.1 代码退化根源

**退化机制**：复制粘贴→知识分裂，快速修复→破坏设计意图，需求变更→补丁叠加，知识遗忘→意图模糊

**退化规律**：所有代码都会退化，重构是必然的维护行为

### 1.2 类型系统本质

```text
类型 = 值集合 + 操作集合 + 不变量
```

**类型退化链条**：强类型→弱类型，枚举→字符串常量→魔法字符串→硬编码，编译检查→运行时判断→运行时错误

**退化信号**：值被用来判断行为、编译期错误变成运行时错误、枚举退化成字符串常量

### 1.3 多态本质

```text
多态 = 同一接口 + 不同行为
```

| 分发方式    | 时机   | 安全性       |
| ----------- | ------ | ------------ |
| if-else     | 运行时 | 低（易遗漏） |
| switch      | 运行时 | 中           |
| 虚方法      | 运行时 | 高           |
| 模板/泛型   | 编译期 | 最高         |

**本质**：用类型系统分发行为，而非运行时判断

### 1.4 数据结构本质

```text
数据结构 = 数据组织方式 + 访问操作 + 复杂度保证
```

| 访问模式 | 推荐        | 不推荐     | 原因         |
| -------- | ----------- | ---------- | -------------|
| 顺序遍历 | List/Array  | Map        | 简单高效     |
| Key查找  | Map/HashMap | List       | O(1) vs O(n) |
| 范围查询 | TreeMap     | HashMap    | 有序性       |
| 去重     | Set         | List       | 自动去重     |

## 二、方法论体系

### 2.1 问题识别

```text
代码异味 → 症状(What) → 根因(Why) → 设计退化(本质)
```

| 退化类型 | 信号       | 根因         |
| -------- | ---------- | ------------ |
| 类型退化 | 值判断行为 | 类型信息丢失 |
| 数据退化 | 嵌套查找   | 结构不匹配   |
| 行为退化 | 重复代码   | 缺少抽象     |
| 关系退化 | 紧耦合     | 依赖方向错误 |

### 2.2 三问分析法

- Q1: 为什么出现？→ 根因
- Q2: 本质是什么？→ 抽象
- Q3: 正确设计应该是什么？→ 目标

### 2.3 决策框架

| 问题本质 | 推荐方案        | 收益             |
| -------- | --------------- | ---------------- |
| 类型退化 | 多态/策略模式   | 类型安全、易扩展 |
| 数据退化 | 重建索引/换容器 | 性能提升         |
| 行为退化 | 提取抽象        | 减少重复         |
| 关系退化 | 解耦/依赖注入   | 降低耦合         |

**决策原则**：优先解决根本原因；选择收益/成本比最高方案；小步快跑，持续验证

### 2.4 执行框架

```text
识别 → 分析 → 方案 → 小步 → 验证 → 提交
```

**小步原则**：每次只改一个问题，每次改完可编译，每次提交可回退

### 2.5 验证框架

| 维度       | 指标               | 方法               |
| ---------- | ------------------ | ------------------ |
| 性能       | 时间/空间复杂度    | 算法分析、基准测试 |
| 质量       | 圈复杂度、重复率   | 静态分析工具       |
| 可维护性   | 扩展性、可读性     | 代码审查           |

From hellyguo/self-ai-spec, Apache-2.0.

More from hellyguo/self-ai-spec