5.1.1. 打印调试¶

打印调试（print debugging）是我经常用来帮助自己追踪代码错误的方法。其主要思想很简单：在你程序的每个阶段，尽可能多地打印出信息。通过这样做，我们就能在程序的每个阶段看到数据是如何变化的，以及它是否按照我们计划的方式变化。需要注意的是，这种方法也有一些缺点。

1. 它需要在代码中布满打印语句，这意味着这些语句以后还得被移除

2. 根据程序打印的数据量的多少，程序可能会被海量信息淹没，以至于难以从中获得任何有意义的结论

5.1.2. 橡皮鸭调试¶

橡皮鸭调试（Rubber Duck Debugging）在编程行业中已经流行起来。橡皮鸭调试的重点是让程序员仔细检查自己的每一行代码，不要只是假设它做了自己期望的事情，还要解释它是如何工作的。要进行橡皮鸭调试，程序员应该拿一只橡皮鸭玩具（或任何其他可以充当听众的东西），然后逐行阅读自己的代码，就像向一个毫无编程经验的普通人那样，把代码解释给鸭子听。不过，橡皮鸭调试的效果取决于你在其中投入了多少思考。使用这种技巧时，一定要详尽地解释，并考虑每一种可能的情况。橡皮鸭调试的示例，请阅读 这篇博客。

5.1.3. 围栏调试¶

想象阿拉斯加只有一只狼。你会怎样找到它？一种方法就是在阿拉斯加中间设一道围栏，然后等待那只狼"嚎叫"。当你知道狼在哪一半之后，就把那一半再一分为二，继续等待。不断重复，直到你找到那只狼为止。

这就是围栏调试（Wolf Fence Debugging）的基础。设法找出错误发生的位置，反复排除区域，直到找到引发问题的那个方法，进而定位到出问题的代码行。这种方法在与异常（Exception）配合使用时尤其有用，因为栈跟踪可以显示出最终导致实际抛出该异常所调用的每一行代码。

5.1.4. 打印调试与源码调试¶

在源码调试和基于打印的调试之间做出选择，有时会很困难。每种方法都各有利弊。一般来说，基于打印的调试可以方便地为你提供少量有针对性且明确的信息（也就是说，你知道自己想要什么）。而源码级调试则便于探索你的代码正在发生什么。