应该修复不重要的错误，以免它们分散开发人员的注意力吗？

Question

虽然Joel Spolsky认为在编写新代码之前应该修复每个错误，但很多地方的现实是开发人员非常忙碌，而有些错误被认为是有价值的，而其他错误则不然。单元测试通常也被视为很好。

我一直在追逐一个关键应用程序中的神秘错误，并在此过程中找到了一些小错误。我向原作者提到了他们，他说了一句“哦，是的......我记得3年前QA提出了这些问题，但他们被关闭了。”

我认为一些开发人员更擅长于其他人的多任务处理。就我个人而言 - 我喜欢一次做一件事，即使有一个0.1%机会让一个不重要的错误可能与一个严重的错误相互作用，我也有一种想要先解决一个不重要的错误的冲动（在这个过程中也要更好地理解它），不要在以后考虑它。

一方面，我会浪费时间在业务分析师认为不值得的事情上。另一方面 - 如果我可以专注于那一项任务，我可能能够更快地解决这个重要的错误。

在我尝试提出这个论点之前，我想问一下你的想法和经历是什么样的。问题被标记为社区维基。感谢。

Answer 1

这听起来像属于“对你和你的团队最有效”的类别。如果你真的那么紧张，你没有时间来修复错误，那么无论如何你都需要有充分的理由。

如果这些错误让你烦恼并阻止你专注于更大的问题，这可能足以说明这一点，尽管你可能要解释为什么你错过了发货日期，因为你花了一个星期来修复琐碎的错误然后修复一个大错误。

Answer 2

虽然很高兴认为你可以发布无错误的代码，但实际上总会有另一个代码。也就是说，我认为最实用的方法是按照严重程度对您所知道的顺序进行排序，并根据时间和资源允许情况对每个进行排序，并按严重程度排列。

Answer 3

Joel's post澄清了“你在编写新代码之前修复了错误吗？”哲学。

“”零缺陷“意味着在任何给定时间，最高优先级是在编写任何新代码之前消除错误。”

这种解释可以使用稍微澄清，但我能够认为他并不意味着有完美的期望，而程序员应该努力追求完美。这意味着程序员不应该故意吝啬方法实现只是为了让产品脱颖而出。 {零}缺陷心态的full definition有助于澄清：

“成功团队的最佳实践或原则，这意味着项目团队承诺在完成任务时以最高质量开展工作，并且每个团队成员都有责任帮助实现所需的水平质量。零缺陷心态并不意味着部署的解决方案必须“完美”，没有任何缺陷;相反，它将完美作为团队努力的一贯目标。“

由于您要向您的团队提出建议，请记住这一理念是团队理念。如果团队不接受您的论点，但是您试图自己遵循这一点，那么试图自行遵循这一点可能会导致高度的挫败感。

Answer 4

请记住，每当您更改代码时，您可能会引入新的错误，因此通过修复那些被认为不重要的小错误来修复，您可能会意外地引入一个新的严重错误。有时这是一个值得冒险的风险，但对于一些关键的系统，如果没有充分的理由，你绝不应该触及任何代码。那么你正在研究什么样的系统可以成为回答这个问题的重要因素。

Answer 5

非常有趣的问题。像其他人说的那样，这取决于团队。资源，截止日期，个人信仰以及更多干扰这个问题。

在您的情况下，我认为最好的选择是与您的上司和同事讨论此事。不要只为自己承担所有责任。