代码流失率在说什么
代码流失率（Code Churn）统计一段时间内代码新增、修改与删除的行数分布。它的用途不是衡量产出，而是发现不稳定区域：某个文件在几个月内被反复重写，通常意味着需求反复、设计不适配或缺少共识。把流失率与缺陷、变更频率交叉看，可以把设计评审与需求复盘的注意力引向最需要的地方。
口径与用法
| 口径 | 时间段内的新增、修改、删除行数，可按文件或模块聚合 |
|---|---|
| 正确用法 | 识别反复改动的震荡文件，作为评审与复盘输入 |
| 错误用法 | 作为个人产出或生产力指标 |
| 配套数据 | 缺陷记录、变更频率、模块所有权 |
典型使用场景
- 震荡区域排查：找出三个月内被多次重写的文件，判断是需求反复还是设计问题
- 需求复盘：流失率高的模块往往对应用户需求变化频繁，可作为澄清机制的改进输入
- 重构时机判断：高流失率叠加高缺陷的模块优先级最高
- 设计评审：新模块上线后持续高流失，说明接口或数据模型可能存在缺陷
- 提交规范检查：排除格式化与生成代码对统计的干扰
震荡信号示例
震荡信号示例
# 观察：文件 A 在三个月内被重写 4 次，churn 显著高于同类文件
推断方向：需求反复？设计不适配？缺少接口共识？
对应动作：需求澄清会 + 设计评审，先确定变化原因再谈重构
# 注意：统计前排除格式化提交与生成代码，否则数字失真流失与缺陷交叉解读
| 流失 | 缺陷 | 解读与动作 |
|---|---|---|
| 高 | 高 | 优先处理：需求与设计都可能有问题，先做澄清与结构梳理 |
| 高 | 低 | 可能是需求变化快，检查接口是否需要更稳定的抽象 |
| 低 | 高 | 问题可能不在代码结构，检查测试覆盖与评审质量 |
| 低 | 低 | 属于稳定区域，维持现状 |
| 突然升高 | 不限 | 核对是否有重构或需求变更项目正在进行 |
统计前先排除格式化提交、依赖升级与生成代码：这些改动会产生大量行级变化，若未剔除，流失率会被严重扭曲，结论也随之偏离。
流失率高本身不是问题：新模块在早期快速迭代时流失率自然会高。判断要看持续时间与是否收敛，长期不收敛的区域才值得投入设计改进。
落地检查清单
- 统计窗口与聚合粒度在报告中写明
- 已排除格式化、依赖升级与生成代码
- 与缺陷、变更频率交叉解读，而不是单看一项
- 每个高流失区域都有跟进结论