调试——你做错了。10 种技巧帮你找到代码中的 bug

你还记得那些漫长的调试时间吗？你盯着代码库，却不知道到底哪里出了问题？你并不孤单！我想所有开发人员都会时不时地遇到调试难题。所以，在本文中，我将向你介绍我最喜欢的查找代码错误的方法。

目录

• Google 错误信息
• 控制台记录一切
• 使用调试器
• 问题定位
• 创建一些测试
• 分析日志
• 询问朋友
• Git 二分法
• 和一只小黄鸭对话
• 铃鼓舞

Google 错误信息

我不会按实用性对这些技巧进行排序，但谷歌错误信息之所以排在第一位，是有原因的。我认为，如果你连错误信息都看不懂，那么解决问题最简单的方法就是去谷歌搜索错误信息。

大多数情况下，你遇到的错误消息之前已经被别人用谷歌搜索过。我们有很多很棒的平台，比如StackOverflow和GitHub问题，人们在那里互相帮助。所以你不仅可以找到答案，还可以找到避免此类错误的步骤，或者找到导致错误发生的动机。那么，为什么不直接用谷歌搜索错误信息呢？这是最简单的方法。

控制台记录一切

我认为这是在代码库中查找错误的最常用方法之一 -console.log(...)在代码库中添加十分之一的语句，重新运行应用程序并尝试找出问题所在。

我喜欢它，而且在我看来，它对于一些已经局部化到几个类的简单问题来说，是一个正确的解决方案。但是，console.log(...)当你完全不知道发生了什么，也不知道那个令人毛骨悚然的 bug 在哪里时，开始使用 s 进行搜索总是一个坏主意。因为在这种情况下，你可能会错过一些重要的、没有记录下来的内容，而你必须添加控制台日志并多次重新运行应用程序，直到找到失败的原因。

使用调试器

我想这里没什么好说的。所有开发人员都知道什么是调试器以及为什么要使用它。不过，我还是想跟大家分享一下前几天我在办公室和一位同事发生的小讨论。

几天前，我和一位队友讨论了不同的调试方法（这就是我写这篇文章的原因）。我说，查找问题最可靠的方法之一是使用调试器。就这么简单——设置断点，然后执行一些操作，逐步检查代码库，观察应用程序的状态如何变化。还有什么比这更直接的呢？

我的队友提出了一个令人兴奋的想法——使用调试器时，你的分析能力和批判性思维并没有得到锻炼。原因是，使用调试器时，你只是盯着变量窗口，等待错误的行为。而当你不使用调试器深入研究代码库时，你会更加专注，试图理解正在发生的事情，并在每次寻找错误时学到新的东西。

你对调试器和手动调查有什么看法？请在评论区分享你的想法。

问题定位

问题定位方法的核心思想是逐步注释/删除代码，直到找出问题所在。当你编写算法或业务逻辑很长时间而没有编译和执行应用程序时，这种方法尤其有用。

在这种情况下，我总是会犯错。对我来说，最简单的方法就是部分注释代码，并尝试拦截那些消失的错误。然后，重复这个过程，直到找到并修复所有错误。

在某些情况下，当你注释掉一半代码（或删除一半文件）时，使用二分查找法或许是个好主意——然后检查错误是否仍然存在。如果是，则对这一半代码重复同样的操作；如果是，则对另一半代码重复同样的操作。

当然，这仅在特定情况下有效，即当您能够注释/删除代码部分但仍保持其正常工作时。

创建一些测试

好吧，这有点疯狂，但在某些特定情况下它确实有用。在我看来，当某些算法运行不正确，而且过于复杂，无法console.log用代码编写或调试器执行时，它就很有效。

在这种情况下，编写一些测试可能会有用。测试可以帮助你定位算法中的问题。

此后，当错误被定位并且您知道在哪里搜索时，您可以使用另一种方法最终修复它。

分析日志

