code-health

使用 Repowise 检查代码健康度

Repowise 根据确定性标记为每个文件打分，范围为 1–10，标记包括 McCabe 复杂度、深层嵌套、脑方法、类内聚性（LCOM4）、上帝类、克隆检测、未测试热点、函数级变更频率、代码所有权分散程度等。不会调用 LLM；完全在本地分析。权重基于真实缺陷语料校准，因此低分表示更可能存在错误，而不只是代码量更大。

根据传入内容选择模式

• 仪表板：get_health()（不传目标）：先显示 fix_first，即按优先级排列的修复项列表，然后显示仓库级 KPI 和得分最低的文件。想了解“这个代码库的健康状况如何？”或“我们应该清理哪些内容？”时，从这里开始。
• 定向分析 — get_health(targets=["src/x.py", "src/y.py"])：逐个文件显示分数，以及导致该分数的具体标记发现。可在重构前后使用，也可用于解释文件为何被标记。

实用的 include 标志

get_health(targets=[...], include=[...])：

• "biomarkers" — 始终返回发现列表（问题所在及位置）。
• "refactoring" — 返回确定性的重构建议，并按影响／工作量排序。
• "coverage" — 如果已导入覆盖率数据，则显示该数据。
• "trend" — 返回近期健康度快照，以及健康度下降／预测下降信号。

include 用于添加区块；only=[...] 用于移除区块。

如何使用结果

1. 对于“我应该重构什么？”→ 使用仪表板模式，优先展示 fix_first；通过 get_health(fix_id=...) 展开某个条目，查看其步骤和要运行的测试，并展示计划，而不只是分数。
2. 按 weighted_deficit 排序，而不是按 score 排序——分数最低为 1.0。
3. 针对特定文件 → 报告分数、排名前 2–3 的标记发现，以及每项发现的通俗含义。避免直接倾倒原始负载。
4. 在判断文件没有问题之前，先检查 unresolved：其中列出的目标未匹配到任何内容；not_indexed 则表示需要运行 repowise update。
5. 编辑被标记的文件前 → 交叉检查 get_risk(targets=[...])；健康度低且属于变更热点的文件需要格外谨慎。
6. 对于未测试热点／覆盖率相关问题 → 告知用户，导入报告后会显示覆盖率标记：repowise coverage add cov.lcov（支持 LCOV / Cobertura / Clover；coverage.py 的 .coverage 文件也会生成逐测试映射），然后运行 repowise health --recompute，将覆盖率数据纳入评分。

CLI 等效命令

• repowise health — KPI + 得分最低的文件
• repowise health --refactoring-targets — 按影响／工作量排序
• repowise health --trend — 快照 + 健康度下降提醒
• repowise coverage add <file> — 导入覆盖率数据，显示未测试热点

错误处理

如果 get_health 报告找不到仓库，建议运行 /repowise:init。即使使用模板渲染的 wiki，代码健康度也会照常计算（无需 LLM），因此只要仓库已建立索引，就应该可以使用。