×少量的预防措施要比大量的治疗措施有价值的多。。。
1.故障从哪里来
为了寻找有缺陷的代码，你必须以这个故障作为起点回溯追踪起因。
1.2从缺陷到故障
通常缺陷是通过以下四个阶段产生的：
1.程序员制造了一个缺陷：所有代码都是程序员写的，写错了。
2.缺陷造成了错误状态的感染：正确的代码段，被错误的代码感染。这时候代码已经不可控。
3.错误状态不断的传播：大多数程序由于不正确的输入而返回错误，当后面的程序访问该状态时，会把错误扩散到后续的程序状态中。（正确情况应该是不会持续传播的，应该会被后续某个模块覆盖或者修正）
4.错误状态引发的故障：外部程序应为感知到了程序的错误状态而故障
×错误只能程序有缺陷，不能证明程序没有缺陷。。。
1.3迷失在时空之中
调试过程可以分解成七个步骤：
1.track the problem
2.reproduce the failure
3.automate and simplify
4.find infection origins
5.focus on likely origins
6.isolate the infection chain
7.correct the defect
在很大程度上，调试就是一个搜索问题，主要是如下两个原则：
×从错误状态中分离出正确状态：如果一个状态是错误的，它可能就是从缺陷到故障的传播链中的一部分；如果一个状态是正确的，他就基本不可能有错误被传播。
×从不相关状态中分离出相关状态：一个变量的值取决于一小部分早期变量的值。因此，只有一部分早期状态是和程序故障相关的。
1.4从故障到修正
×跟踪问题：
×重现故障：
×自动化和简化测试用例：如果是一个复杂的程序，就必须考虑如何自动产生故障（应为希望被重现），以及如何简化输入，得到最小测试用例。
×寻找可能的感染源：如果有自动化测试可以使用排除法，将测试数据中会导致错误的数据找到。
×分离感染源：假设找到是某个测试数据导致错误，现在可以回溯相关系统这个数据出来的模块。
×修正缺陷：
1.5自动调试技术
×简化输入：
×程序片段：
×观察状态：
×监视状态：
×断言：
×反常：
×因果链：
1.6 BUG、失误、还是缺陷
缺陷（defect）：错误的程序代码（代码中的bug）
错误的状态感染（infection）： 错误的程序状态（状态中的bug）
故障（failure）： 可感知程序的错误行为（行为中的bug）
summary：
1.调试程序的七个步骤：跟踪->重现->自动化->发现感染源->重点关注->分离->修正
咱们平常就是自动化和分离的时候会偷懒，老实说，在调试复杂程序的时候，花点时间做自动化和分离是“磨刀不误砍柴功”
////////////////////////////////////////////////////////////////////////////////////////////////
程序员写了一段有缺陷的代码，这是否意味着他犯了过错呢？考虑这些情况：
原始需求没有预测到未来的变化，如：千年虫
只有当程序的某种行为呈现在用户面前是时，才有可能被列入“故障”
在模块化的程序中，故障可能是由两个模块之间的不兼容接口造成的。
分布式系统中，故障可能是由几个组件之间无法预测的交互造成的
。。。。。。
这时候讨论责任已然是一种政治态度
////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////
///// f16的bug
////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////