cyclomatic-complexity

圈复杂度

目的：AI 编写的代码往往能正常工作，但分支却像丛林一样复杂。本技能用于衡量复杂度、重构热点，让代码保持易于人工维护。

先衡量

CC = 决策点 + 1。决策点包括：if、else if、case、循环、catch、三元表达式，以及条件中的 &&、||。

以项目的 linter 配置为准。如果 eslintrc、radon 配置、sonar 配置或类似配置设置了复杂度阈值，就使用该阈值。没有配置时，使用以下默认值。

阈值：

• 1-5：正常，保持不动
• 6-10：留意；如果本来就要修改，可考虑重构
• 11-15：立即重构
• 15 以上：必须拆分，不容争议

环境允许时，优先使用实际工具，而不是凭目测判断：

• Python：radon cc -s -a <path>
• JS/TS：eslint complexity 规则
• Go：gocyclo
• 多语言项目：lizard <path>

没有可用工具时，按函数手动计数，并显示计数结果。

重构策略，按优先顺序排列

1. 卫语句。 反转条件，提前返回，消除嵌套。
2. 提取函数。 为提取出的每段代码起一个说明做什么、而非怎么做的名字。名称就是文档。
3. 使用查找表 / 映射代替 if-else 或 switch 链。
4. 命名谓词。 if (isEligibleForRefund(order)) 胜过包含 4 个子句的布尔表达式。
5. 对按类型切换的逻辑使用多态 / 策略模式。仅当该 switch 出现在 2 个或更多位置时使用。
6. 扁平化循环。 提取循环体，并使用 continue 代替嵌套 if。

硬性规则

• 保持行为不变。修改前后都运行测试。没有测试时，应说明并建议添加测试，谨慎重构。
• 不要钻指标空子。用一行密集代码隐藏 6 个分支，比原本直白的 if 链更糟。复杂度应转移到名称清晰的单元中，而不是靠技巧将其隐藏。
• 未经询问，不要破坏公共 API 或导出签名。
• 函数少而职责清晰、命名明确，胜过用注释解释各个部分。
• 每个函数只负责一项职责。如果名称里需要用“和”，就拆分。

工作流

1. 衡量所有涉及的函数，按 CC 从高到低排序。
2. 动手前，报告复杂度最高的热点及其数值。
3. 从最复杂的函数开始，一次重构一个函数。
4. 重新衡量。展示修改前后的表格：函数、修改前 CC、修改后 CC。
5. 验证：测试通过、行为未变、差异易于审查。

输出格式

每次重构结束时都附上：

## Complexity report
| Function | Before | After |
|----------|--------|-------|
| parseOrder | 14 | 4 |

Extracted: validateHeader, resolveDiscount
Behavior verified: <how>

尽量精简说明。用数字和差异说话。