这个问题看起来很合理，但是仔细想想，这个问题背后有一些很极端的假设：

• 代码行数 = 工作量

• 代码行数 = 价值

• 所有的代码都是等价的



以上皆错。



那么为什么修复一些看起来很简单的问题需要花两天呢？



1. 因为报告这个问题的人没有描述如何重现

我花了好几个小时才能稳定的重现问题。有些开发者可能会立即去找报告问题的人，在开始调查问题之前试着了解更多信息。有些开发者不喜欢修复bug，所以他们尽量避免这些问题，没有足够的信息就是一个不错的接口。我不是不想帮，是帮不了。我对上报问题的用户很感激，我知道上报错误不是很容易，所以我在联系用户前，会尽量利用已有信息解决问题。



2. 因为报告中提到的功能我不熟悉

这个功能我很少用，也从来没详细使用过。也就是说我要花比平常更久的时间才能理解怎么使用这个功能，还要再花一些时间理解有bug时怎样影响这个功能。



3. 因为我在花时间调查真正的原因，而不是仅仅观察问题的表现

不能头疼医头脚疼医脚，隐藏错误不是解决问题。藏起来一个问题很有可能会导致其他副作用，我不想以后再跟这个bug打交道。



4. 因为我在查产生这个问题的其他方式，而不是仅解决报告中的步骤

按照步骤重现问题很简单，但实际上的问题可能是更深层次的。找到问题的原因，找到重现这个问题的其他步骤，可以洞察到更有价值的内容。例如代码实际上是如何使用的，有没有其他地方存在类似的问题，或者可能会发现同样功能的代码写法不一致，有些代码没有同步复制到另一处？



5. 因为我花时间验证代码中是否有其他部分收到类似的影响

如果一个错误导致了bug，代码库中可能还会有类似的错误。这时候趁热查找最容易发现。



6. 因为我找到原因后，尝试用最简单的方法修复，避免出错风险

我不想用最快的方法，我不想修复一个问题未来产生更多的问题。



7. 因为我对改动做了彻底的测试，并且验证了受影响的所有路径

我不想依靠别人测试我的改动是否正确。我不想放下这段代码后再出现bug。程序员切换 Context 是很昂贵很疲惫的事情。



我不喜欢改bug，部分原因是，这感觉就像是在面对我以前做的错事。还有一个原因是我更喜欢做新东西。



比改bug更糟的事是什么？

多次修复同一个bug。

我更愿意花时间确保一个bug被完全修复了，不需要再一次去面对、去调查、去修复、去测试。



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