Python學習七步走

結果這些日志被轉移到了你獲取不到的地方，但它們正在導入到一個網(wǎng)頁應用中——所以到時候你可以用這個漂亮的應用來檢索日志，但是，這個應用現(xiàn)在還沒完成。這個應用預計會在幾天內完成。我知道，你覺得這完全不切實際。然而并不是，日志或者日志消息似乎經(jīng)常在錯誤的時間消失不見。在我們開始查錯前，一個忠告：經(jīng)常檢查你的日志以確保它們還在你認為它們應該在的地方，并記錄你認為它們應該記的東西。當你不注意的時候，這些東西往往會發(fā)生令人驚訝的變化。

好的，你找到了日志或者嘗試了呼叫運維人員，而客戶確實發(fā)現(xiàn)了一個錯誤。甚至你可能認為你已經(jīng)知道錯誤在哪兒。

你立即打開你認為可能有問題的文件并開始查錯。

閱讀代碼，你甚至可能會想到該閱讀哪些部分。但是在開始搞亂你的代碼前，請重現(xiàn)導致錯誤的調用并把它變成一個測試。這將是一個集成測試，因為你可能還有其他疑問，目前你還不能準確地知道問題在哪兒。

確保這個測試結果是失敗的。這很重要，因為有時你的測試不能重現(xiàn)失敗的調用，尤其是你使用了可以混淆測試的 web 或者其他框架。很多東西可能被存儲在變量中，但遺憾的是，只通過觀察測試，你在測試里調用的東西并不總是明顯可見的。當我嘗試著重現(xiàn)這個失敗的調用時，我并不是說我要創(chuàng)建一個可以通過的測試，但是，好吧，我確實是創(chuàng)建了一個測試，但我不認為這特別不尋常。從自己的錯誤中吸取教訓。

現(xiàn)在，你有了一個失敗的測試，或者可能是一個帶有錯誤的測試，那么是時候解決問題了。但是在你開干之前，讓我們先檢查下調用棧，因為這樣可以更輕松地解決問題。

調用棧包括你已經(jīng)啟動但尚未完成地所有任務。因此，比如你正在烤蛋糕并準備往面糊里加面粉，那你的調用棧將是：

做蛋糕
打面糊
加面粉

你已經(jīng)開始做蛋糕，開始打面糊，而你現(xiàn)在正在加面粉。往鍋底抹油不在這個列表中，因為你已經(jīng)完成了，而做糖霜不在這個列表上因為你還沒開始做。

如果你對調用棧不清楚，我強烈建議你使用 Python Tutor，它能幫你在執(zhí)行代碼時觀察調用棧。

現(xiàn)在，如果你的 Python 程序出現(xiàn)了錯誤， Python 解釋器會幫你打印出當前調用棧。這意味著無論那一時刻程序在做什么，很明顯錯誤發(fā)生在調用棧的底部。

在棧底你不僅能看到發(fā)生了哪個錯誤，而且通常可以在調用棧的最后一行發(fā)現(xiàn)問題。如果棧底對你沒有幫助，而你的代碼還沒有經(jīng)過代碼分析，那么使用代碼分析是非常有用的。我推薦 pylint 或者 flake8。通常情況下，它會指出我一直忽略的錯誤的地方。

如果錯誤看起來很迷惑，你下一步行動可能是用 Google 搜索它。如果你搜索的內容不包含你的代碼的相關信息，如變量名、文件等，那你將獲得更好的搜索結果。如果你使用的是 Python 3（你應該使用它），那么搜索內容包含 Python 3 是有幫助的，否則 Python 2 的解決方案往往會占據(jù)大多數(shù)。

很久以前，開發(fā)者需要在沒有搜索引擎的幫助下解決問題。那是一段黑暗時光。充分利用你可以使用的所有工具。

不幸的是，有時候問題發(fā)生在更早階段，但只有在調用棧底部執(zhí)行的地方才顯現(xiàn)出來。就像當?shù)案鉀]有膨脹時，忘記加發(fā)酵粉的事才被發(fā)現(xiàn)。

那就該檢查整個調用棧。問題更可能在你的代碼而不是 Python 標準庫或者第三方包，所以先檢查調用棧內你的代碼。另外，在你的代碼中放置斷點通常會更容易檢查代碼。在調用棧的代碼中放置斷點，然后看看周圍是否如你預期。

