Refactoring planner
agent-skills
npx -y skills add bingooyong/agent-skills --skill refactoring-plannerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Analyze code smells, generate refactoring plans with impact assessment and risk evaluation. Use when (1) identifying code smells and technical debt hotspots, (2) planning safe refactoring sequences with dependency awareness, (3) estimating refactoring scope and risk, (4) creating step-by-step refactoring checklists. Outputs prioritized refactoring plans with rollback strategies.
SKILL.md
5.8 KB, as published. Nobody here has run it
重构计划 Skill
分析代码坏味道和技术债，生成按优先级排序的重构计划，评估影响范围和风险，确保重构安全可回退。
何时使用
- 发现代码重复、过长函数、过深嵌套等坏味道，需要系统化处理
- 需要规划技术债偿还顺序
- 准备大规模重构前，需要评估影响和风险
- 生成重构 checklist 供团队执行
不适用：实时性能优化、从零开始的架构设计、纯 cosmetic 的代码格式化。
代码坏味道分类
| 坏味道 | 严重性指标 | 典型表现 | 推荐重构手法 |
|---|---|---|---|
| 重复代码 | 同一代码块出现 2+ 次 | 复制粘贴的逻辑、相似的 if-else 分支 | Extract Method / Extract Class / 模板方法 |
| 过长函数 | 函数超过 50 行 | 做太多事的函数、难以理解的逻辑块 | Extract Method / Replace Temp with Query |
| 过大类 | 类超过 300 行或方法超过 15 个 | 承担多个职责的"上帝类" | Extract Class / Move Method |
| 过深嵌套 | 嵌套层级超过 3 | if-for-if-for 套娃、箭头型代码 | Guard Clauses / Extract Method / 早返回 |
| 发散变化 | 一个类因 N 种不同原因修改 | 修改时总需要改同一个文件 | Extract Class / 按职责拆分 |
| 霰弹修改 | 一个变更需要修改 N 个文件 | 新功能需要改 5+ 个文件 | Move Method / 合并相关逻辑 |
| 特性嫉妒 | 频繁访问其他类的数据 | 大量 getter 调用链 | Move Method / Extract Method |
| 过度耦合 | 模块间依赖超过 3 层 | 改一个模块影响一串模块 | 引入接口 / Dependency Injection |
输入
| 输入类型 | 说明 | 必需 |
|---|---|---|
| 目标代码路径或范围 | 要分析的文件/目录/模块 | 是 |
| 已知问题清单 | 团队已知的痛点 | 否 |
| 重构目标 | 可维护性 / 性能 / 可测试性 | 否（默认可维护性） |
| 约束条件 | 不可修改的接口、冻结的模块等 | 否 |
输出
- 坏味道分析报告（按严重性排序）
- 重构计划（P0/P1/P2 分级）
- 影响范围评估
- 每步的验证条件
- 回退策略
执行步骤
1. 识别代码坏味道
FOR each 目标文件/模块:
IF 函数超过 50 行 → 标记"过长函数", 严重性: 中
IF 类超过 300 行 OR 方法超过 15 个 → 标记"过大类", 严重性: 中
IF 嵌套层级超过 3 → 标记"过深嵌套", 严重性: 高
IF 重复代码块超过 6 行 AND 出现 2+ 次 → 标记"重复代码", 严重性: 高
IF 文件修改原因超过 3 种（从 git history 推断）→ 标记"发散变化", 严重性: 中
IF 函数频繁访问其他类的属性 → 标记"特性嫉妒", 严重性: 中
IF 模块间依赖超过 3 层 → 标记"过度耦合", 严重性: 高
2. 评估影响范围
对每个识别到的坏味道：
- 统计受影响的文件数和函数数
- 识别依赖此代码的上游调用方
- 识别此代码依赖的下游模块
- 评估修复所需的最小变更范围
影响评估:
受影响文件数: N
受影响函数数: M
上游调用方: [列表]
最小变更范围: [文件列表]
3. 确定重构优先级
优先级排序:
P0 (高收益低风险):
- 严重性高 AND 影响范围小（< 3 文件）
- 重复代码提取
- 过深嵌套改为 guard clause
P1 (高收益中风险):
- 严重性高 AND 影响范围中等（3-10 文件）
- 过大类拆分
- 发散变化重构
P2 (中等收益):
- 严重性中 AND 影响范围可控
- 过长函数提取
- 特性嫉妒修复
建议延后:
- 影响范围超过 10 文件
- 涉及跨团队接口
- 当前无测试覆盖的区域
4. 制定重构计划
## 重构计划
### P0 — 高收益低风险
1. **提取重复的参数校验逻辑**
- 目标文件: src/utils/validate.ts
- 影响范围: 2 个文件
- 重构手法: Extract Method
- 验证条件: 现有测试全部通过
- 预估时间: 30 分钟
### P1 — 高收益中风险
2. **拆分 UserService 的权限逻辑**
- 目标文件: src/services/UserService.ts
- 影响范围: 5 个文件
- 重构手法: Extract Class
- 验证条件: 现有测试通过 + 新增权限测试用例
- 预估时间: 2 小时
5. 设计回退策略
回退策略:
1. 每步重构前确保 Git 工作区干净
2. 每步完成后运行完整测试套件
3. 测试失败时: git revert 到上一步的提交
4. 大范围重构: 先创建 feature branch，完成后合并
5. 重构过程中不混合功能变更
边界与非目标
- 不做实际代码修改 — 只生成重构计划，修改由用户执行
- 不做代码 review — 这是 code-review-checklist 的职责
- 不做API 设计审查 — 这是 api-design-reviewer 的职责
- 不做测试策略设计 — 这是 test-strategy-designer 的职责
- 不做依赖分析 — 这是 dependency-analyzer 的职责
- 不做错误模式管理 — 这是 error-pattern-library 的职责
- 只规划重构，不涉及新功能设计
验收标准
- 每个识别的坏味道都有严重性评估和影响范围
- 重构计划按 P0/P1/P2 分级，P0 可以立即执行
- 每步重构有明确的验证条件（通常是测试通过）
- 回退策略具体可执行，不是笼统的"回退"
- 没有将高风险大范围重构标记为 P0