# 代码复用思维指南

> **目的**：在创建新代码之前停下来思考 — 它已经存在吗？

---

## 问题

**重复代码是不一致 bug 的头号来源。**

当你复制粘贴或重写现有逻辑时：
- Bug 修复不会传播
- 行为会随着时间发散
- 代码库变得难以理解

---

## 在写新代码之前

### 步骤 1：先搜索

```bash
# 搜索类似的函数名
grep -r "functionName" .

# 搜索类似的逻辑
grep -r "keyword" .
```

### 步骤 2：问这些问题

| 问题 | 如果是... |
|----------|-----------|
| 是否存在类似的函数？ | 使用或扩展它 |
| 这个模式在其他地方使用吗？ | 遵循现有模式 |
| 这可以成为共享工具吗？ | 在正确的地方创建它 |
| 你正在从另一个文件复制代码吗？ | **停** — 提取到共享 |

---

## 常见的重复模式

### 模式 1：复制粘贴函数

**Bad**：将验证函数复制到另一个文件

**Good**：提取到共享工具，按需导入

### 模式 2：类似的组件

**Bad**：创建一个与现有组件有 80% 相似的新组件

**Good**：用 props/variants 扩展现有组件

### 模式 3：重复的常量

**Bad**：在多个文件中定义相同的常量

**Good**：单一数据源，到处导入

---

## 何时抽象

**抽象当**：
- 相同代码出现 3+ 次
- 逻辑复杂到可能有 bug
- 多人可能需要这个

**不要抽象当**：
- 只使用一次
- 简单的一行代码
- 抽象比重复更复杂

---

## 批量修改之后

当你在多个文件中做了类似的修改时：

1. **审查**：你找到了所有实例吗？
2. **搜索**：运行 grep 查找任何遗漏
3. **考虑**：这应该抽象吗？

---

## 注意：产生相同输出的不对称机制

**问题**：当两个不同的机制必须产生相同的文件集时（例如 init 的递归目录拷贝 vs update 的手动 `files.set()`），结构更改（重命名、移动、添加子目录）只通过自动机制传播。手动方式静默漂移。

**症状**：Init 完美工作，但 update 在错误路径创建文件或完全遗漏文件。

**预防清单**：
- [ ] 迁移目录结构时，搜索引用旧结构的所有代码路径
- [ ] 如果一个路径是自动派生（glob/copy）而另一个是手动列出，手动那个需要更新
- [ ] 添加一个回归测试，比较两种机制的输出

---

## 提交前的清单

- [ ] 搜索了现有类似代码
- [ ] 没有应该共享的复制粘贴逻辑
- [ ] 常量定义在一个地方
- [ ] 类似模式遵循相同结构
