你只加了两行代码 - 为什么要花两天时间！？_帮朋友写了个代码花了一天时间要不要收费-CSDN博客

本文链接：https://blog.csdn.net/u013643074/article/details/126697434

这篇文章告诉你，如何回答老板的疑问。

扫码关注《Java学研大本营》，加入读者群，分享更多精彩

这似乎是一个合理的问题，但它提出了一些可怕的假设。

代码行数=工作量
代码行数=价值
所有的代码行都是平等的

但是，这些都不是真的。

为什么一个在看了所做的修改后看起来很简单的修复要花两天时间来完成？

因为在报告这个问题时，对如何重现这个问题的描述很模糊。

因为在报告这个问题时，对如何重现这个问题的描述很模糊。我花了好几个小时才找到一个可靠的重现项目。有些开发人员会立即回到报告问题的人那里，要求在调查之前提供更多信息。我尝试着用所提供的信息做尽可能多的事情。我知道有些开发者不喜欢必须修复bug，所以不惜一切代价来摆脱它。声称没有足够的信息是一个很好的方法，可以让人觉得你在努力帮助，但却不必做任何事情。我知道报告错误可能很困难，我很感谢任何报告错误的人。我想通过在要求提供更多细节之前尽可能多地利用所提供的信息来表示对错误报告的感谢。

因为报告的问题与功能有关，我并不熟悉。

因为报告的问题与功能有关，我并不熟悉。它所涉及的功能是我很少使用的，也不是我曾经非常详细地使用过的。这意味着我花了比它更多的时间来了解如何使用它，以及它如何与有问题的软件互动的细微差别。因为我花时间去调查问题的真正原因，而不是只看症状。如果某些代码抛出了一个错误，你可以直接用try...catch语句来包装它，然后抑制错误。没有错误，就没有问题。对吗？对不起，对我来说，让问题不可见并不等同于解决它。"吞下 "一个错误很容易导致其他意外的副作用。我不想在未来的某个时刻不得不处理它们。

因为我调查了是否有其他方法来解决同样的问题，而不仅仅是报告中的再现步骤

因为我调查了是否有其他方法来解决同样的问题，而不仅仅是报告中的再现步骤。一套重现步骤很容易使错误出现在一个地方，而实际上它可能是更深层次的。找到问题的确切原因，并查看所有的方法，可以提供有价值的洞察力。洞察力，如代码的实际使用情况，可能有其他地方可能有（其他）问题需要解决，或者它可能显示代码中的不一致，这意味着一个错误是在一个代码路径中造成的（或处理的），而不是另一个。

因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。

因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。如果一个错误导致了这个错误，那么同样的错误也可能是在代码库的其他地方发生的。现在是检查的好时机。

因为当我找到问题的原因时，我希望找到最简单的方法来修复它，使引入副作用的风险最小。

因为当我找到问题的原因时，我希望找到最简单的方法来修复它，使引入副作用的风险最小。我不想要最快速的修复方法。我想要一个不可能在未来引起混乱或其他问题的修复。

因为我彻底地测试了这个改变，并验证了它解决了所有受影响的不同代码路径的问题。

因为我彻底地测试了这个改变，并验证了它解决了所有受影响的不同代码路径的问题。我不想依靠别人来测试我所做的事情是否正确。我不希望将来发现了一个错误，而当我在精神上已经转移到其他地方时，又不得不回到这个代码。上下文的切换是很昂贵的，也是令人沮丧的。让一个专门的测试人员再次查看 "相同 "的变化是我想尽可能避免的事情。