你只添加了两行代码，为什么要花两天时间！
这似乎是一个挺合理的问题，但问题是提问的人先做了“可怕”的假设：
代码行数 = 工作量
代码行数 = 价值
每一行代码都是一样的
事实上，以上假设都不成立。
那么，为什么有时一个看似简单的 bug fix，需要两天才能完成？
提 Issue 的人对问题的描述模糊不清，导致工程师难以定位和复现问题。而定位和复现问题往往是最耗时的，有时候问题定位之后，解决方案往往也就呼之欲出了。如果说：“画一个圆圈值 1 美元，知道在哪里画圆圈值 9999 美元”，那么，定位问题就是知道在哪里画 ”圈“，当然也是最耗时的过程。出现问题时，如果能尽可能多的描述产生问题的背景和相关信息，工程师们修起 bug 来就快多了 ~
提的 Issue 和产品的某个功能有关，但可能解决此问题的工程师不太熟悉该功能。这意味着工程师需要花费比预期更长的时间，去了解产品功能在正常情况下和有 bug 的时候，两者之间的差别。
比起暂时救火，工程师需要花更多的时间去探究产生问题的真正原因。如果某些代码抛出一个错误，典型的救火方法就是：在代码块上加个 try ... catch 语句，眼不见为净。对不起，对有追求的工程师来说，让问题隐形不等于解决问题。了解墨菲定律的人应该知道，如果不彻底解决问题，那么该来的还是会来，不多不少。
除了用户在 Issue 中提及的操作会引起该 bug，工程师还需要花时间分析是否还有其他操作会引起一样的问题。好的工程师会通过一个问题，解决潜在的一类问题。
工程师需要花时间来验证：代码库的其他部分是否可能也以类似的方式受到影响？ 如果某种错误导致了一个 bug，那么同样的错误也可能在代码库的其他地方潜伏着。现在就是检查的好时机，不要等以后。谁也不想将来发现一样的 bug 后，又不得不打断当前的工作进程，去找回当时的思绪，重新回到出问题的那段代码中来。好比 CPU 的上下文切换，是一个耗时的操作，如非必要，尽量避免不必要的切换。
找到了问题的根本原因，有了解决方案后，工程师还需要花时间做彻底的测试。好的工程师会自己写各种 Test case, 跑通单元测试，而不是干等专门的测试人员来验证。
比起开发新的功能，工程师们不喜欢修复 bug。修复 bug 费时费力，可能还会让人觉得工作没有做好。而开发新功能，更像是新生事物，未来可期。
还有什么比修复 bug 更糟糕的事情呢 ?
如果有，那就是：反复修复相同的 bug。
所以，要多花些时间，确保在遇到 bug 时尽可能地完全修复。这样就不需要反复面对一样的 bug，反复调查原因，反复救火，反复测试，惶惶不可终日。
以上， Enjoy ~