×少量的預防措施要比大量的治療措施有價值的多。。。

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

////////////////////////////////////////////////////////////////////////////////////////////////

////////////////////////////////////////////////////////////////////////////////////////////////