共计 1551 个字符，预计需要花费 4 分钟才能阅读完成。
“你只批改了 2 行代码，为什么须要两天？”
这是程序员最常碰到的质问，外表看这是一个十分正当的问题，但它做了一些不适合的假如：
- 代码行数 = 致力
- 代码行数 = 价值
- 每一行代码价值都雷同
所幸下面这些断言都不是真的。
一个简略的修复，为什么须要花两天工夫？上面列举了一些常见起因。
- 因为如何重现问题的形容很含糊。程序员可能须要花几个小时能力重现 bug。有些开发人员会立刻分割报告 bug 的用户，要求提供更多的信息再进行剖析。有些程序员会试着用提供的信息做尽可能多的事件。我晓得有些开发者不喜爱修复 bug，所以会不惜一切代价来摆脱困境，宣称问题不能重现是一种十分好的回避形式，它让你看起来很想解决问题，但又不须要真的入手。我晓得用户报告 bug 不容易，我也很感激这样做的用户。我想通过在打搅用户询问更多细节之前，尽量多地应用所提供的信息来表白对报告 bug 用户的感激。
- 因为报告的问题与特定性能无关，但程序员不相熟这块性能。这块代码不是他开发的，以前也比拟少接触。如果去修的话，须要破费更长的工夫来先理解这块的流程，以及这个问题怎么呈现。
- 因为破费了工夫去剖析问题的真正起因，而不仅仅是看表面现象。如果一些代码抛出了谬误，你能够间接用 try…catch 语句把它包起来，吞下谬误。这样谬误就不见了，对吧？道歉，对我来说，把问题覆盖不等于解决问题。” 吞下 ” 一个谬误，很容易导致其余意想不到的副作用。我不心愿在将来某个工夫点上不得不来解决它。
- 因为我剖析了是否有其余办法能够重现这个问题，而不仅仅局限于报告提出的重现步骤。某一套重现步骤，容易让谬误呈现在某个中央，但实际上可能是更深层次的起因导致。找到问题的确切起因，并查看所有达到那里的办法，能够失去更有价值的意见。诸如代码理论是如何应用的，其余中央可能也有须要解决的问题，或者它可能因为代码中的应用不统一，这意味着谬误是只在一个代码门路中引起，但不会在另一个呈现。
- 因为我花了工夫来验证代码中是否有其余局部可能受到相似的影响。如果一个谬误导致了 bug，那么同样的谬误也可能在代码库的其余中央产生，当初是查看这个问题的最好机会。
- 因为当我找到问题的起因时，我会寻找最简略的办法来修复，并将引入副作用的危险降到最低。我不想要最疾速的修复办法，我须要一个不会在将来带来凌乱或引入其余问题的修复办法。
- 因为我彻底地测试了这个变更，并验证了受影响的不同代码门路的各种状况。我不想依附他人来测试我批改的代码是否正确。我不想未来某一天又呈现一个 bug，在我曾经淡忘这个的时候，还要回到这段代码中来。上下文切换是低廉的，而且很糟心。让一个专门的测试人员不得不再次查看同一个问题的变更，是我想尽可能防止的。
我不喜爱修 bug，局部起因是会让人感觉是我之前的代码品质不好造成的。我不喜爱修 bug，另一个起因是我更违心去钻研新的货色。
有什么比修 bug 更糟心的事件？那就是重复修复同一个 bug。
我花了更长时间，是须要确保任何一次遇到的 bug 都被 齐全修复，这样就不须要再次去面对这个 bug、再次剖析起因、修复和测试。
举荐浏览
为什么阿里巴巴的程序员成长速度这么快，看完他们的内部资料我懂了
字节跳动总结的设计模式 PDF 火了，完整版凋谢下载
刷 Github 时发现了一本阿里大神的算法笔记！标星 70.5K
程序员 50W 年薪的常识体系与成长路线。
月薪在 30K 以下的 Java 程序员，可能听不懂这个我的项目；
字节跳动总结的设计模式 PDF 火了，完整版凋谢分享
对于【暴力递归算法】你所不晓得的思路
开拓鸿蒙，谁做零碎，聊聊华为微内核
=
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注公众号『Java 斗帝』，不定期分享原创常识。
同时能够期待后续文章 ing????
正文完
