“你只是加了 2 行代码，为什么要用 2 天？”

这是一个看似合理的问题，但做了一些可怕的假设。

1. 
   
2. 代码行数 = 努力
   
3. 代码行数 = 价值；
   
4. 所有代码都有同等价值；

复制代码

上述 3 个假设都有误。

为什么 1 个看起来很简单的修改，要花 2  天时间才能完成？

我们来分析一下原因：

1、因为提交这个问题报告的人，并没有清晰描述如何重现问题。

我花了几个小时才重现了。有些开发者会立即回到报告问题的人那里，要求他提供更多的信息，然后再进行调查。我试着用提供的信息做尽可能多的事情。我知道有些开发者不喜欢必须修复 bug，所以会不惜一切代价来“逃避”。声称没有足够的信息是一种“好方法”，看起来你是想帮忙，但不需要做任何事情。报告错误不是一件容易事，我很感谢所有提错误报告的人。在向他们询问更多细节之前，我会尽量先从已提供的信息来开展工作。

2、因为报告的问题与 XX 功能有关，是我不熟悉的。

问题所涉及的功能，我很少用，也不是我曾仔细用过的。这就意味着我得花了更多的时间去理解这个功能，以及它是如何与整个软件相互作用的。

3、因为我花了时间去调查问题的真正原因，而不仅是看表面症状。（治本，不止治标）

如果一些代码抛出了错误，你可以直接用 try...catch 语句把它包起来，然后抑制错误。没有错误，就没有问题。对吧？抱歉，对我来说，让问题隐形不等于解决问题。隐藏错误容易导致其他意想不到的隐患。我不希望在将来还得返工处理。

4、因为我调查了是否有其他方式可以引发同样的问题，而不仅仅是重现报告的步骤。

重现步骤是很容易让复现错误，而实际上可能是更深层次的错误原因。找到问题的确切原因，并查看所有引发问题的方法，更能提供有价值的见解。比如代码实际是如何使用的，哪些地方可能有需要解决的问题，或者反映出代码不一致，这意味着错误是在一个代码路径 A 中导致的(或处理的)，而不是在路径 B 中。

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

如果一个错误导致了 Bug，那么代码库的其他地方发生也可能有同样的错误。现在是检查的好时机。

6、因为我发现问题原因后，我就开始寻找最简单的方法来解决问题，同时将带来副作用的风险降到最低。

我不想要最快速的修复方法。我想要一个未来不会造成混乱或其他问题的修复方法。

7、因为我做了更彻底的测试，并验证了它解决了所有受影响的不同代码路径的问题。

我不想依靠别人来检验我所做的是正确的。我不希望在将来发现错误，不得不回到这段代码。场景切换既代价昂贵又令人沮丧。我希望尽可能避免让专职的测试人员再次查看“相同的”更改。

我不喜欢必须修复 bug。部分原因是 Bug 会让人觉得是我之前的失败造成的。另一个原因是我更愿意去研究新的东西。

还有什么比修 bug 更惨的呢？

就是反复修同一个 bug。

我花时间确保任何一次遇到的 bug 都能完全修复，这样就不需要不止一次的面对、调查、修复和测试。