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