tdd-workflows-tdd-refactor

适用情形

• 处理 TDD 工作流、TDD 重构任务或工作流时
• 需要有关 TDD 工作流、TDD 重构的指导、最佳实践或检查清单时

不适用情形

• 任务与 TDD 工作流、TDD 重构无关时
• 需要使用此范围之外的其他领域知识或工具时

说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可执行的步骤和验证方法。
• 引用的实现手册和 tdd-orchestrator Agent 未随附。请使用可用的仓库工具；除非确实运行过，否则不要声称运行了某个具名 Agent 或模型。

借助全面的测试安全网，自信地重构代码：

只有当前指令授权时才委派，并使用选定的可用模型。测试套件通过并不能证明行为未变，尤其是在测试覆盖不完整时。

用法

使用 Task 工具，并设置 subagent_type="tdd-orchestrator"，以执行安全重构。

提示词：“重构此代码，同时确保所有测试通过：$ARGUMENTS。应用 TDD 重构阶段：

核心流程

1. 预评估

• 运行测试，建立通过的基准状态
• 分析代码异味和测试覆盖率
• 记录当前性能指标
• 制定渐进式重构计划

2. 检测代码异味

• 重复代码 → 提取方法／类
• 过长的方法 → 拆分为职责明确的函数
• 过大的类 → 拆分职责
• 参数列表过长 → 使用参数对象
• 特性嫉妒 → 将方法移至合适的类
• 基本类型偏执 → 使用值对象
• switch 语句 → 使用多态
• 死代码 → 删除

3. 设计模式

• 应用创建型模式（工厂、构建器、单例）
• 应用结构型模式（适配器、门面、装饰器）
• 应用行为型模式（策略、观察者、命令）
• 应用领域模式（仓储、服务、值对象）
• 仅在模式确实能带来明确价值时使用

4. SOLID 原则

• 单一职责：只有一个变更理由
• 开闭原则：对扩展开放，对修改关闭
• 里氏替换原则：子类型可相互替换
• 接口隔离原则：接口小而专注
• 依赖倒置原则：依赖抽象

5. 重构技术

• 提取方法／变量／接口
• 内联不必要的间接层
• 重命名以提高清晰度
• 将方法／字段移至合适的类
• 用常量替换魔法数字
• 封装字段
• 用多态替换条件语句
• 引入空对象

6. 性能优化

• 通过性能分析找出瓶颈
• 优化算法和数据结构
• 在有益时实现缓存
• 减少数据库查询（消除 N+1 问题）
• 延迟加载和分页
• 始终测量优化前后的指标

7. 渐进式步骤

• 进行小规模、原子性的更改
• 每次修改后运行测试
• 每次成功重构后提交
• 将重构与行为更改分开
• 需要时使用脚手架

8. 架构演进

• 分层和依赖管理
• 模块边界和接口定义
• 使用事件驱动模式实现解耦
• 优化数据库访问模式

9. 安全验证

• 每次更改后运行完整测试套件
• 进行性能回归测试
• 通过变异测试验证测试有效性
• 为重大更改制定回滚计划

10. 高级模式

• 绞杀榕模式：逐步替换遗留系统
• 抽象分支模式：用于大规模更改
• 并行更改：扩展—收缩模式
• 米卡多方法：沿依赖关系图逐步推进

输出要求

• 完成改进的重构代码
• 测试结果（全部通过）
• 前后指标对比
• 已应用的重构技术列表
• 性能改进测量结果
• 剩余技术债评估

安全检查清单

提交前：

• ✓ 所有测试通过（100% 通过）
• ✓ 无功能回归
• ✓ 性能指标符合要求
• ✓ 代码覆盖率保持不变或有所提高
• ✓ 文档已更新

恢复协议

如果测试失败：

• 检查失败原因；必要时仅撤销你最近一次独立的更改，并保留无关的用户修改
• 找出导致问题的重构
• 采用更小的增量更改
• 使用版本控制进行安全试验

示例：提取方法模式

之前：

class OrderProcessor {
  processOrder(order: Order): ProcessResult {
    // Validation
    if (!order.customerId || order.items.length === 0) {
      return { success: false, error: "Invalid order" };
    }

    // Calculate totals
    let subtotal = 0;
    for (const item of order.items) {
      subtotal += item.price * item.quantity;
    }
    let total = subtotal + (subtotal * 0.08) + (subtotal > 100 ? 0 : 15);

    // Process payment...
    // Update inventory...
    // Send confirmation...
  }
}

之后（仅示意编排方式的更改，并非保持行为不变的提取）：

此示例引入了异步支付、库存和通知依赖；不要将其标记为纯重构。采用前，请明确在失败情况下的幂等性、预留与扣款顺序以及补偿机制。

class OrderProcessor {
  async processOrder(order: Order): Promise<ProcessResult> {
    const validation = this.validateOrder(order);
    if (!validation.isValid) return ProcessResult.failure(validation.error);

    const orderTotal = OrderTotal.calculate(order);
    const inventoryCheck = await this.inventoryService.checkAvailability(order.items);
    if (!inventoryCheck.available) return ProcessResult.failure(inventoryCheck.reason);

    await this.paymentService.processPayment(order.paymentMethod, orderTotal.total);
    await this.inventoryService.reserveItems(order.items);
    await this.notificationService.sendOrderConfirmation(order, orderTotal);

    return ProcessResult.success(order.id, orderTotal.total);
  }

  private validateOrder(order: Order): ValidationResult {
    if (!order.customerId) return ValidationResult.invalid("Customer ID required");
    if (order.items.length === 0) return ValidationResult.invalid("Order must contain items");
    return ValidationResult.valid();
  }
}

已应用： 提取方法、值对象、依赖注入、异步模式

要重构的代码：$ARGUMENTS"

限制

• 仅在任务明确符合上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。