“但是，瑪麗，”我聽到你說，“如果我有一個調用棧，那這些都是有幫助的，但我只有一個失敗的測試。我該從哪里開始？”

pdb，一個 Python 調試器。

找到你代碼里會被這個調用命中的地方。你應該能夠找到至少一個這樣的地方。在那里打上一個 pdb 的斷點。

為什么不使用 print 語句呢？我曾經(jīng)依賴于 print 語句。有時候，它們仍然很方便。但當我開始處理復雜的代碼庫，尤其是有網(wǎng)絡調用的代碼庫，print 語句就變得太慢了。我最終在各種地方都加上了 print 語句，但我沒法追蹤它們的位置和原因，而且變得更復雜了。但是主要使用 pdb 還有一個更重要的原因。假設你添加一條 print 語句去發(fā)現(xiàn)錯誤問題，而且 print 語句必須早于錯誤出現(xiàn)的地方。但是，看看你放 print 語句的函數(shù)，你不知道你的代碼是怎么執(zhí)行到那個位置的。查看代碼是尋找調用路徑的好方法，但看你以前寫的代碼是恐怖的。是的，我會用 grep 處理我的代碼庫以尋找調用函數(shù)的地方，但這會變得乏味，而且搜索一個通用函數(shù)時并不能縮小搜索范圍。pdb 就變得非常有用。

你遵循我的建議，打上 pdb 斷點并運行你的測試。然而測試再次失敗，但是沒有任何一個斷點被命中。留著你的斷點，并運行測試套件中一個同這個失敗的測試非常相似的測試。如果你有個不錯的測試套件，你應該能夠找到一個這樣的測試。它會命中了你認為你的失敗測試應該命中的代碼。運行這個測試，然后當它運行到你的斷點，按下 w 并檢查調用棧。如果你不知道如何查看因為其他調用而變得混亂的調用棧，那么在調用棧的中間找到屬于你的代碼，并在堆棧中該代碼的上一行放置一個斷點。再試一次新的測試。如果仍然沒命中斷點，那么繼續(xù)，向上追蹤調用棧并找出你的調用在哪里脫軌了。如果你一直沒有命中斷點，最后到了追蹤的頂部，那么恭喜你，你發(fā)現(xiàn)了問題：你的應用程序名稱拼寫錯了。沒有經(jīng)驗，小白，一點都沒有經(jīng)驗。

如果你仍覺得迷惑，在你稍微改變了一些的地方嘗試新的測試。你能讓新的測試跑起來么？有什么是不同的呢？有什么是相同的呢？嘗試改變一下別的東西。當你有了你的測試，以及可能也還有其它的測試，那就可以開始安全地修改代碼了，確定是否可以縮小問題范圍。記得從一個新提交開始解決問題，以便于可以輕松地撤銷無效地更改。（這就是版本控制，如果你沒有使用過版本控制，這將會改變你的生活。好吧，可能它只是讓編碼更容易。查閱“版本控制可視指南”，以了解更多。）

盡管如此，當它不再感覺起來像一個有趣的挑戰(zhàn)或者游戲而開始變得令人沮喪時，你最好的舉措是脫離這個問題。休息一下。我強烈建議你去散步并嘗試考慮別的事情。

當你回來了，如果你沒有突然受到啟發(fā)，那就把你關于這個問題所知的每一個點信息寫下來。這應該包括：

真正造成問題的調用
真正發(fā)生了什么，包括任何錯誤信息或者相關的日志信息
你真正期望發(fā)生什么
到目前為止，為了找出問題，你做了什么工作；以及解決問題中你發(fā)現(xiàn)的任何線索。
有時這里有很多信息，但相信我，從零碎中挖掘信息是很煩人。所以盡量簡潔，但是要完整。

我經(jīng)常發(fā)現(xiàn)寫下所有信息能夠啟迪我想到還沒嘗試過的東西。當然，有時候我在點擊求助郵件（或表單）的提交按鈕后立刻意識到問題是是什么。無論如何，當你在寫下所有東西仍一無所獲時，那就試試向他人發(fā)郵件求助。首先是你的同事或者其他參與你的項目的人，然后是該項目的郵件列表。不要害怕向人求助。大多數(shù)人都是友善和樂于助人的，我發(fā)現(xiàn)在 Python 社區(qū)里尤其如此。