软件的缺陷以各种各样的方式表现自己，从误解的需求到编码的错误。
没人能写出完美的软件，所以挑事肯定要占用你大量的时间。
调试的心理学
对于许多开发者，调试本身是一个敏感、感性的话题。你可能会遇到抵赖、推诿、蹩脚的借口，甚至于无动于衷，而不是把它当作要解决的难题发起进攻。
要接受事实：调试就是解决问题，要据此发起进攻。
要修正问题，而不是发出指责。bug是你的还是别人的过错，并不真的很重要，重要的是它仍然是你要解决的问题。
调试的思维方式
不要恐慌。不要因为到了工期的最后期限、或有BOSS在看着而感到慌张。
不要有“那不可能”的思维。当目睹bug时思绪不要以“但那不可能发生”来起头。因为很明显，已经发生了。
小心“近视”。要抵制只休整你看到的症状的急迫愿望。根源可能只离你观察到的问题差了几步之遥。要总是设法找到问题的根源，而不只是问题的特定表现。
从何处开始
在开始调试bug之前。应该确保代码是在没有编译警告的前提下。我们例行公事地把编译器警告级别设置的尽可能高。把时间浪费在设法找出编译器能够为你找出的问题上是没有意义的。
“Andy曾经参与过一个大型图形应用的开发。快到发布时，测试人员报告说，每次他们用特定的画笔画线，应用都会崩溃。负责该应用的程序员争辩说：这个画笔没有任何问题；她试过用它绘图，它工作的很好！几天里这样的对话来回进行，大家的情绪急速上升。 最后，我们让他们做到同一个房间里。测试人员选了个画笔工具，从右上角到左下角画了一条线，应用程序炸了。程序员随后像绵羊一样承认，他测试时只测试了从左下角画到右上角的情况，没有暴露出这个bug。” —— 这个故事有两个要点：
1.你也许需要与报告bug的用户面谈，以搜集比最初给你的数据更多的数据。
2.人工合成的测试不能足够地演练应用。必须既强硬地测试边界条件，又测试现实中的最终用户的使用模式，需要系统地进行这样的测试。
测试策略
修正bug的最佳途径是使其可再现。再现bug应该通过简单的途径。一个bug需要很长的步骤才能再现，那么这个bug修正起来也会很困难。
有时候，强迫自己隔离显示出bug的环境，你甚至会洞见它的修正方法。
使你的数据可视化
将程序操作的数据进行可视化处理——3D图、波形图、结构关系图。通过手工或绘图程序去可视化数据。这样可以清晰的反映出程序对数据进行了哪些处理，bug也会相对容易显现出来。DDD领域调试器有一些可视化能力。
跟踪
需要观察程序或数据结构随时间变化的状态。
跟踪语句把小段的调试信息打印到屏幕上或文件中，信息中说明了程序执行流的位置或者是某个需要查看的变量的值等。这种方式很原始，但能发现一些诊断调试器或stack trace不能提供的信息。
跟踪信息应采用规范、一致的格式。有时一个变量的值非期望值时，可以从它的上下文环境开始检查。
橡皮鸭
找到问题的原因更简单且有用的方法是向别人解释它。从对它的讲解过程中发现问题所在。
消除过程
bug有可能存在于OS、编译器、第三方产品、或你的应用代码。当发生bug时应该先从正在开发的应用代码中开始检查。而不是一开始就怀疑是用到的其它产品产生的bug。"select isn't broken"
改进任何和应用代码有关的东西都有可能产生bug。例如：OS、编译器、数据库、第三方软件等更新了版本，这些是在你控制外的东西，但是也可能会让之前正确的代码出现bug；让之前产生的bug自动地得到了修正，但之前为绕开该bug而别写的代码可能会因此而作废。
造成惊讶的要素
有时发生bug，会让你吃惊，感到“那不可能”。是否测试了所有的边界条件？只是假定它是正常的，而没有证明？不要假定，要证明。
遇到让人吃惊的bug时，除了修正它，应考虑先前为何没发现。考虑是否要改进单元测试或其它测试。如果bug是坏数据导致的，应在数据传播的各个层面做好检查，尽早的隔离它。
调试检查列表
- 正在报告的问题是底层bug的直接结果，还是只是症状？
- bug真的在编译器里？在OS里？或者是在你的代码里？
- 如果你向同事详细解释这个问题，你会说什么？
- 如果可以代码通过了单元测试，测试是否足够完整？如果你用该数据运行单元测试，会发生什么？
- 造成这个bug的条件是否存在于系统中的其它任何地方？