Bug 存续的原因：不受欢迎的观点 | AI生成和翻译
问题：关于开发者或团队未能解决软件问题或修复 bug 的一些不受欢迎的观点是什么？
回答：
以下是一些关于 bug 持续存在或问题未能解决的、真正不受欢迎（且往往令人不适）的观点，这些观点基于真实世界的观察而非令人愉悦的叙述：
-
大多数 bug 在技术上并不难——它们在社交上很难。 代码修复显而易见，但某人的自负、政治或害怕被指责使其未能修复。团队宁愿忍受一个已知的 bug 数年，也不愿承认最初的作者（或架构师）是错的。
-
“我们没有时间好好修复它”实际上意味着“我们没有能力好好修复它。” 经验丰富的工程师能迅速修正根本原因。不称职或初级工程师过多的团队会将一行代码的修复变成长达数月的拉锯战，然后将责任归咎于“技术债务”。
-
许多持续存在的 bug 实质上是伪装的特性。 用户已经适应了围绕 bug 的工作流程。对其进行“正确”修复会打乱肌肉记忆或第三方工具，因此 bug 悄然变成了规范。
-
代码审查并不能阻止 bug——它们只是分散了责任。 一个糟糕的设计获得了六个“LGTM”批准，因为没有人想成为那个阻止 PR 或承认自己不完全理解它的人。
-
“在我的机器上能跑”是道德上的失败，而不是一个正当的借口。 如果你的团队在 2025 年还能一本正经地说这句话，那你们已经输了。
-
最糟糕的 bug 是那些没有人报告的，因为用户认为“软件就是这样”。 默默忍受是默认的用户体验；你知道的 bug 都是容易解决的。
-
结对编程和 TDD 对于大多数代码库中的 bug 预防而言被高估了。 它们有助于初级人员提升水平并使代码看起来整洁，但大多数生产 bug 来自需求误解、竞态条件和外部变更——这些是测试和结对很少能捕获的。
-
有些 bug 应该保持未修复。 对于一个每年影响 0.001%用户一次、需要高风险重构且有可靠变通方案的 bug，成本效益计算是显而易见的——但大声说出来会让你被指责“不关心质量”。
-
90% 的情况下，将责任归咎于“遗留代码”是在推卸责任。 真正的原因是理解旧系统的人已经离开了，而新团队不敢触碰它。“遗留”只是意味着“我们解雇了所有知道它如何工作的人”。
-
高级工程师导致的未修复 bug 比初级工程师更多。 初级工程师编写的代码虽然粗糙，但容易被发现和修复。高级工程师编写“巧妙”的抽象，它们看起来很美观，但在实际负载下却会崩溃，而且没有人敢质疑它们。
这些观点之所以不受欢迎，是因为它们将责任从“代码”或“管理层”转移到了房间里实际存在的人和激励机制上——而大多数人宁愿保留那些令人舒适的迷思。
参考资料：