Git Diff 复杂度分析器

要解决的问题

在代码审查中，开发者常聚焦逻辑正确性与测试覆盖，却难以量化单次 diff 对圈复杂度的影响。一个看似简单的分支条件新增，可能让单个函数的可维护性从“易理解”滑向“需重写”。传统人工审查难以快速定位这类变更，尤其在团队协作中，复杂度的微小累积会逐渐演化成技术债。

工作原理

该技能围绕 git diff 展开结构化分析，核心能力如下：

• 依赖 libgit2 解析差异：直接读取仓库的变更集，精准提取新增、修改或删除的代码行，避免依赖文本匹配带来的误判。
• 调用 radon 计算圈复杂度：对 diff 涉及的函数逐一分析，区分前后版本的复杂度值。例如，若某函数在修改前复杂度为 8，修改后升至 15，差值会被标记为回归。
• 生成内联审查评论：通过 PyGithub 将结果转化为可定位的评论，直接在 GitHub 的 Pull Request 页面对应代码行显示警告，而非仅在文件级提示。

关键步骤包括：提取 diff 中的函数边界→计算每个函数的复杂度增量→过滤掉无实际逻辑变化的噪声（如重命名或空行）→按阈值（如+3）筛选风险项→通过 GitHub API 写入评论。

适用边界与注意点

• 语言偏向性：radon 原生支持 Python，若 diff 涉及其他语言，需确认其复杂度计算规则是否适配。
• 阈值需自定义：固定阈值无法适配所有团队，建议根据业务场景调整“回归”判定标准（如核心服务阈值设为+2，工具类设为+5）。
• 依赖仓库结构：对合并提交或复杂分支模型，diff 解析可能需额外配置，避免因代码块跨文件引用导致分析偏差。