巴士系数与代码所有权
巴士系数指的是关键模块在失去多少名成员之后会停摆：数值为一说明该模块只有一个人真正熟悉。判断方式不是凭印象，而是看提交历史里模块的贡献者分布与集中度。风险不在于是否有多人提交过代码，而在于关键决策与细节是否只存在于一个人的记忆中。降低集中度的常见手段是结对、评审轮换与决策文档化。
观察与手段
| 度量对象 | 模块级的贡献者分布与提交占比 |
|---|---|
| 风险表现 | 唯一熟悉者休假或离职时，模块改动被阻塞 |
| 主要手段 | 结对开发、评审轮换、关键决策文档化 |
| 注意 | 目标是分散关键知识，不是追求数量上的平均 |
典型使用场景
- 排期风险评估：接手需求前先看模块的知识集中度，评估阻塞概率
- 人员变动应对：确认关键模块是否有第二熟悉人可临时接手
- 新人融入：安排集中度高的模块作为结对学习对象
- 评审人分配：让非主力贡献者参与该模块评审，逐步扩大熟悉范围
- 文档补强：为仅一人熟悉的模块补齐设计决策与排障说明
分析思路
分析思路
# 按模块统计近 12 个月的贡献者与提交占比
主力贡献者占比超过 80% → 标记为高集中度
第二贡献者占比低于 10% → 缺少有效的备份知识
# 对应动作
指定第二负责人，安排结对任务与轮流评审
补齐设计决策文档与排障手册集中度与动作
| 集中度 | 风险 | 建议动作 |
|---|---|---|
| 单人占比极高 | 人员变动即停摆 | 结对开发，指定第二负责人 |
| 两人分担 | 短期可控，缺少第三人 | 评审轮换扩大到其他成员 |
| 多人分散 | 知识分布相对健康 | 保持评审轮换与文档更新 |
| 挂名贡献者多 | 看似多人实际无人深耕 | 核对提交质量，避免用人数代替深度 |
| 关键模块无人维护 | 变更时无人能评审 | 明确归属并安排接手 |
判断标准应包含活跃度：仅统计提交过代码的人，会把早期参与或格式调整的提交也算进来，形成人数虚高的假象。按时间段与提交内容过滤后再看分布更有意义。
不要追求人人均等：让所有人平均参与所有模块，会导致没人真正深入。合理做法是在高集中度模块上确保至少有一名可接手的第二人，其他模块维持自然分工。
落地检查清单
- 关键模块有明确的第二熟悉人
- 结对与评审轮换有具体安排，而不只是口号
- 设计决策与排障步骤有文档记录
- 统计时过滤非实质贡献，避免人数虚高