本文简短的介绍了为什么一个小小的 Bug，可能会修复好几天。你看到的可能只是一个小问题，解决问题的人可能看到及考虑得更多。
阅读这篇文章，非技术人员可以了解一个看似简单的 Bug 的修复背后需要做些什么，技术人员可以在别人 BB 「一个小修复要花几天？」的时候丢他脸上。下面正文开始——
这看似是一个合理的问题，但它做了一些可怕的假设：
- 代码行数=工作量
- 代码行数=价值
- 每一行代码都是相等的
这些都不是真的。
为什么一个看起来很简单的修复需要花两天的时间来完成？
-
因为对如何重现问题的描述很模糊。 我花了几个小时才得到一个可靠的问题重现。有些开发人员会立即回到报告问题的人那里，要求提供更多的信息，然后再进行调查。而我试着用提供的信息做尽可能多的事情。我知道有些开发者不喜欢修复 Bug，所以会不惜一切代价来摆脱它。一种很好的方式就是声称没有足够的信息，这让你看起来很想帮忙，但实际不需要做任何事情。我知道报告错误是很难的，我很感谢任何这样做的人。我想对错误报告表示感谢，在询问更多细节之前，尽量用提供的信息来做。
-
因为报告的问题与功能有关，我不熟悉。 它所要做的功能是我很少使用的，也不是我曾经很详细地使用过的功能。这意味着我花了比它可能更长的时间来了解如何使用它，以及它如何与软件互动的细微差别与错误。
-
因为我不仅仅是看表面，而是花了时间去调查问题的真正原因。如果一些代码抛出了错误，你可以直接用 try...catch 语句把它包起来，然后禁止错误。没有错误，就没有问题，对吧？抱歉，对我来说，让问题隐形不等于解决问题。「吞下」一个错误很容易导致其他意想不到的副作用。我不希望在未来的某一个点上不得不处理它们。
-
因为我调查了是否有其他方法可以解决同样的问题，而不仅仅是报告的再现步骤。一套再现步骤很容易让错误出现在一个地方，而实际上可能是更深层次的错误。找到问题的本质原因，并查看所有到达那里的方法，可以提供有价值的见解。如代码实际如何使用，可能存在其他可能的地方且可能需要解决这个问题，或者可能显示代码中的不一致，这意味着错误是在一个代码路径中而不是在另一个代码路径中导致的。
-
因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。如果一个错误导致了 Bug，那么同样的错误也可能在代码库的其他地方发生。现在是检查的好时机。
-
因为当我找到问题的原因时，我就会寻找最简单的方法来修复它，将引入副作用的风险降到最低。我不想要最快速的修复方法。我想要一个不可能在未来造成混乱或其他问题的修复方法。
-
因为我彻底地测试了这个变化，并验证了它能解决所有受影响的不同代码路径的问题。我不想依靠别人来测试我所做的事情是否正确。我不想将来发现一个 Bug，让我在心态上有所动摇的时候，还要回到这段代码中来。来回切换的代价是昂贵的，而且令人沮丧。让一个专门的测试人员不得不再次查看 「相同」的变化，是我想尽可能避免的事情。
我不喜欢修复 Bug。部分原因是它们会让人觉得是我之前的失败造成的。我不喜欢修复 Bug 的另一个原因是，我更愿意去研究新的东西。
还有什么比修复 Bug 更糟糕的呢？ 就是不得不反复修复同一个 Bug。 我花时间确保任何一次遇到的 Bug 都能完全修复，这样就不需要不止一次的面对、调查、修复和测试。
#总结：
- 重现花时间
- 熟悉功能花时间
- 了解本质原因花时间
- 举一反三
- 触类旁通
- 寻找简单且小风险方案
- 修复后彻底测试
这里再谈谈自己的想法，写该文的作者，想必是一个将敲代码当作兴趣的人，而且看得出来非常负责任。面对问题，首先不是恼怒而是感谢。然后不是敷衍解决，而是追求问题的本质原因，并尝试举一反三，最后彻底验证自己的修复。如果所有人都是以这种心态来写代码，或许世界上就没那么多垃圾代码了。
原文标题：You've only added two lines - why did that take two days!
来源：https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
作者：Matt Lacey
推荐源：https://wanqu.co/