TDD 重构工作流

重构时测试红了，还是不敢动代码？

TDD 的 Refactor 阶段最容易踩坑：功能已经由测试锁住，但结构债、重复逻辑和「顺手改行为」往往让套件在几轮改动后变红，回滚成本也高。本技能面向「在保持全部测试绿色的前提下改结构」这一具体约束，把重构前评估、增量步骤和失败恢复协议串成可执行流程，而不是泛泛的设计原则清单。

技能如何工作

用法上通过 Task 工具指定 subagent_type="tdd-orchestrator""，由编排智能体在测试网保护下做复杂重构。核心流程包括：

• 重构前评估：跑测试建立绿色基线，分析坏味道与覆盖率，必要时记录性能指标，再制定增量计划。
• 改动维度：从重复代码、过长方法/类、参数列表到 Feature Envy、Primitive Obsession、switch 泛滥等，对应抽取、移动、值对象、多态等手法；设计模式与 SOLID 仅在能明确降复杂度时采用。
• 验证节奏：小步原子修改，每步后跑测试；重构与行为变更分离；性能改动需前后测量；提交前对照安全检查清单（全绿、无回归、覆盖率不降等）。

更细的示例与 playbook 见资料中的 resources/implementation-playbook.md。

适用边界

• 适用：任务明确属于 TDD 工作流中的重构环节，需要检查清单、最佳实践或可验证步骤时。
• 不适用：与 TDD 重构无关的需求，或需要本技能范围外的其他领域/工具时；不要指望它替代你们项目里缺失的测试或 CI 基线——没有绿色套件，「安全重构」无从谈起。