原文 | https://www.mrlacey.com

作者 | Matt Lacey

我花了两天时间，写了两行代码。

对于真正的程序员来看，这可能是一个合理的事情，但背后不理解程序员的人，往往会做出了一个可怕的假设：

• 代码行数 = 程序员的努力

• 代码行数 = 程序员的价值

• 所有代码都是等效的

我想对这些人说，“别瞎猜了，这都是错的！”

那么，为何看似简单的问题，要花费两天时间才能修复呢？

1

因为有些人上报问题时，对描述「如何复现问题」写得十分模糊。有时我们要花了几个小时才能复现问题。收到报告时，一些程序员会立即反馈给上报问题的人，要求他们提供更多的信息，才能研究问题是如何产生的。

而有些程序员不喜欢修复 bug，他们会以信息不完整，无法复现问题为借口，拖延修复进度。

我知道上报问题可能很麻烦，对此我向上报问题的人表示感谢。所以我尽可能在用已知信息来修复 bug，避免给上报的人增加沟通成本。

2

因为上报的问题与自己负责开发的功能不相关。

有时，与发现的错误相关的功能是我很少使用的，或者不是我负责开发的。这意味着，我要花了更长的时间来理解这个功能是如何实现的，以及它与错误是如何关联的。

3

因为我需要花时间调查问题的真正原因，而不是仅仅看表面上的错误。

通常，如果某些代码抛出错误，则可以将其包装在 try...catch 语句中来避免错误。

如果这样没有错误，就是没有问题吗？不，对我来说，让问题不出现与解决该问题是不同的。这种方式规避错误很容易导致其他意外的副作用。我不想在将来再与这次问题打交道。

4

因为我需要研究「是否存在其他方法可以复现相同的问题」，而不是按步骤简单地复现问题。

可能有其他方法让我们找到 bug 带来的更深层问题。找到问题的根本原因，并研究解决方法，这才可以避免类似 bug 的产生。

5

因为我需要花时间验证代码的其他地方是否会受到影响。

如果某段代码导致了错误，那么在代码库的其他地方也可能发生相同的错误，此时是检查的好时机。

6

因为当我需要找到问题的根源时，我寻求最简单的方法来解决它，而这种方法将带来最小的副作用风险。

我并不想只以最快的方案来解决问题，我想要的修复方案是在将来不会引起混乱或其他 bug。

7

因为我对自己所做的更新会进行彻底的测试，并验证所有受影响的路径保证没有问题产生。

我不想依靠别人来测试我所做的更新，因为我不希望之后再发现错误。再次重新思考之前的方案既耗时又费力，所以我会尽可能避免让测试的人再次上报类似的问题。

其实我不喜欢修复 bug。其中一个原因是，这些 bug 是自己必须要面对的错误。另一个原因是，我更喜欢在新功能的开发上，有哪个程序员会喜欢把时间耗在修复 bug 上呢？

问：如果想逼疯一个程序员，还有什么比让他马上修复一个 bug 更有效的呢？

答：让他反复修复同一个 bug。

我愿意会花时间确保任何一个 bug 在出现后会被完全修复，这样就不需要再一遍一遍地检查、修复和测试了。

同样也避免和和领导、产品经理、测试人员之间的相互伤害了。

程序员改善代码质量的 101 个方法

本书介绍了软件开发领域 101 个重要的编程原则，涉及编程中的永恒真理，指导方针，编程思想，程序员的视角、习惯和工具，以及编程的反模式等内容。

书中以“这个原则是什么”“为什么要遵循这个原则”“具体应该怎么做”为中心，对各个原则进行介绍，简明扼要，通俗易懂。这些原则凝聚了前人的智慧，经过了历史的考验，是指导程序员改善代码、进一步提升编程能力的实用指南。

本书适合各层次软件开发人员和项目管理人员阅读，也可作为高等院校计算机相关专业师生的参考读物。

图灵官方小店

享受正版低价折扣