聲明：本文檔的內容主要來源于書籍《軟件調試修煉之道》作者Paul Butcher，屬于讀書筆記。

不要急于動手！

盡管可以利用各種工具和技術以及軟件自身查找缺陷，但是你最重要的財富是你的智慧

• 一種調試方法

提出假設->設計實驗->假設不成立，重新開始

• 采用不同類型的實驗

進行幾種不同類型的實驗，但是每種實驗必須有一個明確的目標。比如軟件內部運行狀態、軟件的輸入參數、本身編碼邏輯。

• 實驗必須起到驗證的作用

實驗是一種達到目的手段，而不是目的的本身。可以通過實驗用來證明或者推翻假設。

• 一次只做一次修改

設計實驗的規則之一，你每次只能做一個修改。此規則適用于任何修改，令人大跌眼鏡的是，該規則經常被人忽略！雖然一次修改幾個地方看起來省時間，實際上可能得到的只是無效的結果。不要再犯這種錯誤

• 記錄你所做過的調試

在長期調試時，由于做過多種實驗，最后可能忘記自己做了哪些工作，并且在已經得到證明的問題上重復浪費時間，甚至進入死胡同。因此應該做調試記錄，理想情況是每個實驗都都消除一些可能原因，最終找到根本原因。

• 不要忽略任何細節

凡是你不明白的都是潛在的缺陷，因此即使莫名其妙的現象，也往往對發現問題本身非常有價值。弄清楚意想不到的運行狀況可以為你節省大量跟蹤缺陷的時間。

?

相關策略

• 插樁

留意海森堡定律，其本身不應該影響軟件本身的運行，有充足的利用把插樁留到代碼中，從而編寫出自調試軟件。

• 分而治之

也就是二分法，這種方法可以排除很多錯誤的情況，提高效率，但是對減小工作量、提高效率，其并非唯一。

• 利用源碼控制工具

利用源碼控制系統，可以進行有效的回歸跟蹤，它可以有效的告訴你哪個變化導致了這些問題。

• 聚焦差異

問題是否只在特定環境下重現？是否在大量數據輸入情況下重新？

• 向他人學習

許多缺陷只存在于代碼中，因此只有你和合作者才能解決它們。但有時其設計到特定的算法、庫文件等，這種情況可能其他人已經遇到過同樣的問題。

?

陷阱

下面這些是從實戰中來之不易的經驗教訓

• 你做的修改正確嗎

如果修改沒有起到任何效果，那么你并沒有改到點子上。這個陷阱很容易掉進去，又讓人摸不著頭腦，唯一的防御措施是時刻提高警惕。

• 驗證假設

假設會帶來盲點，要了解你正在做什么樣的假設，以及何時對它進行嚴格的檢驗。

• 多重原因

這種情況比較難，最富有成效的解決多原因缺陷的辦法是對問題進行隔離，并找到一個方法來重現缺陷。另外一個方法是先找尋同一區域內其它明顯的缺陷并處理。

• 流沙

實證方法的基礎是，可以一次一次的重現問題，并且每次獲得相同的結果，但是如果沒有了這種確定性，想取得改進就變得極為困難。如果自己遇到了這種問題，那就立即停下來，繼續進行只會陷入更大的麻煩。此時的主要目標是準確的找到是什么在變化，以便你能控制它。

?

思維游戲

調試是艱苦的，有時簡直苦不堪言，別灰心 ，我們都遇到過。這正是軟件開發工作的 一部分，如果你遇到這種情況，下面的技巧會幫你解決這些問題。

• 旁觀調試方法

最有效的一個策略就是向人求助，人多力量大，問題可能很快得到解決。做過這項工作的人都知道，往往只要把問題再解釋一遍的簡單行為也能激發靈感。因此實在找不到人，對著橡皮鴨或者紙人都可以做。

• 角色扮演

在解釋和探討問題時非常有用，特別是涉及到系統之間的數據交互時。

• 換換腦筋

當自己變得沮喪或者超負荷時，休息一會，看問題的角度可能就大不相同。

• 做些改變

當做實證實驗陷入困境之中時，做一點改變是必要的，任何改變都可以，也需不會告訴你任何東西，但是有時會給你帶來驚喜。

• 福爾摩斯原則

當你排除了一切不可能，無論剩下的是什么，他也一定是真相！

• 堅持

在絕望時，請記住總有一個辦法能幫你解決問題，只要有足夠的時間、付出足夠的精力和決心，你一定會解決問題。

?

驗證診斷

我們人類是多才多藝的，其中才能之一就是自欺欺人。考慮到這一點，花時間驗證你的診斷是很值得的。

• 向他人講述你的診斷

他們可能會發現一個缺陷，即使是旁觀者效應也能幫助你達到這樣的效果。

• 檢查源碼原始副本

從一個已知沒有問題的版本重新驗證你編程時的思考。

• 多和他人討論

假設你是錯誤的，知道你犯過什么錯誤了嗎？

總結

以上是生活随笔為你收集整理的读书笔记软件调试之道 ：问题的核心-诊断的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。