Item 44: Verify Your Reasoning by Perturbing the Debugged Program#

隨意修改程式來「看看會發生什麼」常被貶抑為 hacking。但是，以有計劃的方式進行實驗性修改，可以讓你測試假設、深入了解系統和底層平台。這在程式碼或 API 文件品質不佳時特別有價值。

可以透過擾動回答的問題#

• 傳入 null 作為參數會怎樣？
• 變數超過 999 毫秒時程式碼還能正確運作嗎？
• 進入這個函式時如果持有 lock，是否會記錄警告？
• method 的呼叫順序是否與我的問題有關？
• 換用另一個 API 會不會更好？

兩種實驗方向#

修改運算式和值：將 runtime 運算式替換為具體值來測試：

• 傳入正確值給函式，確認故障是否因此消失，來驗證故障確實與該值相關
• 傳入或回傳錯誤值，確認問題是否可歸因於該值
• 將參數設為極端值，讓微小或罕見的問題（如效能衰退）變得明顯且易於觀察

測試替代實作：替換可能有錯的程式碼，看問題是否解決：

• 例如 Windows API 提供超過五種取得字串寬度的方式，如果文字對齊有問題，可以嘗試將 GetTextExtentPoint32 換成 GetTextExtentExPoint
• 如果對函式呼叫順序有疑慮，嘗試替代順序
• 也可以嘗試極端的程式碼簡化（見 Item 46）

重點回顧#

• 在程式碼中手動設定值來辨識正確與錯誤的值
• 如果找不到修正的指引，嘗試替代實作來進行實驗