“犯错是人之常情”
程序员中间经常互相调侃，说自己的主要工作就是写各种BUG，然后在费劲心力的去消灭它。bug 各式各样，从页面打不开到数据丢失，让人习以为常。
或许有人会忍不住问：为什么 bug 总是会出现？
其实，bug 是代码的副产品。代码是人写的，而人总会犯错。就像硬币有正反面，人性的缺陷在代码中也无法避免。
如果你对 bug 零容忍，甚至把它写入 KPI，只会让开发者不敢做大改动，害怕引入更多风险。经历过这种情况情况的团队会心里憔悴，结果是团队没有动力重构或尝试新技术，创新停滞不前。
所以，bug 不可能完全消失，关键是如何减少它们的出现。
重新认识质量
在 MoSCoW 方法中，功能优先级分为四类：Must Have、Should Have、Could Have 和 Won’t Have。质量如果被当作一个功能，它往往不会是“必须有”的。用户不会因为一个应用没 bug 就一直用下去，也不会因为有 bug 就立刻换到竞争对手。
这意味着：
- 一些缺陷是可以容忍的。
- 质量的投入永远是有限的。
在快速迭代和低成本的互联网产品中，用户对质量的容忍度变得非常高。
关键问题是：如何用有限的资源最大化提升质量？如果只通过增加人手来修复 bug，问题不会真正解决，因为这只是加快了“清理”的速度，而不是减少“制造垃圾”的人。
现实中，很多公司当线上问题增多时，第一反应是责怪 QA。这种做法像是“刻舟求剑”，因为 bug 是编码过程中产生的，而不是 QA 能完全避免的。
我的观点其实是老生常谈：质量应该在开发过程中内建，测试要尽量“左移”。这些概念在网上有很多专业资料，这里不再展开。
质量的成本
接下来是一个关键问题：谁该对质量负责？官方回答是“每个人”，但实际上，程序员常常是首当其冲的。
假设你是团队经理，发现上个月线上问题数量翻了一倍，你冲到开发团队前怒吼：“我希望这个月问题数降到个位数！” 你觉得他们能做到吗？
事实上，质量是努力换来的，不是靠“希望”来的。提升质量有代价，关键是你愿意付出多少。
很多提升质量的做法其实早已被证明有效，比如重构、代码评审、结对编程和持续集成。以单元测试为例，在我所在的项目中，写 React 组件的单元测试时间几乎和开发功能的时间一样多。如果代码改动导致之前的测试失败，还要额外花时间修复，这些都是隐性的成本。
更大的难点在于改变工程文化。你需要保证开发者认真写测试，关注测试结果，并修复问题。同时，争取管理层的理解和支持，给这些实践留足空间。
工程实践往往很难立刻见效。比如你无法准确预测，在提高了测试覆盖率之后，bug 会减少多少。而实践带来的“负面”效应却很明显：团队交付速度会变慢。
测试的好处更多体现在未来，它可以增强我们在重构和改动时的信心，防止旧功能被新功能破坏。但这种收益往往是长期的，短期内难以看见。
于是，现状就是：迭代速度变慢了，质量的成本暂时看不到回报，最终质量成了可以被牺牲的部分。
还债
质量问题不是个人问题，而是团队甚至整个行业的问题。我们需要面对现实，虽然提升质量的投入见效慢，但这不是可有可无的事情。
虽然有时候“快”比“好”更重要，但当质量问题不可避免地出现时，别忘了它是在什么时候被忽视的。