你从未被教过如何构建高质量软件
许多工程师认为，计算机科学教育和典型实习更关注算法和交付功能，而几乎没有系统性地训练软件质量、测试和长期可维护性。评论者将此与航空和制造等将严格 QA 与事后复盘流程嵌入其中的领域进行对比，但也指出这些做法成本高昂，并且常常与追求速度的商业激励相冲突。争论的核心在于：“质量”是否能被正式教授、多少只能通过经验获得，以及如何在主要以速度和短期结果为优化目标的组织中证明 QA 工作的合理性。
“高质量软件”是什么意思（以及它是否可教）
- 许多人认为“质量”这个词很模糊：它是可靠性、性能、可维护性、用户体验，还是业务价值？
- 有些人说，质量主要是通过实践和反馈学来的，而不是课堂理论。
- 另一些人坚持认为，确实存在一门学术和工程学科（软件工程、QA、形式化方法）来教授质量，只是其采纳并不均衡。
与其他领域的比较（航空、制造、工程）
- 航空和制造被引用为通过检查清单、监管、事故复盘和流程控制系统性教授质量的例子。
- 有人建议，如果为软件制定一份类似的 500 项检查清单，可能会大幅减少 bug，但会扼杀初创公司式的速度。
- 反方观点：即便在“硬核”工程中，缺陷、召回和故障也很常见；一切都是“足够好”，而不是完美。
大学 CS 与软件工程
- 一个反复出现的抱怨是：CS 课程重点放在算法、编译器、理论和低层系统上，但几乎不讲 QA、测试、调试策略或大规模系统设计。
- 也有人表示自己上过很认真的软件工程课程：测试、SDLC、UML、团队项目、模拟现实维护的毕业设计。
- 关于大学应该是职业培训还是纯教育，存在争论，尤其是在学费上涨和就业期待提高的背景下。
QA、测试与流程
- 一个强烈主题是：QA 常常因为进度压力被最后才加上去（甚至被跳过）；“QA 冲刺”和后期测试被点名为反模式。
- 支持者推动：与代码同步编写测试、CI/CD、自动化、快照/视觉测试、覆盖率加变异/模糊测试，以及深思熟虑的指标（同时注意 Goodhart 定律）。
- 有人指出，确实存在高质量团队，其中 40–60% 的工作投入在测试和质量工作上，但这并非常态。
Bug、“无 bug”说法与形式化方法
- 共识是：除了极其简单的程序外，绝对无 bug 的软件在实践中不可实现；“零 bug”更适合作为渐近线，或“相对于规格没有已知缺陷”。
- 对“bug”的定义存在争论（偏离规格 vs. 任何意外行为），以及规格错误是否也算在内。
- 形式化方法和证明可以消除安全关键领域中的某些缺陷类别，但成本高、适用范围有限，而且无法修复糟糕或不完整的规格。
经济、激励与权衡
- 许多人指出，管理层往往优先考虑速度和可见功能，而不是质量，因为业务指标很少奖励长期可维护性。
- 质量成本是分散且延后的（技术债、团队变慢、用户浪费时间），而开发成本是即时且可衡量的。
- 有人认为，在大规模下，即使“罕见”bug 也会变得常见，并造成“千刀万剐式”的伤害；但也有人声称，大多数市场都能容忍平庸的软件，只要它上线快并且解决了问题。