作者 | Matt Lacey

译者 | 弯月，责编 | 屠敏

头图 | CSDN 下载自东方 IC

出品 | CSDN（ID：CSDNnews）

以下为译文：

“只加两行代码，为什么用了整整两天时间？！”

这个问题看似合理，但其背后隐藏着一些可怕的假设：

• 代码行数=工作量

• 代码行数=价值

• 所有代码行都一样

但这些统统不属实。

有人花了整整两天的时间改好了代码，但为什么我们回头去看的时候会觉得这些改动如此简单？

• 因为问题报告对如何再现的描述非常模糊。

我花了好几个小时才成功地重现了问题。有些开发人员会立即去找报告问题的人，在获得更多信息之后再展开调查。而我会尽力使用已提供的信息。我知道有些开发人员不喜欢改bug，因此他们会想法设法逃避这种工作。声称信息量不足是及时甩锅的一个好办法，看起来你像是在努力帮忙，但又无需做任何工作。我知道报告错误非常困难，我非常感谢那些报告错误的人。我会尽可能利用已有信息，实在没办法再去请求报告错误的人提供更多信息，目的是为了表达对他们的感谢。

• 因为报告的问题与某个功能有关，但我不熟悉这个功能。

我很少使用与这个问题相关的功能，而且我并没有接触过与该功能相关的具体细节。因此，我花费了很长时间来理解如何使用这个功能，以及这个bug与软件交互的具体过程。

• 因为我花了很长时间调查引发问题的真正原因，而不仅仅是流于表面。

如果某些代码抛出了错误，则你只需把它包装在try..catch语句中即可抑制错误。没有错误，就没有问题。对吗？不好意思，在我看来，把问题藏起来并不等同于解决问题。掩盖错误很容易引发其他意料之外的副作用。我不想留到将来，再与它们打交道。

• 因为我调查了除了问题报告的步骤之外，是否还有其他方法可以再现这个问题。

通过一组再现步骤可以很容易地让错误浮现，但实际上它可能涉及更深层的问题。找到问题的确切原因，并研究解决问题的所有方法，才能提供有价值的见解。比如代码的实际使用方式，可能其他地方存在有待解决的问题，或者存在代码不一致，导致某个代码路径中引发了错误，而其他路径则不会。

• 因为我花时间验证了代码的其他部分是否会受到类似问题的影响。

如果某个错误引发了这个bug，那么代码库的其他地方可能也存在相同的错误。我可以借这个机会仔细检查一下。

• 因为如果我找出了问题的根源，那么就可以寻求最简单的解决方法，同时引入副作用的风险也很小。

我不希望用最快捷的方法修复问题。我希望修复这个问题之后将来不会引起混乱或引发其他问题。

• 因为我对此次代码变更进行了彻底的测试，并验证了它能够解决所有受影响代码路径下的问题。

我不想依靠他人来测试我做的更改是否正确。我不希望以后等到我完全忘记此次更改之后再发现某个bug，迫使我不得不再次回头看这些代码。来回切换思维费时费力，又令人沮丧。我不希望让专职的测试人员再来检验同一个更改。

我不喜欢改bug的工作，部分原因是因为这种工作让人感觉是我之前的失误造成的。而我不喜欢改bug的另一个原因是，我更喜欢从事新的工作。

问：有什么是比改bug更糟糕的工作呢？

答：反复修复同一个bug。

我愿意花时间确保每次遇到的bug都会被完全修复，这样我就无需再面对这个bug，也无需再花时间调查、修复并测试这个bug。

原文：https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html

本文为 CSDN 翻译，转载请注明来源出处。

更多精彩推荐

☞两万字长文读懂 Java 集合！
☞V神演讲干货全送上！关于以太坊2.0，你想知道的都在这里！
☞大写“惨”？三次改变世界、却被无情出局的程序员大牛！
☞我还没考试，算法就说我的物理一定挂科
☞中台架构详解（上） | 大咖说中台
☞Eth2 验证者快速启动器发布，还有什么惊喜是我们不知道的？
点分享点点赞点在看