用途
重构专家（Refactoring Specialist）用于系统性地改善代码质量与结构，同时不改变其外部行为。它专注于应用设计模式、贯彻 SOLID 原则，并通过增量式重构策略来管理技术债务。
何时使用
在以下情况调用该技能：
- 改善代码可读性与可维护性
- 减少代码重复与复杂度
- 应用设计模式解决结构性问题
- 拆分臃肿的类或函数
- 引入恰当的抽象层
- 为新增功能开发做准备
- 将遗留代码迁移到现代模式
- 在系统之间建立防腐层
在以下情况不要调用：
- 添加新功能（应先重构，再添加）→ 使用相应的领域技能
- 调试运行时错误 → 使用调试器
- 审查代码安全问题 → 使用 security-auditor
- 优化性能瓶颈 → 使用 performance-engineer
决策框架
检测到代码坏味道时：
- 重复 → 提取方法/类、模板方法模式
- 长方法 → 提取方法、分解条件式
- 大类 → 提取类、单一职责
- 依恋情结 → 将方法移动到合适的类
- 基本类型偏执 → 引入值对象
- 霰弹式修改 → 将相关变更集中在一起
- 发散式变化 → 按职责拆分
核心工作流
1. 安全重构循环
- 确保存在全面的测试覆盖
- 识别要处理的具体代码坏味道
- 应用尽可能小的重构步骤
- 运行测试以验证行为未变
- 提交变更
- 重复直到坏味道消除
2. 模式引入
- 识别反复出现的结构性问题
- 选择合适的设计模式
- 在现有代码旁创建新结构
- 逐步迁移调用方
- 移除旧实现
- 为团队记录模式用法
3. 防腐层实现
- 识别系统/领域之间的边界
- 为内部领域定义干净的接口
- 创建适配器/转换层
- 将所有跨边界调用路由到防腐层
- 独立演进内部模型
最佳实践
- 始终以测试作为安全网进行重构
- 进行小的增量变更并频繁提交
- 在添加新功能之前重构，而不是在添加过程中
- 使用 IDE 重构工具进行机械式转换
- 记录应用模式的原因，而不仅仅是应用了什么
- 按业务价值与风险对重构进行优先级排序
反模式
- 大爆炸式重构 → 使用增量式绞杀者模式
- 无测试重构 → 先添加特征测试
- 过度工程 → 仅在需要时应用模式
- 在功能开发期间重构 → 将重构提交分离
- 忽视团队约定 → 与现有代码库风格保持一致
限制
该技能不用于添加新功能、调试运行时错误、安全审查或性能优化，这些场景应使用对应的专门技能。资料未提供关于收费、价格、平台支持范围或具体效果保证的信息。