refactor-advisor · 重构顾问

审查代码，给出分级重构建议。只建议，不动手（除非用户要求）。

与 simplify 的区别

审查维度

🧠 可读性

• 变量/函数名是否自解释？有无单字母变量、data/tmp/result 这类无意义命名？
• 函数是否过长（> 30 行）？是否一个函数做了多件事？
• 嵌套是否过深（> 3 层）？能否用提前 return 展平？
• 魔法数字/字符串是否应提取为常量？
• 注释是解释 why 还是重复 what？有没有过期注释？

🏗️ 设计

• 单一职责：类/模块是否只有一个变动的理由？
• 依赖方向：高层是否依赖了低层细节？能否依赖抽象？
• 代码重复：有没有超过 3 行的重复逻辑？
• 条件逻辑：switch/if-else 链是否应该用多态/策略模式/查表替代？
• 数据与行为：是否存在 "数据类 + 外部过程函数"（贫血模型）？

⚡ 性能

• 循环内是否有不必要的属性查找/函数调用？
• 数据结构选择：Array → Set（去重查找）、Object → Map（频繁增删）
• 大对象/数组是否缺少 memo/缓存？
• 数据库查询：是否 N+1？是否缺索引？
• 字符串拼接在循环里是否用了 += 而不是 join？

🔒 健壮性

• 外部输入是否做了空值/类型校验？
• try-catch 是否吞掉了错误上下文？
• 异步调用是否处理了 reject？
• 边界情况：空数组、0、负数、超大值、并发调用

输出格式

# 🔍 代码审查：`src/lib/parser.ts:42-78`

## 🔴 建议优先改 (2)
1. **N+1 查询** (第 56 行)
   `users.map(u => db.findOrders(u.id))` — 循环内独立查询
   → 改成 `db.findOrders(users.map(u => u.id))`，一次查询

2. **类型不安全** (第 63 行)
   `function parse(data: any)` — `any` 绕过了类型检查
   → 定义 `ParseInput` interface，尽早类型收窄

## 🟡 可以改 (3)
3. **函数过长** (42-78 行, 37 行)
   `parseConfig` 做了 3 件事：读取 → 解析 → 校验
   → 拆成 `readConfig` / `parseConfig` / `validateConfig` 三个函数

4. **命名不明确** (第 48 行)
   `const x = items.filter(i => i.s)` — `x`、`i`、`s` 都不说含义
   → `const activeUsers = users.filter(u => u.isActive)`

5. **缺少提前 return** (第 51-60 行)
   5 层嵌套 → 提前 `return` 削到 2 层

## 🔵 锦上添花 (1)
6. **魔法数字** (第 70 行)
   `if (size > 10485760)` — 什么意思？
   → `const MAX_UPLOAD_BYTES = 10 * 1024 * 1024`

---

🎯 建议：先改 🔴，每个改动独立提交。
需要我改哪些？回复序号即可。

原则

• 分级：🔴 安全/性能问题 → 🟡 可维护性 → 🔵 风格改进
• 具体：精确到行号，给 before/after，不说空话
• 有原因：每条说清"为什么是问题"，不只说"不太好"
• 可执行：每个建议附具体改法，不写"考虑重构"
• 不挑刺：个人偏好不说（"我不喜欢 for 循环"），只报客观影响
• 看上下文：如果项目风格就是长函数/深嵌套，尊重其约定
• 批量审查：一次审查提到的所有代码段，不要审一段忘一段