了解一些技巧助你減少程式碼查錯時間。
在週五的下午三點鐘（為什麼是這個時間？因為事情總會在週五下午三點鐘發生），你收到一條通知，客戶發現你的軟體出現一個錯誤。在有了初步的懷疑後，你聯絡運維，檢視你的軟體紀錄檔以了解發生了什麼，因為你記得收到過紀錄檔已經搬家了的通知。
結果這些紀錄檔被轉移到了你獲取不到的地方，但它們正在匯入到一個網頁應用中——所以到時候你可以用這個漂亮的應用來檢索紀錄檔，但是，這個應用現在還沒完成。這個應用預計會在幾天內完成。我知道，你覺得這完全不切實際。然而並不是，紀錄檔或者紀錄檔訊息似乎經常在錯誤的時間消失不見。在我們開始查錯前，一個忠告：經常檢查你的紀錄檔以確保它們還在你認為它們應該在的地方，並記錄你認為它們應該記的東西。當你不注意的時候，這些東西往往會發生令人驚訝的變化。
好的，你找到了紀錄檔或者嘗試了呼叫運維人員，而客戶確實發現了一個錯誤。甚至你可能認為你已經知道錯誤在哪兒。
你立即開啟你認為可能有問題的檔案並開始查錯。
閱讀程式碼，你甚至可能會想到該閱讀哪些部分。但是在開始搞亂你的程式碼前，請重現導致錯誤的呼叫並把它變成一個測試。這將是一個整合測試，因為你可能還有其他疑問，目前你還不能準確地知道問題在哪兒。
確保這個測試結果是失敗的。這很重要，因為有時你的測試不能重現失敗的呼叫，尤其是你使用了可以混淆測試的 web 或者其他框架。很多東西可能被儲存在變數中，但遺憾的是，只通過觀察測試，你在測試裡呼叫的東西並不總是明顯可見的。當我嘗試著重現這個失敗的呼叫時，我並不是說我要建立一個可以通過的測試，但是，好吧，我確實是建立了一個測試，但我不認為這特別不尋常。
從自己的錯誤中吸取教訓。
現在，你有了一個失敗的測試，或者可能是一個帶有錯誤的測試，那麼是時候解決問題了。但是在你開乾之前，讓我們先檢查下呼叫棧，因為這樣可以更輕鬆地解決問題。
呼叫棧包括你已經啟動但尚未完成地所有任務。因此，比如你正在烤蛋糕並準備往麵糊裡加麵粉，那你的呼叫棧將是：
你已經開始做蛋糕，開始打麵糊，而你現在正在加麵粉。往鍋底抹油不在這個列表中，因為你已經完成了，而做糖霜不在這個列表上因為你還沒開始做。
如果你對呼叫棧不清楚，我強烈建議你使用 Python Tutor，它能幫你在執行程式碼時觀察呼叫棧。
現在，如果你的 Python 程式出現了錯誤， Python 直譯器會幫你列印出當前呼叫棧。這意味著無論那一時刻程式在做什麼，很明顯錯誤發生在呼叫棧的底部。
在棧底你不僅能看到發生了哪個錯誤，而且通常可以在呼叫棧的最後一行發現問題。如果棧底對你沒有幫助，而你的程式碼還沒有經過程式碼分析，那麼使用程式碼分析是非常有用的。我推薦 pylint 或者 flake8。通常情況下，它會指出我一直忽略的錯誤的地方。
如果錯誤看起來很迷惑，你下一步行動可能是用 Google 搜尋它。如果你搜尋的內容不包含你的程式碼的相關資訊，如變數名、檔案等，那你將獲得更好的搜尋結果。如果你使用的是 Python 3（你應該使用它），那麼搜尋內容包含 Python 3 是有幫助的，否則 Python 2 的解決方案往往會佔據大多數。
很久以前，開發者需要在沒有搜尋引擎的幫助下解決問題。那是一段黑暗時光。充分利用你可以使用的所有工具。
不幸的是，有時候問題發生在更早階段，但只有在呼叫棧底部執行的地方才顯現出來。就像當蛋糕沒有膨脹時，忘記加發酵粉的事才被發現。
那就該檢查整個呼叫棧。問題更可能在你的程式碼而不是 Python 標準庫或者第三方包，所以先檢查呼叫棧內你的程式碼。另外，在你的程式碼中放置斷點通常會更容易檢查程式碼。在呼叫棧的程式碼中放置斷點，然後看看周圍是否如你預期。
“但是，瑪麗，”我聽到你說，“如果我有一個呼叫棧，那這些都是有幫助的，但我只有一個失敗的測試。我該從哪裡開始？”
pdb，一個 Python 偵錯程式。
找到你程式碼裡會被這個呼叫命中的地方。你應該能夠找到至少一個這樣的地方。在那裡打上一個 pdb 的斷點。
為什麼不使用 print 語句呢？我曾經依賴於 print 語句。有時候，它們仍然很方便。但當我開始處理複雜的程式碼庫，尤其是有網路呼叫的程式碼庫，print 語句就變得太慢了。我最終在各種地方都加上了 print 語句，但我沒法追蹤它們的位置和原因，而且變得更複雜了。但是主要使用 pdb 還有一個更重要的原因。假設你新增一條 print 語句去發現錯誤問題，而且 print 語句必須早於錯誤出現的地方。但是，看看你放 print 語句的函數，你不知道你的程式碼是怎麼執行到那個位置的。檢視程式碼是尋找呼叫路徑的好方法，但看你以前寫的程式碼是恐怖的。是的，我會用 grep 處理我的程式碼庫以尋找呼叫函數的地方，但這會變得乏味，而且搜尋一個通用函數時並不能縮小搜尋範圍。pdb 就變得非常有用。
你遵循我的建議，打上 pdb 斷點並執行你的測試。然而測試再次失敗，但是沒有任何一個斷點被命中。留著你的斷點，並執行測試套件中一個同這個失敗的測試非常相似的測試。如果你有個不錯的測試套件，你應該能夠找到一個這樣的測試。它會命中了你認為你的失敗測試應該命中的程式碼。執行這個測試，然後當它執行到你的斷點，按下 w 並檢查呼叫棧。如果你不知道如何檢視因為其他呼叫而變得混亂的呼叫棧，那麼在呼叫棧的中間找到屬於你的程式碼，並在堆疊中該程式碼的上一行放置一個斷點。再試一次新的測試。如果仍然沒命中斷點，那麼繼續，向上追蹤呼叫棧並找出你的呼叫在哪裡脫軌了。如果你一直沒有命中斷點，最後到了追蹤的頂部，那麼恭喜你，你發現了問題：你的應用程式名稱拼寫錯了。
沒有經驗，小白，一點都沒有經驗。
如果你仍覺得迷惑，在你稍微改變了一些的地方嘗試新的測試。你能讓新的測試跑起來麼？有什麼是不同的呢？有什麼是相同的呢？嘗試改變一下別的東西。當你有了你的測試，以及可能也還有其它的測試，那就可以開始安全地修改程式碼了，確定是否可以縮小問題範圍。記得從一個新提交開始解決問題，以便於可以輕鬆地復原無效地更改。（這就是版本控制，如果你沒有使用過版本控制，這將會改變你的生活。好吧，可能它只是讓編碼更容易。查閱“版本控制可視指南”，以了解更多。）
儘管如此，當它不再感覺起來像一個有趣的挑戰或者遊戲而開始變得令人沮喪時，你最好的舉措是脫離這個問題。休息一下。我強烈建議你去散步並嘗試考慮別的事情。
當你回來了，如果你沒有突然受到啟發，那就把你關於這個問題所知的每一個點資訊寫下來。這應該包括：
有時這裡有很多資訊，但相信我，從零碎中挖掘資訊是很煩人。所以盡量簡潔，但是要完整。
我經常發現寫下所有資訊能夠啟迪我想到還沒嘗試過的東西。當然，有時候我在點選求助郵件（或表單）的提交按鈕後立刻意識到問題是是什麼。無論如何，當你在寫下所有東西仍一無所獲時，那就試試向他人發郵件求助。首先是你的同事或者其他參與你的專案的人，然後是該專案的郵寄清單。不要害怕向人求助。大多數人都是友善和樂於助人的，我發現在 Python 社群裡尤其如此。
Maria McKinley 已在 PyCascades 2019 演講 程式碼查錯，2 月 23-24，於西雅圖。