质量内建是什么
质量内建（Built-in Quality）把质量活动嵌进研发流程的每个环节：需求可测试、提交即验证、评审常态化、缺陷预防先于检出。目标不是堆积更多检查，而是缩短「缺陷被引入」到「缺陷被发现」的时间——越早发现越便宜，流程自身的节拍就是质量的保障。它是精益思想中「内建质量」实践在软件研发上的落地。
各阶段的内建动作
- 需求阶段：可测试的验收标准（Given-When-Then）。
- 编码阶段：静态检查、单元测试、代码评审。
- 合并阶段：流水线门禁（测试、覆盖率、安全扫描）。
- 发布阶段：灰度与生产验证、监控告警。
- 回顾阶段：缺陷数据反哺模板与规范，堵住同类问题的源头。
基本信息
| 核心理念 | 预防先于检出，尽早发现缺陷 |
|---|---|
| 落地形式 | 模板约束、自动化门禁、评审机制、度量反馈 |
| 度量目标 | 缩短引入到发现的时延，而非增加检查数量 |
| 常见载体 | CI 流水线、Git 钩子、需求与评审模板 |
| 失败信号 | 所有检查都堆在发布前，等于末端拦截 |
提交前本地检查
提交前本地检查
# 示例（不同技术栈命令不同）
npm run lint && npm test -- --changed
# 或在 Git hook / CI 中统一执行
# 要点：检查在开发者手边就能跑，不依赖专门的「测试阶段」质量内建的目标是缩短「引入缺陷到发现缺陷」的时间，而不是增加检查的数量。
门禁要配修复机制：红灯出现后谁在多久内处理、如何处理，写进团队约定，否则门禁会被习惯性绕过。
模板是低成本内建：需求模板里的可测试性检查项、缺陷模板里的定级例子，比开会强调更持久有效。
内建不等于零缺陷：目标是让残余风险可控、缺陷暴露得更早，而不是承诺任何问题都不会流出。