明明只是增加了两行代码,为什么却花了整整两天的时间?
这个问题看似合理,但其背后隐藏着一些可怕的假设:
- 代码行数=工作量
- 代码行数=价值
- 所有代码行都一样
但这些统统不属实。
有人花了整整两天的时间改好了代码,但为什么我们回头去看的时候会觉得这些改动如此简单?
(推荐教程:python教程)
因为问题报告对如何再现的描述非常模糊。
我花了好几个小时才成功地重现了问题。有些开发人员会立即去找报告问题的人,在获得更多信息之后再展开调查。而我会尽力使用已提供的信息。我知道有些开发人员不喜欢改bug
,因此他们会想法设法逃避这种工作。声称信息量不足是及时甩锅的一个好办法,看起来你像是在努力帮忙,但又无需做任何工作。我知道报告错误非常困难,我非常感谢那些报告错误的人。我会尽可能利用已有信息,实在没办法再去请求报告错误的人提供更多信息,目的是为了表达对他们的感谢。
因为报告的问题与某个功能有关,但我不熟悉这个功能。
我很少使用与这个问题相关的功能,而且我并没有接触过与该功能相关的具体细节。因此,我花费了很长时间来理解如何使用这个功能,以及这个bug与软件交互的具体过程。
因为我花了很长时间调查引发问题的真正原因,而不仅仅是流于表面。
如果某些代码抛出了错误,则你只需把它包装在try..catch
语句中即可抑制错误。没有错误,就没有问题。对吗?不好意思,在我看来,把问题藏起来并不等同于解决问题。掩盖错误很容易引发其他意料之外的副作用。我不想留到将来,再与它们打交道。
因为我调查了除了问题报告的步骤之外,是否还有其他方法可以再现这个问题。
通过一组再现步骤可以很容易地让错误浮现,但实际上它可能涉及更深层的问题。找到问题的确切原因,并研究解决问题的所有方法,才能提供有价值的见解。比如代码的实际使用方式,可能其他地方存在有待解决的问题,或者存在代码不一致,导致某个代码路径中引发了错误,而其他路径则不会。
因为我花时间验证了代码的其他部分是否会受到类似问题的影响。
如果某个错误引发了这个bug
,那么代码库的其他地方可能也存在相同的错误。我可以借这个机会仔细检查一下。
(推荐课程:JavaScript教程)
因为如果我找出了问题的根源,那么就可以寻求最简单的解决方法,同时引入副作用的风险也很小。
我不希望用最快捷的方法修复问题。我希望修复这个问题之后将来不会引起混乱或引发其他问题。
因为我对此次代码变更进行了彻底的测试,并验证了它能够解决所有受影响代码路径下的问题。
我不想依靠他人来测试我做的更改是否正确。我不希望以后等到我完全忘记此次更改之后再发现某个bug
,迫使我不得不再次回头看这些代码。来回切换思维费时费力,又令人沮丧。我不希望让专职的测试人员再来检验同一个更改。
我不喜欢改bug
的工作,部分原因是因为这种工作让人感觉是我之前的失误造成的。而我不喜欢改bug
的另一个原因是,我更喜欢从事新的工作。
问:有什么是比改bug更糟糕的工作呢? 答:反复修复同一个bug。
我愿意花时间确保每次遇到的bug
都会被完全修复,这样我就无需再面对这个bug
,也无需再花时间调查、修复并测试这个bug
。
以上就是关于为什么有时候明明只增加了一点点代码,却花费了好几天时间的相关介绍了,希望对大家有所帮助。
原文:www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
参考来源:blog.csdn.net/csdnnews/article/details/107903206