不理解程序员的人，往往会做出了一个可怕的假设：
代码行数 = 程序员的努力
代码行数 = 程序员的价值
所有代码都是等效的
我想对这些人说，“别瞎猜了，这都是错的！”
那么，为何看似简单的问题，要花费两天时间才能修复呢？
一、如何复现问题
因为有些人上报问题时，对描述「如何复现问题」写得十分模糊。有时我们要花了几个小时才能复现问题。
收到报告时，一些程序员会立即反馈给上报问题的人，要求他们提供更多的信息，才能研究问题是如何产生的。
而有些程序员不喜欢修复 bug，他们会以信息不完整，无法复现问题为借口，拖延修复进度。
我知道上报问题可能很麻烦，对此我向上报问题的人表示感谢。所以我尽可能在用已知信息来修复 bug，避免给上报的人增加沟通成本。
二、问题和自己开发功能不相关
因为上报的问题与自己负责开发的功能不相关。
有时，与发现的错误相关的功能是我很少使用的，或者不是我负责开发的。这意味着，我要花了更长的时间来理解这个功能是如何实现的，以及它与错误是如何关联的。
三、调查问题真正原因
因为我需要花时间调查问题的真正原因，而不是仅仅看表面上的错误。
通常，如果某些代码抛出错误，则可以将其包装在 try...catch 语句中来避免错误。
如果这样没有错误，就是没有问题吗？不，对我来说，让问题不出现与解决该问题是不同的。
这种方式规避错误很容易导致其他意外的副作用。我不想在将来再与这次问题打交道。
四、是否存在其他方法可以复现相同的问题
因为我需要研究「是否存在其他方法可以复现相同的问题」，而不是按步骤简单地复现问题。
可能有其他方法让我们找到 bug 带来的更深层问题。找到问题的根本原因，并研究解决方法，这才可以避免类似 bug 的产生。
五、验证代码正确性
因为我需要花时间验证代码的其他地方是否会受到影响。
如果某段代码导致了错误，那么在代码库的其他地方也可能发生相同的错误，此时是检查的好时机。
六、寻求简单方法，风险最小
因为当我需要找到问题的根源时，我寻求最简单的方法来解决它，而这种方法将带来最小的副作用风险。
我并不想只以最快的方案来解决问题，我想要的修复方案是在将来不会引起混乱或其他 bug。
七、修复问题后进行测试
因为我对自己所做的更新会进行彻底的测试，并验证所有受影响的路径保证没有问题产生。
我不想依靠别人来测试我所做的更新，因为我不希望之后再发现错误。
再次重新思考之前的方案既耗又费力，所以我会尽可能避免让测试的人再次上报类似的问题。