除錯：自己找出答案

大多數初學者把 bug 當成一道牆。他們撞上去、停下來，然後請別人幫忙翻過去。真正能建立技能的習慣是這樣的：你學會把 bug 當成一個有答案的問題，然後在開口詢問之前自己去找答案。

把錯誤訊息當作證據，不是噪音

Stack trace 經常被人跳過，因為看起來很嚇人。但它們通常會告訴你確切的故障位置和原因。如果你在 Python 中得到 TypeError: 'NoneType' object is not subscriptable，那不是隨機的亂碼——它表示你預期要持有列表或字典的變數其實是 None。行號會告訴你在哪裡。你的工作是從那一行往回追溯，找出值應該在哪裡被設定但沒有被設定。

在網上搜尋任何東西之前先做這件事：先看 traceback 的最後一行，然後往上逐行檢視。最後一行通常會指出實際的例外。上面的行則顯示了呼叫鏈。

刻意重現問題

如果 bug 只在某些時候出現，你還沒真正理解它。在改程式碼之前，試著讓它穩定地重現。一次改一個輸入。它對空列表失敗但對完整列表不會嗎？它只在第二次呼叫函式時失敗，而不是第一次嗎？一個你能隨時重現的 bug 已經解決了 80%，因為現在你可以測試修正是否真的有效，而不是瞎猜。

把問題對半切，再對半切

二分搜尋不只適用於排序陣列——它是在長函式或管道中找出破損程式碼最快的方式。註解掉或繞過邏輯的後半部分，檢查前半部分是否仍然產生 bug。如果是，問題在前半部分。如果不是，問題在後半部分。重複這個過程。這對 200 行的腳本一樣有效，對於你用 print() 或 df.head() 在每一階段檢查輸出的多階段資料管道也同樣有效。

這比隨意改行然後重新執行要好得多，而那是大多數人在壓力下做的事，也浪費遠比節省更多的時間。

當 print() 不再有用時，改用除錯器

print() 陳述式在簡單的情況下還可以，但一旦你開始在多個函式呼叫間追蹤狀態，一個真正的除錯器會節省實際的時間。在 Python 中，在可疑的那一行前面放上 import pdb; pdb.set_trace()，執行腳本，你就會得到一個即時提示符，可以檢查變數、用 n 逐行執行、用 s 進入函式呼叫。VS Code 的內建除錯器做同樣的事，只是用你點擊而不是輸入的中斷點。無論哪種方式，目標都一樣：觀察程式的實際狀態，而不是猜測它可能是什麼。

從專案的其他部分隔離它

如果 bug 發生在大型程式碼庫內，別在大型程式碼庫內除錯。把相關的函式複製到一個新檔案中，加上能觸發同樣故障的假的、最小化輸入。如果 bug 消失了，說明周圍的環境——全域變數、匯入或陳舊的狀態——才是真正的原因，你剛好學到了重要的東西。如果 bug 在隔離狀態下仍然存在，你現在有了一個小的、可分享的、可測試的案例，你離實際的修正也更近了。

根據現實檢查你的假設，不是記憶

除錯時間中有很大一部分花在未經質疑的假設上：