前言

软件开发者路线图看完以后，我开启了接下来的读书之路。一周时间准确的说是6天终于拿下这个山头。废话不多说，这本书是一本从事编程行业一本经典书籍————依然不是一本工具书。它能指导我们如何快速的查找工作中的BUG，并把调试的规格简明扼要外加故事的手段归纳为九条规则。

规则1 理解系统

通过阅读手册或者其它方式理解系统，能使我们避免很多低级的错误，并能对一些问题有一定的处理方式，以及帮助我们能更好的使用系统。此规则又分为以下几个要点:

“什么也比不上直接去的的证据来得重要。”————福尔摩斯，《血色的研究》

制造失败，能使我们观察错误，并专心的排查失败的原因，以及作为是否修复问题的依据。此规则又分为以下几个要点:

亲眼看到底层的失败是非常重要的。如果你猜测失败是如何发生的，那常常会修复一些根不是BUG的问题。这样的修复不仅不会解决问题，而且还会浪费时间和金钱，甚至会破坏其他地方。请记住，不要这样做。————选自本书

此规则又分为以下几个要点:

把问题分割处理，有力于快速定位失败产生的原因，节约时间。有序序列的二分法和顺序查找的效率对比。此规则又分为以下几个要点:

每次修改，只应修复和此次失败相关的部分。对于有代码重构症的人要忍住自己双手去修改BUG，完全遵守此规则很难，不过也有失之东隅收之桑榆。此规则又分为以下几个要点:

对每次测试的条件和结果做记录和分类，有时会起到意想不到的效果。此规则又分为以下几个要点:

“没有什么比一个显而易见的事实更能迷惑人了。”————福尔摩斯，《博斯科姆比溪谷秘案》

显而易见的错误，往往灯下黑。此规则又分为以下几个要点:

一人计短两人技长，我们可以从其他人那边获取新的观点。此规则又分为以下几个要点:

我们的目标是解决BUG，而不是掩盖BUG。不明确BUG产生的原因，巧合的方式BUG被掩盖，BUG依然存在，会被再次触发。此规则又分为以下几个要点: