你好！在过去的 6 个月里，我一直在和我的朋友Marie一起写一本关于调试的杂志，我们遇到的一个问题是弄清楚如何解释调试时应该采取的正确态度。
我们最终写了一份简短的调试宣言作为 zine 的开头，我对它的结果非常满意。这是图像和文本（有一些额外的解释）
1.检查，不要压扁
当您遇到错误时，自然的本能是尝试尽快修复它。当然，有时这就是您必须要做的——如果错误导致了巨大的生产事故，您必须在深入找出根本原因之前迅速缓解它。
但在我的日常调试中，我发现通常更有效（也更快！）将错误留在原地，找出到底出了什么问题，然后在我了解发生了什么之后修复它。
在没有完全理解发生了什么的情况下尝试修复它或添加解决方法通常只会让我更加困惑。
2.卡住是暂时的
有时我在调试时真的很沮丧，感觉我永远不会取得进展。
我必须提醒自己，我之前已经修复了很多错误，我可能也会修复这个 🙂
3. 不相信任何人，什么也不相信
有时错误来自令人惊讶的来源！例如，我想我发现了一个 Mac 内核错误？我描述了我第一次尝试为 Mac OS 编写程序时，我的程序中有一个由 Mac OS 内核错误引起的错误。
这真的很令人惊讶（通常操作系统没有错！！），但有时甚至通常值得信赖的来源也是错误的。即使是一个流行的库、您的操作系统、官方文档，或者一个非常聪明能干的同事！
4.这可能是你的代码
也就是说，几乎所有时候问题都不是“Mac OS 中存在错误”。我只能代表我自己，但 95% 的时间我的程序出了问题，那是因为我做了一些愚蠢的事情。
因此，在尝试归咎于某些外部源之前，首先在您自己的代码中查找问题很重要。
5. 不要一个人去
通过向同事或朋友寻求调试帮助，我学到了很多东西。我认为这是最有趣的协作方式之一，因为您有一个特定的目标，并且有很多机会可以共享信息，例如：
- 如何使用特定的调试工具（“这里是如何使用 GDB 检查内存……”）
- 计算机是如何工作的（“嘿，你能解释一下 CORS 吗？”）
- 类似的过去错误（“我以前在 X 方面看到过这种中断，也许就是这样？”）
6.总是有原因的
这一种不言自明：有时感觉事情只是无缘无故地随机破坏，但事实并非如此。
即使发生了真正奇怪的事情（例如硬件问题），这仍然是一个原因。
7. 构建你的工具包
我在这个博客上写了很多关于我对调试工具（如 tcpdump、strace 等）的热爱。
要修复错误，您需要有关程序正在做什么的信息，并且有时您需要学习一种新工具才能获得该信息。
此外，有时您需要构建自己更好的工具，例如改进您的测试套件、漂亮的打印等。
8.这可以是一次冒险
如果您经常阅读此博客，您可能知道，我喜欢调试，并且从中学到了很多东西。你会学到新东西！有时你会得到一个伟大的战争故事来讲述！还有什么比这更有趣？
我真的认为调试是对我未来知识的投资——如果有什么东西坏了，通常是因为我的心智模型出了问题，这是一个学习的机会，并确保我下次知道它。
当然，并不是所有的错误都是冒险（我今天调试的那个差一错误肯定不像是有趣的冒险）。但我认为（尽可能多地）反思你的错误并看看你可以从中学到什么是很重要的。