质量门是什么
质量门把团队的容忍底线自动化：对「新代码」设定阈值（阻断级问题、增量覆盖率、新代码重复率等），不达标即流水线失败。关键在作用域是新增或修改的代码，而不是整个历史仓库——存量债务不因为门禁上线就消失，但可以从此停止增长。阈值应从团队当前基线出发、随能力逐步收紧，而非一步到位。
基本信息
| 重点 | 新代码质量（Clean as You Code） |
|---|---|
| 收紧节奏 | 从当前基线出发，每季度小步提高 |
| 范围 | 阻断项要少而准——红灯必须与风险强相关 |
| 配套 | 失败时给出修复指引与豁免流程 |
| 载体 | SonarQube Quality Gate、CI 脚本中的 lint 与测试门槛 |
实施要点
- 先止新增：新增阻断级问题为零，比追求总量下降更快见效
- 阻断项控制在少数几条，多了团队会找绕过路径
- 阈值从现状统计而来，拍脑袋定的目标会被立刻违反
- 每次抬头都有对应的整改动作，例如这季度补哪类测试
- 失败信息要能直接定位文件与行号，并提供修复指引
- 豁免需要记录理由与到期时间，避免变成永久的静音开关
演进路径示例
演进路径示例
Q1：新增 Blocker = 0（先止新增）
Q2：新增代码覆盖率 ≥ 60%
Q3：新代码重复率 ≤ 5%
Q4：覆盖率目标提至 80%，并接入变异测试抽检
# 每个季度只抬一项，抬之前先回看上一季是否稳定达标门禁项示例
| 门禁项 | 作用域 | 阈值来源 |
|---|---|---|
| 阻断级问题 | 新增代码 | 团队共识：安全与正确性优先 |
| 增量覆盖率 | 本次改动 | 当前基线上浮一档 |
| 新代码重复率 | 新增代码 | 观察历史波动后定线 |
| 静态扫描关键规则 | 全量但只报新违规 | 按规则严重级别分级 |
| 构建时长 | 流水线 | 超出即告警并回看 |
门禁不是质量的全部：它只能拦住可自动判定的一类问题，架构判断与命名取舍仍需评审。把门禁当作评审的减负手段，而不是替代品。
门禁一步到位最常见的结果是绕过：PR 被反复拒绝几次后，团队会开始拆大改动、加忽略标记或干脆不走流水线。宁可先松后紧，也不要一开始就满屏红灯。