热点怎么识别
把改动最频繁的代码与复杂度指标叠加就能找出热点：热点等于高变更频率乘以高复杂度（或高缺陷密度）。它是投资回报较高的偿还区域，也是重构清单的输入——优先改经常改又难改的地方，而不是看着别扭的地方。
基本信息
| 数据来源 | 版本历史（提交次数、改动行数）加静态分析（复杂度） |
|---|---|
| 呈现方式 | 散点图或矩阵，高频高复杂度区优先 |
| 交叉验证 | 对照缺陷记录与工单分布 |
| 阈值选择 | 取各指标靠前的少量文件 |
| 主要用途 | 排定重构优先级 |
典型使用场景
- 制定季度重构计划时选目标模块
- 评审中判断某处为何总是容易出错
- 新人接手前找出最需要先读懂的模块
- 事故复盘时确认热点是否已被处理
- 评估重构收益时对照改动频率
分析思路
分析思路
# 变更频率：近 12 个月每个文件的提交次数
# 复杂度：圈复杂度或认知复杂度
# 热点 = 两个维度都靠前的文件集合
# 交叉验证：这些文件的缺陷与工单占比是否也偏高
# 结论应落在少量文件上，否则无法排期四象限怎么用
| 象限 | 特征 | 建议 |
|---|---|---|
| 高频高复杂 | 热点 | 优先重构并补测试 |
| 高频低复杂 | 简单但活跃 | 保持现状，注意别加复杂度 |
| 低频高复杂 | 隐患 | 需要改动时再重构 |
| 低频低复杂 | 安静区域 | 不必投入 |
热点分析让重构决策有数据依据：它把讨论从代码看起来糟不糟，转移到这块代码每天消耗多少时间。
只看复杂度不看变更频率，会把预算花在几乎不改的老模块上；数据只看一个季度，也会被阶段性项目波动误导。
热点会漂移：模块被重构或业务重心转移后，高频区域随之移动。建议每季度重新计算一次，并保留历史结果做前后对比。