<讀書筆記>軟體調試之道 ：問題的核心-診斷

標籤：

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

不要急於動手！

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

• 一種調試方法

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

• 採用不同類型的實驗

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

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

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

• 一次只做一次修改

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

• 記錄你所做過的調試

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

• 不要忽略任何細節

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

 

相關策略

• 插樁

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

• 分而治之

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

• 利用源碼控制工具

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

• 聚焦差異

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

• 向他人學習

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

 

陷阱

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

• 你做的修改正確嗎

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

• 驗證假設

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

• 多重原因

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

• 流沙

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

 

思維遊戲

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

• 旁觀調試方法

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

• 角色扮演

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

• 換換腦筋

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

• 做些改變

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

• 福爾摩斯原則

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

• 堅持

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

 

驗證診斷

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

• 向他人講述你的診斷

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

• 檢查源碼原始副本

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

• 多和他人討論

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

<讀書筆記>軟體調試之道 ：問題的核心-診斷