虽然 Joel Spolsky 认为每个 bug 都应该在编写新代码之前修复，但许多地方的现实是开发人员非常忙，有些 bug 被认为值得，而另一些则不值得。单元测试也经常被视为很好。
我一直在追踪一个关键应用程序中的一个神秘错误，并在此过程中发现了一些小错误。我向原作者提到了它们，他说了类似“哦，是的......我记得 QA 在 3 年前提出了这些，但它们被关闭了”。
我想有些开发人员在其他人身上更擅长多任务处理。就我个人而言——我喜欢一次只做一件事，即使0.1%一个不重要的 bug 可能会与一个严重的 bug 交互，我也有一种冲动先修复一个不重要的 bug（在过程），以后不要考虑。
一方面，我会在业务分析师认为不值得的事情上浪费时间。另一方面——如果我能专注于那一项任务，我可能能够更快地修复重要的错误。
在我试图提出这个论点之前，我想问一下你对这种情况的想法和经验。问题被标记为社区 wiki。谢谢。
这听起来像是属于“对您和您的团队最有效的”类别。如果您的日程安排非常紧迫，以至于您没有时间修复错误，那么无论如何您都需要有充分的理由这样做。
如果错误使您烦恼并阻止您专注于更大的问题，那可能就足以成为这样做的理由，尽管您可能必须解释为什么您错过了发货日期，因为您花了一周时间修复琐碎的错误，然后才修复了一个大问题漏洞。
虽然很高兴认为您可以发布无错误的代码，但实际上总会有另一个。也就是说，我认为最实用的方法是按严重程度对您所知道的进行排序，并在时间和资源允许的情况下修复每个问题，并按严重程度进行优先级排序。
Joel 的帖子澄清了“在编写新代码之前你会修复错误吗？” 哲学。
“‘零缺陷’意味着在任何给定时间，最重要的是在编写任何新代码之前消除错误。”
这个解释可以稍微澄清一下，但我可以推测他并不是说有完美的期望，而是程序员应该努力追求完美。这意味着程序员不应该为了将产品推出而故意忽略方法实现。“零缺陷心态”的完整定义有助于阐明：
“成功团队的最佳实践或原则，意味着项目团队承诺在完成工作时以尽可能高的质量完成工作，每个团队成员都有责任帮助实现所需的质量水平。零缺陷的心态并不意味着部署的解决方案必须是“完美的”，几乎没有缺陷；相反，它将完美确立为团队努力追求的一致目标。”
由于您要向您的团队提出建议，请记住，这种理念是一种团队理念。如果您的论点不被团队接受，但您自己尝试遵循它，则尝试自己遵循这一点可能会导致高度的挫败感。
请记住，每当您更改代码时，您可能会引入新的错误，因此通过修复那些被认为不重要的小错误，您可能会意外地引入新的严重错误。有时这是值得冒的风险，但在某些关键系统上，如果没有充分的理由，您永远不应该接触任何代码。所以你正在研究什么样的系统可能是回答这个问题的一个重要因素。
非常有趣的问题。正如其他人所说，这取决于团队。资源、截止日期、个人信仰等等都会影响这个问题。
就你而言，我认为最好的选择是与你的上级和同事讨论这个问题。不要只为自己承担所有责任。