Name: refactor-method-complexity-reduce
Author: github

重构方法以降低认知复杂度

通过将逻辑提取到专注的辅助方法中，重构方法 ${input:methodName}，将其认知复杂度降低到 ${input:complexityThreshold} 或以下。

分析当前方法，识别认知复杂度的来源：
- 嵌套的条件语句
- 多个 if-else 或 switch 链
- 重复的代码块
- 带条件的多个循环
- 复杂的布尔表达式
识别提取机会：
- 可以提取到单独方法中的验证逻辑
- 重复出现的类型特定或情况特定处理
- 复杂的转换或计算
- 多次出现的常见模式
提取专注的辅助方法：
- 每个辅助方法应有单一、清晰的责任
- 将验证提取到单独的 Validate* 方法中
- 将类型特定逻辑提取到处理程序方法中
- 为常见操作创建实用方法
- 使用适当的访问级别（static、private、async）
简化主方法：
- 减少嵌套深度
- 用更小的编排调用替换庞大的 if-else 链
- 在适当的地方使用 switch 语句以实现更清晰的分发
- 确保主方法读起来像高级流程
保留功能：
- 保持相同的输入/输出行为
- 保留所有验证和错误处理
- 保留异常类型和错误消息
- 确保所有参数正确传递给辅助方法
最佳实践：
- 当辅助方法不需要实例状态时，使其为静态
- 尽早使用空检查和守卫子句
- 避免创建不必要的局部变量
- 考虑使用元组返回多个值
- 将相关的辅助方法分组在一起

重构后的方法应：

关键：完成重构后，你必须：

运行所有现有测试，涉及重构方法及其周围功能
强制：明确验证测试结果显示 "failed=0"
- 切勿假设测试通过——始终检查实际测试输出
- 搜索包含通过/失败计数的摘要行（例如 "passed=X failed=Y"）
- 如果摘要显示任何非 "failed=0" 的数字，则测试失败
- 如果测试输出在文件中，读取整个文件以定位并验证失败计数
- 运行测试不等于验证测试通过
- 在明确确认零失败之前，不要继续
如果任何测试失败（failed > 0）：
- 明确说明有多少测试失败
- 分析每个失败以了解哪些功能被破坏
- 常见原因：空处理、空集合检查、条件逻辑错误
- 在重构代码中识别根本原因
- 修正重构代码以恢复原始行为
- 重新运行测试并验证输出中 "failed=0"
- 重复直到所有测试通过（failed=0）
验证编译——确保没有编译错误
检查认知复杂度——确认指标达到或低于目标阈值 ${input:complexityThreshold}

refactor-method-complexity-reduce