是否应该修复不重要的错误，以免分散开发人员的注意力？
虽然 Joel Spolsky 认为每个错误都应该在编写新代码之前修复，但许多地方的现实是开发人员非常忙碌，有些错误被认为是值得的，而另一些错误则不然。单元测试也常常被认为是值得拥有的。
我一直在寻找一个关键应用程序中的神秘错误，并在此过程中发现了一些小错误。我向原作者提到了它们，他说了类似“哦，是的......我记得 QA 在 3 年前提出了这些问题，但它们被关闭了”。
我认为有些开发人员更擅长同时处理其他任务。就我个人而言 - 我喜欢一次只处理一件事，即使有 0.1% 的可能性，一个不重要的错误可能与一个严重的错误相互作用，我也有一种修复的冲动首先处理一个不重要的错误（在这个过程中也能更好地理解它），然后就不再考虑它。
一方面，我会把时间浪费在业务分析师认为不值得的事情上。另一方面 - 如果我能专注于那一项任务，我也许能够更快地修复重要的错误。
在我尝试提出这个论点之前，我想问一下您对这种情况的想法和经历。问题被标记为社区 wiki。谢谢。
While Joel Spolsky thinks that every bug should be fixed before new code is written, the reality in many places is that developers are very busy, and some bugs are deemed worthy while others are not. Unit testing is also often treated as nice to have.
I have been chasing a mysterious bug in a critical application, and found a few minor ones in the process. I mentioned them to the original author, and he said something like "Oh yeah ... I remember QA raised these 3 years ago but they were shut down".
I suppose some developers are better at multi-tasking at others. With me personally - I like to work on one thing at a time, and even if there is a 0.1% chance that an unimportant bug might be interacting with a serious one, I have an urge to just fix an unimportant bug first (understand it better in the process too) and not think about it later.
On one hand I would be wasting my time on what business analysts deemed not worthy. On the other - I might be able to fix the important bug faster if I can focus on just that one task.
Before I try to make this argument, I wanted to ask what your thoughts and experiences are with a situation like this. Question is marked as community wiki. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这听起来像是属于“最适合您和您的团队的方式”的类别。如果你的日程安排真的很紧，以至于没有时间修复错误，那么无论如何你都需要有一个充分的理由来这样做。
如果这些错误让您烦恼并阻止您专注于更大的问题，那么这可能足以成为这样做的理由，尽管您可能必须解释为什么您错过了发布日期，因为您花了一周时间修复了一些小错误，然后才修复了一个大问题漏洞。
This sounds like it falls under the category of "whatever works best for you and your team". If you're really that tight on schedule that you don't have time to fix the bugs, you need to have a good justification for doing it anyway.
If the bugs annoy you and stop you from focusing on bigger problems, that might be enough of a justification to do it, although you might have to explain why you missed a ship date because you spent a week fixing trivial bugs before fixing the one big bug.
虽然很高兴认为您可以交付无错误的代码，但实际上总有另一种。也就是说，我认为最务实的方法是按严重程度对您了解的问题进行排序，并在时间和资源允许的情况下修复每个问题，并按严重程度确定优先级。
While it's nice to think you can ship bug-free code, in reality there's always another one. That said, I think the most pragmatic approach is to rank order the ones you know about by severity and fix each as time and resources permit, prioritized by severity.
Joel 的帖子澄清了“在编写新代码之前修复错误吗？”哲学。
“‘零缺陷’意味着在任何给定时间，最高优先级是在编写任何新代码之前消除错误。”
这个解释可能需要稍微澄清一下，但我可以推断他并不意味着期望完美，而是程序员应该努力追求完美。这意味着程序员不应该仅仅为了将产品推出市场而故意省略方法实现。 “零缺陷”的完整定义心态”有助于澄清：
“成功团队的最佳实践或原则，这意味着项目团队致力于在完成工作时以尽可能高的质量完成工作，并且每个团队成员都单独负责帮助实现目标所需的质量水平。零缺陷思维并不意味着部署的解决方案必须“完美”，实际上没有任何缺陷；相反，它将完美确立为团队努力追求的一致目标。”
既然您要向您的团队提出建议，请记住这种理念是团队理念。如果你的论点没有被团队接受，但你自己尝试遵循这一点，尝试自己遵循这一点可能会导致高度的挫败感。
Joel's post clarifies the "Do you fix bugs before writing new code?" philosophy.
""zero defects" meant that at any given time, the highest priority is to eliminate bugs before writing any new code."
This explanation could use slightly more clarification, but I am able to gather that he does not mean there is an expectation of perfection, rather programmers should strive for perfection. This means a programmer should not knowingly skimp on a method implementation just to get the product out the door. A full definition of the "zero defects mindset" helps to clarify:
“A best practice or principle of a successful team, it means the project team commits to do work at the highest quality possible at the time it is being done, and each team member is individually responsible for helping achieve the desired level of quality. The zero-defect mindset does not mean that the deployed solution must be “perfect” with literally no defects; rather, it establishes perfection as a consistent goal for the team to strive for.”
Since you are going to make a recommendation to your team, keep in mind that this philosophy is a team philosophy. Trying to follow this on your own could lead to a high level of frustration in the case where your argument is not accepted by the team, but you try to follow it yourself.
请记住，每当您更改代码时，您都可能会引入新的错误，因此通过修复那些被认为不重要的小错误，您可能会意外地引入新的严重错误。有时这是值得冒的风险，但在某些关键系统上，如果没有充分的理由，您不应该触摸任何代码。因此，您正在开发什么样的系统可能是回答这个问题的重要因素。
Just remember that whenever you change code you might introduce new bugs, so by fixing those small bugs deemed to unimportant to fix, you might accidently introduce a new serious bug. Sometimes that's a risk worth taking, but on some, critical, systems you should never touch any code without good justification. So what kind of system you're working on can be an important factor for answering this question.
非常有趣的问题。正如其他人所说，这取决于团队。资源、截止日期、个人信仰等等都会干扰这个问题。
对于你的情况，我认为最好的选择是与你的上级和同事讨论这个问题。不要只为自己承担所有责任。
Very interesting question. Like others said, it's up to the team. Resources, deadlines, personal beliefs and much more interfere on this question.
In your case, I think the best option is to discuss this matter with your superiors and workmates. Don't take all the responsibility only for yourself.