这个问题看似合理，但其实话里预设了：
- 代码行=工作量
- 代码行=价值
- 所有的代码行都是相同的
这些预设都不对。
为什么一个看起来很简单的修改要花两天时间才能完成?
- 因为发现这个问题时，对如何重新创建它的描述含糊不清。我花了好几个小时才弄到一份可靠的复制品。一些开发人员会立即回到报告问题的人那里，要求在调查之前获得更多信息。我试着用所提供的信息做尽可能多的事情。我知道有些开发人员不喜欢修复 bug，所以他们会尽一切努力摆脱它。声称“还不够”是一个很好的方式，让人觉得你在尽力帮忙，但却什么都不用做。我知道报告错误可能很难，我对任何这样做的人表示感谢。我想通过在询问更多细节之前尽可能多地使用所提供的信息来表示对错误报告的赞赏。
- 由于报告的问题与功能有关，我不太熟悉。它所涉及的功能是我很少使用的，也不是我曾经详细使用过的。这意味着我花了更多的时间去理解如何使用它，以及它如何与有缺陷的软件相互作用的细微差别。
- 因为我花了时间调查问题的真正原因，而不仅仅是查看问题。如果某些代码出错，你可以仅仅尝试把他掩盖起来。没有error，就没有问题，对吧?不过，对我来说，让问题看不见和解决问题不一样。“接受”错误很容易导致其他意想不到的副作用。我不想在将来的某个时候不得不面对它们。
- 因为我调查了是否有其他方法来解决相同的问题，而不仅仅是报告的复制步骤。一组复制步骤可以很容易地使错误看起来在一个地方，而实际上它可能是更深的。找到问题的确切原因，并查看所有实现原因的方法，可以提供有价值的见解。比如代码实际是如何使用的，哪些地方可能存在其他可能需要解决的问题，或者它可能显示代码中的不一致性，这意味着错误是在一个代码路径中导致的(或处理的)，而不是在另一个代码路径中。
- 因为我花了时间验证代码的其他部分是否可能受到类似的影响。如果一个错误导致了这个bug，那么同样的错误也可能在代码库的其他地方发生。现在是检查的好时机。
- 因为当我发现了问题的原因后，我就开始寻找最简单的方法来解决问题，同时将带来副作用的风险降到最低。我不想要最快的解决办法。我想要一个不太可能在将来引起混乱或其他问题的修复。
- 由于我对修正进行了彻底的测试，并验证了它解决了所有受影响的不同代码路径的问题。我不想依靠别人来检验我所做的是正确的。我不希望在将来发现错误，并且当我在心里继续前进时，不得不回到这段代码。上下文切换既昂贵又令人沮丧。我希望尽可能避免让一个专门的测试人员再次查看“相同的”更改。
我不喜欢修bug。一个原因是我感觉他们是以前失败的结果，另一个原因是我更喜欢做新事情。
还有什么比修bug更难受的呢?
不得不重复修复相同的bug。
花时间确保遇到任何错误时都已完全修复，这样就不需要多次面对、调查、修复和测试。
