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