Debugowanie: Znajdź je sam

Większość początkujących traktuje błąd jak ścianę. Uderzają w niego, zatrzymują się i proszą kogoś innego, aby wszedł na niego dla nich. Nawyk, który faktycznie buduje umiejętności, jest inny: uczysz się traktować błąd jak pytanie z możliwą do znalezienia odpowiedzią i sam ją znajdujesz, zanim coś zapytasz.

Czytaj komunikat o błędzie jak dowód, nie szum

Stack trace'y są stale pomijane, ponieważ wyglądają przerażająco. Ale zwykle mówią ci dokładnie gdzie i dlaczego coś się zepsuło. Jeśli dostaniesz TypeError: 'NoneType' object is not subscriptable w Python, to nie jest losowy bełkot — to znaczy, że zmienna, którą spodziewałeś się że będzie listą lub słownikiem, to faktycznie None. Numer linii mówi ci gdzie. Twoim zadaniem jest śledzenią wstecz od tej linii i znalezienie gdzie wartość powinna być ustawiona, ale nie była.

Zrób to zanim będziesz szukać czegoś online: przeczytaj ostatnią linię traceback'u na początku, potem pracuj w górę. Ostatnia linia zwykle nazwa faktyczny wyjątek. Linie powyżej pokazują łańcuch wywołań, który się tam dostał.

Odtwórz to celowo

Jeśli błąd pojawia się tylko czasami, to go jeszcze nie rozumiesz. Zanim dotkniesz kodu, spróbuj sprawić, aby się pojawiał niezawodnie. Zmień jedno wejście naraz. Czy zawodzi z pustą listą, ale nie z pełną? Czy zawiera się tylko przy drugim wywołaniu funkcji, nie przy pierwszym? Błąd, który można odtworzyć na polecenie, to błąd, który jest w 80% rozwiązany, ponieważ teraz możesz przetestować czy naprawa faktycznie zadziałała zamiast zgadywać.

Podziel problem na połowę, potem znowu na połowę

Binary search to nie tylko dla posortowanych tablic — to najszybszy sposób aby znaleźć zepsuty kod w długiej funkcji lub potoku. Skomentuj lub omiń drugą połowę swojej logiki i sprawdź czy pierwsza połowa wciąż daje błąd. Jeśli tak, problem jest w pierwszej połowie. Jeśli nie, to w drugiej. Powtórz. To działa dla 200-liniowego skryptu dokładnie tak dobrze jak dla wieloetapowego potoku danych gdzie sprawdzasz wyjścia na każdym etapie za pomocą print() lub df.head().

To pokonuje losowe zmienianie linii i ponowne uruchamianie, co większość ludzi robi pod presją i marnuje o wiele więcej czasu niż je oszczędza.

Użyj debuggera zamiast print() gdy print() przestaje działać

Instrukcje print() są w porządku dla prostych przypadków, ale gdy śledzisz stan przez wielokrotne wywołania funkcji, faktyczny debugger oszczędza prawdziwy czas. W Python'ie, wrzuć import pdb; pdb.set_trace() tuż przed podejrzaną linią, uruchom skrypt, a otrzymasz żywy prompt gdzie możesz sprawdzić zmienne, krok za krokiem z n, i wejść do wywołań funkcji z s. Wbudowany debugger VS Code robi to samo z punktami przerwania, które klikasz zamiast pisać. W każdym razie, cel jest ten sam: obserwuj faktyczny stan twojego programu zamiast zgadywać jaki on prawdopodobnie jest.

Izoluj to od reszty twojego projektu

Jeśli błąd dzieje się wewnątrz dużej bazy kodu, nie debuguj go wewnątrz dużej bazy kodu. Skopiuj odpowiednią funkcję do świeżego pliku z fałszywymi, minimalnymi wejściami, które wyzwalają tę samą awarię. Jeśli błąd znika, coś w otaczającym kontekście — zmienna globalna, import, stary stan — to rzeczywista przyczyna i właśnie się o czymś ważnym dowiedziałeś. Jeśli błąd utrzymuje się w izolacji, masz teraz mały, wspólny, testowy przypadek i jesteś znacznie bliżej faktycznej narawy.

Sprawdź swoje założenia względem rzeczywistości, nie pamięci

Huża część czasu debugowania idzie do niezakwestionowanych założeń: