（给程序员的那些事加星标）
英文：Matt Lacey，
翻译：程序员的那些事（id：iProgrammer）
“你只是加了 2 行代码，为什么要用 2 天？”
这是一个看似合理的问题，但做了一些可怕的假设。
代码行数 = 努力
代码行数 = 价值；
所有代码都有同等价值；
上述 3 个假设都有误。
为什么 1 个看起来很简单的修改，要花 2 天时间才能完成？
我们来分析一下原因：
1、因为提交这个问题报告的人，并没有清晰描述如何重现问题。
我花了几个小时才重现了。有些开发者会立即回到报告问题的人那里，要求他提供更多的信息，然后再进行调查。我试着用提供的信息做尽可能多的事情。我知道有些开发者不喜欢必须修复 bug，所以会不惜一切代价来“逃避”。声称没有足够的信息是一种“好方法”，看起来你是想帮忙，但不需要做任何事情。报告错误不是一件容易事，我很感谢所有提错误报告的人。在向他们询问更多细节之前，我会尽量先从已提供的信息来开展工作。
2、因为报告的问题与 XX 功能有关，是我不熟悉的。
问题所涉及的功能，我很少用，也不是我曾仔细用过的。这就意味着我得花了更多的时间去理解这个功能，以及它是如何与整个软件相互作用的。
3、因为我花了时间去调查问题的真正原因，而不仅是看表面症状。（治本，不止治标）
如果一些代码抛出了错误，你可以直接用 try...catch 语句把它包起来，然后抑制错误。没有错误，就没有问题。对吧？抱歉，对我来说，让问题隐形不等于解决问题。隐藏错误容易导致其他意想不到的隐患。我不希望在将来还得返工处理。
4、因为我调查了是否有其他方式可以引发同样的问题，而不仅仅是重现报告的步骤。
重现步骤是很容易让复现错误，而实际上可能是更深层次的错误原因。找到问题的确切原因，并查看所有引发问题的方法，更能提供有价值的见解。比如代码实际是如何使用的，哪些地方可能有需要解决的问题，或者反映出代码不一致，这意味着错误是在一个代码路径 A 中导致的(或处理的)，而不是在路径 B 中。
5、因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。
如果一个错误导致了 Bug，那么代码库的其他地方发生也可能有同样的错误。现在是检查的好时机。
6、因为我发现问题原因后，我就开始寻找最简单的方法来解决问题，同时将带来副作用的风险降到最低。
我不想要最快速的修复方法。我想要一个未来不会造成混乱或其他问题的修复方法。
7、因为我做了更彻底的测试，并验证了它解决了所有受影响的不同代码路径的问题。
我不想依靠别人来检验我所做的是正确的。我不希望在将来发现错误，不得不回到这段代码。场景切换既代价昂贵又令人沮丧。我希望尽可能避免让专职的测试人员再次查看“相同的”更改。
我不喜欢必须修复 bug。部分原因是 Bug 会让人觉得是我之前的失败造成的。另一个原因是我更愿意去研究新的东西。
还有什么比修 bug 更惨的呢？
就是反复修同一个 bug。
我花时间确保任何一次遇到的 bug 都能完全修复，这样就不需要不止一次的面对、调查、修复和测试。
- EOF -
推荐阅读 点击标题可跳转
关注「程序员的那些事」加星标，不错过圈内事
好文章，我在看❤️
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
