写点什么

只加两行代码,为什么用了整整两天时间?

发布于: 2020 年 08 月 11 日
只加两行代码,为什么用了整整两天时间?

以下为译文:



“只加两行代码,为什么用了整整两天时间?!”

这个问题看似合理,但其背后隐藏着一些可怕的假设:

  • 代码行数=工作量

  • 代码行数=价值

  • 所有代码行都一样

但这些统统不属实。

有人花了整整两天的时间改好了代码,但为什么我们回头去看的时候会觉得这些改动如此简单? 



  • 因为问题报告对如何再现的描述非常模糊。

我花了好几个小时才成功地重现了问题。有些开发人员会立即去找报告问题的人,在获得更多信息之后再展开调查。而我会尽力使用已提供的信息。我知道有些开发人员不喜欢改bug,因此他们会想法设法逃避这种工作。声称信息量不足是及时甩锅的一个好办法,看起来你像是在努力帮忙,但又无需做任何工作。我知道报告错误非常困难,我非常感谢那些报告错误的人。我会尽可能利用已有信息,实在没办法再去请求报告错误的人提供更多信息,目的是为了表达对他们的感谢。



  • 因为报告的问题与某个功能有关,但我不熟悉这个功能。

我很少使用与这个问题相关的功能,而且我并没有接触过与该功能相关的具体细节。因此,我花费了很长时间来理解如何使用这个功能,以及这个bug与软件交互的具体过程。



  • 因为我花了很长时间调查引发问题的真正原因,而不仅仅是流于表面。

如果某些代码抛出了错误,则你只需把它包装在try..catch语句中即可抑制错误。没有错误,就没有问题。对吗?不好意思,在我看来,把问题藏起来并不等同于解决问题。掩盖错误很容易引发其他意料之外的副作用。我不想留到将来,再与它们打交道。



  • 因为我调查了除了问题报告的步骤之外,是否还有其他方法可以再现这个问题。

通过一组再现步骤可以很容易地让错误浮现,但实际上它可能涉及更深层的问题。找到问题的确切原因,并研究解决问题的所有方法,才能提供有价值的见解。比如代码的实际使用方式,可能其他地方存在有待解决的问题,或者存在代码不一致,导致某个代码路径中引发了错误,而其他路径则不会。

  • 因为我花时间验证了代码的其他部分是否会受到类似问题的影响。

如果某个错误引发了这个bug,那么代码库的其他地方可能也存在相同的错误。我可以借这个机会仔细检查一下。

  • 因为如果我找出了问题的根源,那么就可以寻求最简单的解决方法,同时引入副作用的风险也很小。

我不希望用最快捷的方法修复问题。我希望修复这个问题之后将来不会引起混乱或引发其他问题。



  • 因为我对此次代码变更进行了彻底的测试,并验证了它能够解决所有受影响代码路径下的问题。

我不想依靠他人来测试我做的更改是否正确。我不希望以后等到我完全忘记此次更改之后再发现某个bug,迫使我不得不再次回头看这些代码。来回切换思维费时费力,又令人沮丧。我不希望让专职的测试人员再来检验同一个更改。



我不喜欢改bug的工作,部分原因是因为这种工作让人感觉是我之前的失误造成的。而我不喜欢改bug的另一个原因是,我更喜欢从事新的工作。



问:有什么是比改bug更糟糕的工作呢?

答:反复修复同一个bug。



我愿意花时间确保每次遇到的bug都会被完全修复,这样我就无需再面对这个bug,也无需再花时间调查、修复并测试这个bug。



原文:https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html

译者 | 弯月,责编 | 屠敏





用户头像

公众号:程序员生活志 2020.06.15 加入

专属程序员圈子!

评论

发布
暂无评论
只加两行代码,为什么用了整整两天时间?