qa-refactoring by vasilyu1983/ai-agents-public
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill qa-refactoring使用此技能进行安全重构:在提升可维护性和交付速度的同时,保持行为不变、降低风险并确保 CI 通过。
默认原则:首先建立基线,然后采取最小安全步骤,并通过测试/契约/可观测性而非直觉来证明。
main 分支状态正常(CI 通过);重现你必须保持的行为。main 分支状态正常(CI 通过);重现你必须保持的行为。| 风险级别 | 示例 | 最低要求的安全网 |
|---|---|---|
| 低 | 重命名、提取方法、仅格式化 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 单元测试 + 代码检查/类型检查 |
| 中 | 跨模块移动逻辑、依赖反转 | 单元测试 + 边界处的集成/契约测试 |
| 高 | 认证/权限路径、并发、数据迁移、涉及资金/数据丢失的路径 | 集成 + 契约测试、可观测性检查、金丝雀发布 + 回滚计划 |
git bisect 可用:除非必要,避免混合“机械性 + 语义性”更改。应做:
应避免:
| 任务 | 工具/模式 | 命令/方法 | 使用时机 |
|---|---|---|---|
| 过长方法(>50 行) | 提取方法 | 拆分为更小的函数 | 单个方法承担过多职责 |
| 过大类(>300 行) | 拆分类 | 创建职责单一、专注的类 | 上帝对象承担过多职责 |
| 重复代码 | 提取函数/类 | DRY 原则 | 相同逻辑出现在多个地方 |
| 复杂条件判断 | 以多态取代条件表达式 | 使用继承/策略模式 | 基于类型的 switch 语句 |
| 过长参数列表 | 引入参数对象 | 创建 DTO/配置对象 | 函数参数超过 3 个 |
| 遗留代码现代化 | 特性测试 + 绞杀者模式 | 先写测试,再增量迁移 | 无测试的旧代码库 |
| 自动化质量门禁 | ESLint, SonarQube, Prettier | npm run lint, CI/CD 流水线 | 防止质量回退 |
| 技术债务追踪 | SonarQube, CodeClimate | 跟踪趋势 + 热点 | 确定重构工作优先级 |
代码问题:[重构场景]
├─ 检测到代码异味?
│ ├─ 重复代码? → 提取方法/函数
│ ├─ 过长方法(>50 行)? → 提取为更小的方法
│ ├─ 过大类(>300 行)? → 拆分为专注的类
│ ├─ 过长参数列表? → 参数对象
│ └─ 特性依恋? → 将方法移至靠近数据的地方
│
├─ 遗留代码(无测试)?
│ ├─ 高风险? → 先编写特性测试
│ ├─ 需要大规模重写? → 绞杀者模式(增量迁移)
│ ├─ 行为未知? → 特性测试 + 小规模重构
│ └─ 生产系统? → 金丝雀部署 + 监控
│
├─ 质量标准?
│ ├─ 新项目? → 设置代码检查器 + 格式化器 + 质量门禁
│ ├─ 现有项目? → 添加预提交钩子 + CI 检查
│ ├─ 复杂度问题? → 设置圈复杂度限制(<10)
│ └─ 技术债务? → 在登记表中跟踪,分配 20% 迭代容量
../qa-debugging/SKILL.md../data-sql-optimization/SKILL.md../software-architecture-design/SKILL.mdCC-*)RULE-01–RULE-13、决策树和操作流程有关详细的重构目录、自动化质量门禁、技术债务操作手册和遗留代码现代化步骤,请参阅 references/operational-patterns.md。
使用 assets/ 目录下的复制粘贴模板来获取清单和质量门禁配置:
使用 references/ 目录下的深度指南(按需加载):
应做:
应避免:
有关精选的外部参考资料,请参阅 data/sources.json。
每周安装次数
75
代码仓库
GitHub 星标数
53
首次出现
2026年1月23日
安全审计
安装于
cursor60
opencode59
gemini-cli58
codex58
github-copilot55
claude-code51
Use this skill to refactor safely: preserve behavior, reduce risk, and keep CI green while improving maintainability and delivery speed.
Defaults: baseline first, smallest safe step next, and proof via tests/contracts/observability instead of intuition.
main green; reproduce the behavior you must preserve.main green; reproduce the behavior you must preserve.| Risk | Examples | Minimum required safety net |
|---|---|---|
| Low | rename, extract method, formatting-only | unit tests + lint/type checks |
| Medium | moving logic across modules, dependency inversion | unit + integration/contract tests at boundary |
| High | auth/permission paths, concurrency, migrations, money/data-loss paths | integration + contract tests, observability checks, canary + rollback plan |
git bisect viable: avoid mixed "mechanical + semantic" changes unless necessary.Do:
Avoid:
| Task | Tool/Pattern | Command/Approach | When to Use |
|---|---|---|---|
| Long method (>50 lines) | Extract Method | Split into smaller functions | Single method does too much |
| Large class (>300 lines) | Split Class | Create focused single-responsibility classes | God object doing too much |
| Duplicated code | Extract Function/Class | DRY principle | Same logic in multiple places |
| Complex conditionals | Replace Conditional with Polymorphism | Use inheritance/strategy pattern | Switch statements on type |
| Long parameter list | Introduce Parameter Object | Create DTO/config object | Functions with >3 parameters |
| Legacy code modernization | Characterization Tests + Strangler Fig | Write tests first, migrate incrementally | No tests, old codebase |
Code issue: [Refactoring Scenario]
├─ Code Smells Detected?
│ ├─ Duplicated code? → Extract method/function
│ ├─ Long method (>50 lines)? → Extract smaller methods
│ ├─ Large class (>300 lines)? → Split into focused classes
│ ├─ Long parameter list? → Parameter object
│ └─ Feature envy? → Move method closer to data
│
├─ Legacy Code (No Tests)?
│ ├─ High risk? → Write characterization tests first
│ ├─ Large rewrite needed? → Strangler Fig (incremental migration)
│ ├─ Unknown behavior? → Characterization tests + small refactors
│ └─ Production system? → Canary deployments + monitoring
│
├─ Quality Standards?
│ ├─ New project? → Setup linter + formatter + quality gates
│ ├─ Existing project? → Add pre-commit hooks + CI checks
│ ├─ Complexity issues? → Set cyclomatic complexity limits (<10)
│ └─ Technical debt? → Track in register, 20% sprint capacity
../qa-debugging/SKILL.md../data-sql-optimization/SKILL.md../software-architecture-design/SKILL.mdCC-*) for citationRULE-01–RULE-13, decision trees, and operational proceduresSee references/operational-patterns.md for detailed refactoring catalogs, automated quality gates, technical debt playbooks, and legacy modernization steps.
Use copy-paste templates in assets/ for checklists and quality-gate configs:
Use deep-dive guides in references/ (load only what you need):
Do:
Avoid:
See data/sources.json for curated external references.
Weekly Installs
75
Repository
GitHub Stars
53
First Seen
Jan 23, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
cursor60
opencode59
gemini-cli58
codex58
github-copilot55
claude-code51
后端测试指南:API端点、业务逻辑与数据库测试最佳实践
11,800 周安装
| Automated quality gates | ESLint, SonarQube, Prettier | npm run lint, CI/CD pipeline | Prevent quality regression |
| Technical debt tracking | SonarQube, CodeClimate | Track trends + hotspots | Prioritize refactoring work |