Debugging: Finding It Yourself

Die meisten Anfänger behandeln einen Bug wie eine Mauer. Sie stoßen dagegen, bleiben stehen und bitten jemand anderen, über sie hinwegzuklettern. Die Gewohnheit, die tatsächlich Fähigkeiten aufbaut, ist anders: du lernst, einen Bug wie eine Frage mit einer findbaren Antwort zu behandeln, und du findest die Antwort, bevor du fragst.

Lies die Fehlermeldung wie Beweise, nicht wie Störgeräusche

Stack Traces werden ständig übersprungen, weil sie beängstigend aussehen. Aber sie sagen dir normalerweise genau, wo und warum etwas kaputtging. Wenn du TypeError: 'NoneType' object is not subscriptable in Python bekommst, ist das kein zufälliger Unsinn — es bedeutet, dass eine Variable, die eine Liste oder ein Dict enthalten sollte, tatsächlich None ist. Die Zeilennummer sagt dir, wo. Deine Aufgabe ist es, von dieser Zeile aus rückwärts zu gehen und zu finden, wo der Wert hätte gesetzt werden sollen, aber nicht wurde.

Tu dies, bevor du etwas online suchst: Lies zuerst die letzte Zeile des Tracebacks, arbeite dann aufwärts. Die letzte Zeile nennt normalerweise die tatsächliche Ausnahme. Die Zeilen darüber zeigen die Aufrufliste, die dich dorthin gebracht hat.

Reproduziere ihn absichtlich

Wenn ein Bug nur manchmal auftaucht, verstehst du ihn noch nicht. Bevor du Code anfasst, versuche, ihn zuverlässig zum Auftreten zu bringen. Ändere jeweils eine Eingabe. Schlägt er mit einer leeren Liste fehl, nicht aber mit einer vollen? Schlägt er nur beim zweiten Aufruf einer Funktion fehl, nicht beim ersten? Ein Bug, den du gezielt reproduzieren kannst, ist ein Bug, der zu 80 % gelöst ist, denn jetzt kannst du testen, ob eine Behebung wirklich funktioniert hat, statt zu raten.

Halbiere das Problem, dann halbiere es nochmal

Binäre Suche ist nicht nur für sortierte Arrays — es ist der schnellste Weg, um fehlerhafte Code in einer langen Funktion oder Pipeline zu finden. Kommentiere die zweite Hälfte deiner Logik aus oder umgehe sie und überprüfe, ob die erste Hälfte den Bug noch produziert. Wenn ja, liegt das Problem in der ersten Hälfte. Wenn nein, liegt es in der zweiten. Wiederhole. Das funktioniert für ein 200-Zeilen-Skript genauso wie für eine mehrstufige Datenpipeline, bei der du Ausgaben in jeder Phase mit print() oder df.head() überprüfst.

Das schlägt zufällige Zeilenänderungen und erneutes Ausführen, was die meisten Menschen unter Druck tun, und es kostet viel mehr Zeit, als es spart.

Nutze den Debugger statt print(), wenn print() nicht mehr funktioniert

print()-Anweisungen sind für einfache Fälle in Ordnung, aber sobald du Zustände über mehrere Funktionsaufrufe hinweg verfolgst, spart ein echter Debugger echte Zeit. In Python, füge import pdb; pdb.set_trace() direkt vor die verdächtige Zeile ein, führe das Skript aus, und du bekommst einen Live-Prompt, wo du Variablen überprüfst, Zeile für Zeile mit n schreitest und mit s in Funktionsaufrufe einsteigst. Der eingebaute Debugger von VS Code tut dasselbe mit Haltepunkten, die du anklickst statt zu tippen. In beiden Fällen ist das Ziel dasselbe: beobachte den tatsächlichen Zustand deines Programms statt zu raten, wie er wahrscheinlich ist.

Isoliere ihn vom Rest deines Projekts

Wenn ein Bug in einer großen Codebasis auftritt, debugge ihn nicht in der großen Codebasis. Kopiere die relevante Funktion in eine neue Datei mit gefälschten, minimalen Eingaben, die denselben Fehler auslösen. Wenn der Bug verschwindet, ist etwas über den umgebenden Kontext — eine globale Variable, ein Import, veralteter Zustand — die echte Ursache, und du hast gerade etwas Wichtiges gelernt. Wenn der Bug in Isolation bestehen bleibt, hast du jetzt einen kleinen, teilbaren, testwertigen Fall, und du bist viel näher an der echten Behebung.

Überprüfe deine Annahmen gegen die Realität, nicht gegen die Erinnerung

Ein großer Teil der Debug-Zeit geht auf unbefragte Annahmen: