你只添加了两行代码,为什么要花两天时间

Photo from   Pexels

这似乎是一个挺合理的问题,但问题是提问的人先做了“可怕”的假设:

  • 代码行数 = 工作量

  • 代码行数 = 价值

  • 每一行代码都是一样的

事实上,以上假设都不成立。

那么,为什么有时一个看似简单的 bug fix ,需要两天才能完成?

  • Issue 的人对问题的描述模糊不清,导致工程师难以定位和复现问题。 而定位和复现问题往往是最耗时的, 有时候 问题定位之后,解决方案往往也就呼之欲出了。如果说:“画一个圆圈值  美元,知道在哪里画圆圈值 9999 美元”,那么,定位问题就是知道在哪里画 ”圈“,当然也是最耗时的过程。出现问题时,如果能尽可能多的描述产生问题的背景和相关信息,工程师们修起  bug  来就快多了 ~

  • 提的  Issue   和产品的某个功能有关,但可能解决此问题的工程师不太熟悉该功能。 这意味着工程师需要花费比预期更长的时间,去了解 产品功能 在正常情况下和有  bug 的时候,两者之间的差别

  • 比起暂时救火,工程师需要花更多的时间去探究产生问题的真正原因。 如果某些代码抛出一个错误,典型的救火方法就是:在代码块上加个  try … catch 语句,眼不见为净。对不起,对有追求的工程师来说,让问题隐形不等于解决问题。了解墨菲定律的人应该知道,如果不彻底解决问题,那么该来的还是会来,不多不少。

  • 除了用户在 Issue  中提及 的操作会引起该 bug ,工程师还需要花时间分析是否还有其他操作会引起一样的问题。 好的工程师会 过一个问题,解 决潜在的一类问题。

  • 师需要 时间 码库 他部分 是否 可能也 类似的方式受到影响 果某种错误 导致了一个  bug 同样的错误也可 能在代码库的其他地方潜伏着。 现在就是 检查的好时机,不要等以后。 谁也不想将来发现一样的 bug 后,又不得不打断当前的工作进程,去找回当时的思绪,重新回 到出问题的那段代码中来。 好比 CPU 的上下文切换,是一个耗时的操作,如非必要,尽量避免不必要的切换。

  • 找到了问题的根本原因,有了解决方案后,工程师还需要花时间做彻底的测试 。好的工程师会自己写各种 Test case , 跑通单元测试,而不是干等专门的 测试人员 来验证。

比起开发新的功能,工程师们不喜欢修复  bug 。修复 bug 费时费力,可能还会让人觉得工作没有做好。而开发新功能,更像是新生事物,未来可期

还有什么比修复 bug 更糟糕的事情呢 ?

如果有,那就是:反复修复相同的 bug

所以,要多 花些 时间, 确保在遇到  bug 时尽可能地完全修复。这样就不需要反复面 对一样的 bug ,反复调查原因,反复救火,反复测试,惶惶不可终日。

以上, Enjoy ~

公众账号
我还没有学会写个人说明!
上一篇

JetBrains出品,一款好用到爆的数据库工具,惊艳到了!!!

下一篇

梁朝伟刘德华久违同框 再与《无间道》编剧合作

你也可能喜欢

评论已经被关闭。

插入图片