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

Photo from   Pexels

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

• 代码行数 = 工作量
  

• 代码行数 = 价值

• 每一行代码都是一样的

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

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

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

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

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

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

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

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

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

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

如果有，那就是：反复修复相同的 bug 。

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

以上， Enjoy ~