開場

不管是老手還是新手，寫程式時最怕看到的就是滿滿的紅字錯誤訊息。前幾天我在製作小程式的時候，也不只一次被滿螢幕的紅字嚇到，甚至一度懷疑自己是不是打錯字或完全不懂。但其實出錯是寫程式的日常，可能是少打一個字母、邏輯沒想清楚，甚至是忘了安裝某個套件……各種千奇百怪的狀況都有可能，結果就是程式跑不起來或結果完全不如預期。那麼，當我們遇到這些狀況時該怎麼辦呢？
今天就來聊聊新手最常遇到的錯誤，以及該如何一步步 Debug。

1.什麼是 Debug？

Debug，顧名思義就是移除程式中的 bug。
這個名稱的由來也非常有趣：1947 年，美國電腦科學家 Grace Hopper 發現電腦故障的原因竟然是一隻卡在機器裡的飛蛾，從此「Debug」就成了找出錯誤的代名詞。
現在的 bug 不是真的蟲子，每次發現錯誤、解決錯誤的過程，就是在訓練我們的程式思維，因此Debug 不只是一個技術動作，更是一種思維模式。
當我們開始使用列印偵錯（Print-debugging）或更進階的偵錯工具（Debugger），一步步追蹤程式碼的執行流程，會發現那些難以捉摸的邏輯錯誤，其實都隱藏在細節之中。所以，學會 Debug 不只是修好一個 bug，而是掌握了解決任何程式問題的核心能力，這也讓寫程式的過程變得更加穩固和高效率。

2.Python 常見錯誤類型

以下是新手最常遇到的錯誤，搭配簡單的範例：

(1)SyntaxError語法錯誤

print("Hello World"

• 少打一個括號，程式就會報錯。

(2)NameError變數未定義

print(name)

• 使用了沒宣告過的變數。

(3)TypeError型別不符

number = "10"
print(number + 5)

• 字串和數字不能直接相加。

(4)IndexError索引超出範圍

items = [1, 2, 3]
print(items[5])

• 嘗試存取不存在的元素。

這邊要釐清的一點是，錯誤訊息不是敵人，而是提示，只要仔細讀懂它，就能找到方向。

3.新手常用的 Debug 方法

針對新手，最常用且最容易上手的 Debug 方法主要有以下三種：

(1)輸出訊息法 (Print Debugging)

在程式中加上 print()或 System.out.println、console.log 等，接著把變數數值、流程進度印出來，確認程式有沒有照預期運行，這是個簡單又快速的方法。

(2)使用 IDE 的偵錯工具 (Debugger / Breakpoint)

在 IDE 像是IntelliJ、PyCharm、Visual Studio、Eclipse中設斷點 (breakpoint)，可以逐行執行程式、查看變數值、呼叫堆疊。這個方法能更深入觀察程式運行，但也需要花較多時間製作。

(3)逐步縮小問題範圍 (Divide and Conquer)

把程式拆成小段測試，確認問題出在哪一部分。(後面後提到如何縮小範圍的)

(4)檢查錯誤訊息 (Error Messages)

很多新手會忽略紅色錯誤訊息，其實錯誤訊息通常已經提示問題在哪裡，可以很好地根據提示做修改。

4.Debug 的思維方式

Debug 的思維方式就像偵探辦案一樣，需要有系統、有邏輯地進行。
我們可以把這個過程拆解成幾個關鍵步驟來詳細說明：

(1)縮小問題範圍：從大局到細節

當程式出錯時，我們常犯的錯誤是想一口氣檢查所有程式碼，但正確的做法是縮小問題範圍。
這邊推薦兩種檢測方法：

• 二分法測試：我們可以把程式碼分前後兩段測試，看錯誤是否重現，能夠快速鎖定問題的大概位置。
• 隔離測試：把可疑的程式碼單獨拉出來，寫一個小小的測試腳本，只執行這段程式碼並給它特定的輸入，看看是否會產生同樣的錯誤，這能排除外部因素的干擾，專注於問題本身。

(2)嘗試重現錯誤：確認問題的發生條件

Debug 最怕的就是錯誤時好時壞，為了能穩定地找到並修復問題，必須能夠穩定地重現錯誤。

• 記錄步驟：詳細記錄從程式啟動到錯誤發生的每一個操作步驟：點擊了哪個按鈕、輸入了什麼內容、上傳了什麼檔案。
• 固定變數：如果問題與輸入資料有關，試著用同樣的資料來執行程式。

透過重現錯誤，能確認問題發生的條件，而不是隨機發生，我們也才能有效地測試修正方案是否有效。

(3)假設→驗證→修正：科學化的排查流程

這個流程是 Debug 的核心，它將 Debug 從亂槍打鳥的行為，提升為有科學根據的推理過程。

• 提出假設 (Hypothesize)：根據觀察到的現象，提出一個關於問題原因的假設。
• 進行驗證 (Verify)：設計一個實驗來驗證這個假設。最簡單的方法就是使用 print() 函式或偵錯工具，把 total 這個變數的值印出來，看看它的值是不是如你所預期的。
• 修正 (Fix)：如果驗證結果證實你的假設是對的，那就修改程式碼；如果假設是錯的，那就拋棄這個假設，提出新的假設，然後回到步驟 (1)。

這個流程讓我們每次的行動都有明確的目的，而不是漫無目的地亂改一通。

(4)避免亂改，保持紀錄：確保問題徹底解決

找到問題並修正後，別急著關閉程式，有兩個步驟需要先做：

• 保持紀錄：紀錄發現了什麼錯誤，以及是如何修正的。這能幫助我們未來遇到類似問題時，能更快找到解決方案，同時，如果這次的修正又引入了新的 Bug，這份紀錄也能讓你輕鬆回溯。
• 回歸測試 (Regression Testing)：修正完畢後，再次執行重現錯誤的步驟，確保原先的問題真的解決了，同時也需要檢查程式的其他功能，確認修正沒有引入新的 Bug（這也稱為回歸問題）。

透過這些有系統的思維方式，Debug 不再是令人沮喪的過程，而是一種有條理的邏輯挑戰，因為它不只解決了當下的問題，更讓我們在過程中學會如何寫出更不容易出錯的程式碼。

5.心得

學會 Debug 的過程，對我來說就像是從一個盲人摸象的摸索者，逐漸成為一個思路清晰的偵探。一開始，每當程式報錯，我都會感到焦慮與挫敗，只能憑直覺亂改一通，結果不是解不開，就是讓問題更嚴重。

後來我慢慢體會到，Debug 不只是找到錯誤的語法，更是一種系統化的思維訓練。我開始學會先耐心閱讀錯誤訊息，理解它真正的意思，再循著蛛絲馬跡逐步排查，跨越一道又一道難關。

最後我發現，每一次修正錯誤的過程其實都是一種難得的收穫。因為我們往往最容易記住那些花最多時間解決的問題，而這份經驗也能應用到生活中，面對現實的難題時，我因此變得更有耐心，也更懂得有條理地思考。