Debugging: Finding It Yourself

De meeste beginners behandelen een bug als een muur. Ze slaan ertegenaan, stoppen, en vragen iemand anders om erover heen te klimmen. De gewoonte die echt vaardigheden opbouwt, is anders: je leert een bug te behandelen als een vraag met een vindbaar antwoord, en je gaat het antwoord zoeken voordat je gaat vragen.

Lees de foutmelding als bewijs, niet als ruis

Stack traces worden constant overgeslagen omdat ze eng uitzien. Maar ze vertellen je meestal precies waar en waarom iets kapot is gegaan. Als je TypeError: 'NoneType' object is not subscriptable in Python krijgt, dat is geen willekeurige onzin — het betekent dat een variabele die je verwacht als list of dict te bevatten, eigenlijk None is. Het regelnummer vertelt je waar. Jouw taak is teruggaan van die regel en vinden waar de waarde had moeten worden ingesteld maar niet is.

Doe dit voordat je iets online zoekt: lees eerst de laatste regel van de traceback, werk dan omhoog. De laatste regel noemt meestal de werkelijke exception. De regels erboven tonen de call chain die je daar heeft gebracht.

Reproduceer het met opzet

Als een bug slechts soms optreedt, begrijp je het nog niet. Probeer het voordat je code aanraakt, om het betrouwbaar aan het gebeuren te krijgen. Wijzig één input tegelijk. Faalt het met een lege list maar niet met een volle? Faalt het alleen bij de tweede aanroep van een functie, niet de eerste? Een bug die je op commando kunt reproduceren, is een bug die voor 80% is opgelost, omdat je nu kunt testen of een fix eigenlijk werkt in plaats van te gissen.

Snij het probleem doormidden, dan doormidden nog een keer

Binair zoeken is niet alleen voor gesorteerde arrays — het is de snelste manier om kapotte code in een lange functie of pijplijn te vinden. Plaats commentaar bij of bypass de tweede helft van je logica en controleer of de eerste helft de bug nog steeds voortbrengt. Zo ja, het probleem zit in de eerste helft. Zo nee, in de tweede. Herhaal dit. Dit werkt voor een 200-regelscript net zo goed als voor een meerstadia data pijplijn waar je outputs at elk stadium met print() of df.head() controleert.

Dit slaat het willekeurig wijzigen van regels en opnieuw uitvoeren van je code, wat de meeste mensen onder druk doen en veel meer tijd kost dan het bespaart.

Gebruik de debugger in plaats van print() als print() niet meer werkt

print() statements zijn prima voor eenvoudige gevallen, maar zodra je state volgt over meerdere functieaanroepen heen, bespaart een echte debugger echt tijd. In Python, plaats import pdb; pdb.set_trace() vlak voor de verdachte regel, voer het script uit, en je krijgt een live prompt waar je variabelen kunt inspecteren, regel voor regel kunt stappen met n, en functieaanroepen kunt binnengaan met s. De ingebouwde debugger van VS Code doet hetzelfde met breakpoints die je klikt in plaats van typt. In beide gevallen is het doel hetzelfde: kijk naar de werkelijke staat van je programma in plaats van te gissen wat het waarschijnlijk is.

Isoleer het van de rest van je project

Als een bug zich voordoet in een grote codebase, debug het dan niet in de grote codebase. Kopieer de relevante functie naar een nieuw bestand met nep, minimale input die dezelfde fout uitlokt. Als de bug verdwijnt, iets over de omringende context — een globale variabele, een import, oude state — is de werkelijke oorzaak, en je hebt net iets belangrijks geleerd. Als de bug in isolatie aanhoudt, heb je nu een klein, deelbaar, testbaar geval, en je bent veel dichter bij de werkelijke fix.

Controleer je aannames tegen werkelijkheid, niet geheugen

Een groot deel van de debugtijd gaat naar onbetwiste aannames: