你只修改了2行代码，为何须要两天时间？

时间 2021-05-19

标签 java 程序员算法设计模式 ide 测试 .net 设计 blog 递归栏目 Java 繁體版

原文原文链接

“你只修改了2行代码，为何须要两天？”java

这是程序员最常碰到的质问，表面看这是一个很是合理的问题，但它作了一些不合适的假设：程序员

代码行数 = 努力
代码行数 = 价值
每一行代码价值都相同

所幸上面这些断言都不是真的。算法

一个简单的修复，为何须要花两天时间？下面列举了一些常见缘由。设计模式

由于如何重现问题的描述很模糊。程序员可能须要花几个小时才能重现 bug。有些开发人员会当即联系报告 bug 的用户，要求提供更多的信息再进行分析。有些程序员会试着用提供的信息作尽量多的事情。我知道有些开发者不喜欢修复 bug，因此会不惜一切代价来摆脱困境，声称问题不能重现是一种很是好的逃避方式，它让你看起来很想解决问题，但又不须要真的动手。我知道用户报告 bug 不容易，我也很感谢这样作的用户。我想经过在打扰用户询问更多细节以前，尽可能多地使用所提供的信息来表达对报告 bug 用户的感谢。
由于报告的问题与特定功能有关，但程序员不熟悉这块功能。这块代码不是他开发的，之前也比较少接触。若是去修的话，须要花费更长的时间来先了解这块的流程，以及这个问题怎么出现。
由于花费了时间去分析问题的真正缘由，而不只仅是看表面现象。若是一些代码抛出了错误，你能够直接用 try...catch 语句把它包起来，吞下错误。这样错误就不见了，对吧？抱歉，对我来讲，把问题掩盖不等于解决问题。"吞下"一个错误，很容易致使其余意想不到的反作用。我不但愿在将来某个时间点上不得不来处理它。
由于我分析了是否有其余方法能够重现这个问题，而不只仅局限于报告提出的重现步骤。某一套重现步骤，容易让错误出如今某个地方，但实际上多是更深层次的缘由致使。找到问题的确切缘由，并查看全部到达那里的方法，能够获得更有价值的意见。诸如代码实际是如何使用的，其余地方可能也有须要解决的问题，或者它可能因为代码中的使用不一致，这意味着错误是只在一个代码路径中引发，但不会在另外一个出现。
由于我花了时间来验证代码中是否有其余部分可能受到相似的影响。若是一个错误致使了 bug，那么一样的错误也可能在代码库的其余地方发生，如今是检查这个问题的最好时机。
由于当我找到问题的缘由时，我会寻找最简单的方法来修复，并将引入反作用的风险降到最低。我不想要最快速的修复方法，我须要一个不会在将来带来混乱或引入其余问题的修复方法。
由于我完全地测试了这个变动，并验证了受影响的不一样代码路径的各类状况。我不想依靠别人来测试我修改的代码是否正确。我不想未来某一天又出现一个 bug，在我已经淡忘这个的时候，还要回到这段代码中来。上下文切换是昂贵的，并且很糟心。让一个专门的测试人员不得再也不次查看同一个问题的变动，是我想尽量避免的。

我不喜欢修 bug，部分缘由是会让人以为是我以前的代码质量很差形成的。我不喜欢修 bug，另外一个缘由是我更愿意去研究新的东西。ide

有什么比修 bug 更糟心的事情？那就是反复修复同一个 bug。测试

我花了更长时间，是须要确保任何一次遇到的 bug 都被彻底修复，这样就不须要再次去面对这个 bug、再次分析缘由、修复和测试。.net

看完三件事❤️

若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：

点赞，转发，有大家的『点赞和评论』，才是我创造的动力。

关注公众号『 Java斗帝』，不按期分享原创知识。

同时能够期待后续文章ing🚀

你只修改了2行代码，为何须要两天时间？

推荐阅读

看完三件事❤️