是的，我知道你讨厌用日志来分析那些 10MB 大小的文本文件。但很多时候，它可以帮你节省几个小时的调试时间。当然，首先必须对日志进行适当的配置。收集到的日志文件必须保存适当的时间。但如果所有条件都满足，那你就很幸运了。它就像控制台日志，但你已经把所有console.log文件都放到了各自的位置，可以直接读取系统上执行的操作。

但不幸的是，这往往只是一场梦......我们并不总是对伐木给予足够的重视。

询问朋友

这很明显，但我们不经常这么做。我想我们办公室里都有经验丰富的同事。或者，我们可以在网上找专家。别害怕，好吗？有人随时准备帮助你！

但是，你需要满足一个要求——在询问别人之前，务必查阅所有可用的信息来源。如果你寻求的是一些简单问题的帮助，而这些内容都写在文档的第二页，那么……好吧，准备好逃跑吧！

Git 二分法

Git 不仅能帮我们保存应用程序的修订历史记录，还提供了一些调试工具。其中之一就是git bisect，它可以对 git 历史记录进行二分查找。如果你有一段时间没维护代码库了，而且自上次维护以来，代码库已经添加了几百条提交，那么这个工具就非常有用了。现在，你遇到了一个 bug，却不知道它是如何以及何时出现的。但你记得，在某个版本中并没有这个 bug 2.0.15。

在这种情况下，git bisect会帮到你。它的思路很简单，你使用 开始调试过程git bisect start，然后，我们需要将当前版本标记为坏版本，因为这里有一个 bug - git bisect bad。之后，我们需要告诉 git 一个可以正常工作的版本：git bisect good 2.0.15。到此为止，设置已完成，我们可以开始搜索了。

git bisect会在bad-good范围的中间选择一个提交并进行检查。然后，我们需要检查这个版本中是否存在该 bug？如果是，则运行git bisect bad；如果不是，则运行。之后，git 会在原来的bad-goodgit bisect good范围内选择一个新提交，重复这个过程，直到找到一个包含该 bug 的提交。

git bisect是一个非常强大的工具，因此完整描述将超出文章的格式，但这里有一个带有良好解释的链接。

和一只小黄鸭对话

这是理解代码运行机制最有效的方法之一。其核心思想是，你需要找一只小黄鸭，把它放在自己面前，然后向它解释你的系统，从基本概念开始，逐行讲解。你可以在这里阅读更多相关信息。我很喜欢这个方法，并且经常使用它，所以，让我给你讲一个简短的故事，讲述我第一次使用它时，甚至没有注意到它。

我刚开始程序员生涯的时候，开发过一个 Android 应用，里面包含相当复杂的手写动画。我一步一步地仔细制作了其中一个动画，一切都很顺利，直到我卡住了。

我有一个不超过150行的动画代码，却找不到它为什么无法正常工作。我反复检查了所有算法，但仍然一无所获。盯着屏幕看了几个小时后，我决定向队友寻求帮助。

我开始详细解释那个动画的工作原理，结果一分钟后就发现了问题！其中一个方法隐式转换float为int🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️🤦‍♂️。当我试图向队友详细解释时，我花了一分钟才明白。

当时我甚至不知道这是橡皮鸭的一种方法。后来我才意识到这一点。但我已经明白它有多厉害了。

铃鼓舞

这是我最喜欢的解决软件问题的方法。你只需要一个铃鼓。你需要在工作站周围跳舞，敲着铃鼓。如果你的铃鼓上印着你正在使用的技术的标志，那就更好了。例如，我就有一个铃鼓，它帮助我解决微服务的问题：

但它对于前端应用程序来说完全没用。

结论

感谢您阅读本文！希望您从本文中学到了一些新东西。最后，我想告诉所有读到最后的人，处理代码库中 Bug 和问题最有效的方法就是编写没有 Bug 的代码。问问你的经理就知道了。😅

无论如何，要专注并坚持。一步一步地进行调查，并运用上面提到的技巧。这样你就能高效地解决所有错误。

在 Twitter 上关注我，了解最新动态，如果您有任何想了解的特定主题，请告诉我！