调试应该是开发人员除编码以外最常进行的工作了。有时，开发人员们花在调试上的时间跟编码的时间一样长甚至更甚。
计算机经典图书《The Pragmatic Programmer:From Journeyman to Master》（《开发人员修炼之道——从小工到专家》）专门开辟一个节来讲述调试，并将这项技能归入“基本工具”一章中，足见调试的基础性和重要性。以下便是对这本书调试一节的读书笔记以及一些读后感。
调试的目的是为了解决“bug”。书中首先介绍了“bug”的起源——在早期，一位计算机操作者在检查为何机器未按期望运转时，发现有一只bug（虫子）——蛾子——钻入了计算机的继电器并把自己的身体“粘在了日志薄里”。从此以后，bug一词便与计算机、与开发人员如影随形。开发人员们试图写出完美无缺的程序，可现实是：即使是稳定运行了很久的程序，其中依旧有可能有bug。于是乎，找出那些虫子并成为一项重要的工作。在书中，富有经验的开发人员介绍了一些找出bug的一般策略。
1. 心理学：Fix the Problem, Not the Blame 要修正问题，而不是发出指责
在实际工作中，面对自己的bug，开发人员们会有一些不“淡定”的表现：抵赖、推诿、蹩脚的接口、甚至是无动于衷。当发现别人的bug时，开发人员可以花费时间和精力去指责“肇事者”。其实这些都不是正确面对bug的方式。
“Fix The Problem, Not the Blame” bug是自己造成的或是别人造成的，这并不重要。重要的是赶紧去解决它、修复它。
2. 思维方式：Don't Panic 不要恐慌
面对bug，在解决掉它之前，选择恰当的思维方式十分重要。第一，不要恐慌。即使面临最后的期限，或者任何的项目压力，抑或是你的头儿就站在你身后。这时你要做的仅仅是冷静下来，思考导致bug的可能原因。第二，不要说“那不可能”。如果你目睹了bug或者看到bug报告时的第一反应是“那不可能”，你就完全错了。不要把任何一个脑细胞浪费在“不可能发生”这种思路上。第三，小心“近视”。“要抵制只修正你看到的症状的急迫愿望：更有可能的情况是，实际的故障离你正在观察的地方可能还有几步远，并且可能涉及许多其他的相关事物。要总是设法找出问题的根源，而不只是问题的特定表现。”
3. 从何处开始
在设法解决任何问题前，都需要通过观察搜集相关数据及其他信息，以求对bug做到精准的定位。某些情况下，bug是由用户报告的，所以可能需要与用户交谈或观看他们的操作，以获取足够多的细节。
不仅仅需要对程序做严格的边界条件测试，也要测试现实中的最终用户的使用模式。
4. 测试策略
开始修正bug的最佳途径是让其可再现。但我们想要的不是只能通过长长的步骤才能复现bug，我们需要的是能够通过尽量少的步骤甚至一个步骤便能复现bug。
找出问题原因的一种非常简单，却又十分有效的技术就是向他人解释它。
在通常情况下，在大部分项目中，开发人员都需要在一种“混合”环境中查找bug——代码可能是你与团队中其他成员一起编写的、代码与第三方产品（数据库、专用通信、算法等等）交互以及依赖于平台环境（操作系统、系统库、编译器等）。面对这种常见的情况你的第一想法不应该是：bug可能存在于伙伴代码、OS、数据库、或者其他第三方产品中。
当发现某个bug让你吃惊时，必须意识到你之前的一个或更多的假设是错的。Don't assume it, prove it。在面对这种bug时，除了只是修正它之外，也需要确定先前为什么没有找出这个故障，还需要思考代码中是否有其他地方容易受这个bug影响。
等一切解决妥当，还需要考虑如果需要向同事详细解释这个bug，你会怎么说——这并不是为掩盖错误而找借口，而是对解决的bug、对解决bug的过程做一次review。
以上便是读书笔记，我自己对书中的内容做了一些精简和提炼。
我对这篇文章印象最深的内容便是心理学与思维方式两段。这两段中讲到的开发人员面对bug的种种心理与行为都十分常见，当然在我自己身上也发生过且估计会继续发生，所以这两节中提到的克服方法也需要我去反复的review。
对于bug，我觉得难点在于找到它，这往往比定位bug后的修复更花费时间。我的找bug信条是：细心观察，大胆假设，小心求证。细心观察是说当面对bug时，我们要仔细研读有关的信息，譬如bug的现象，用户的操作过程，系统的操作日志，错误日志等。如果发现有程序报错，那需要留心报错信息，包括错误码，错误名，涉及的文件名，行数等。如果没有代码级的报错，那就要关注bug的复现过程，譬如能否稳定复现等。大胆假设是为了应对这样一种情况，bug复现后，在思考bug可能出现的原因时，我们往往会有这样的思维模式：是A模块么？不会吧。之前都正常。是B模块么？也不像，上线前我自测过很多次了。这种有些盲目的自信会阻碍我们对bug的寻找。文章中提到的“认真观察”同样很重要，不要放弃任何一条数据、任何一个细节，反复思考、对比，不要放过任何一个“矛盾点”。有一些矛盾的，当时看似无法解释的现象极有可能就是找到bug的突破口。