Fang an, Debugger zu nutzen!

Ich sehe viele talentierte und gute Entwickler, die keine Debugger nutzen. Selbst Leute, die seit mehreren Jahren im Geschäft sind, tun es sehr oft einfach nicht. Statt einen Debugger einzurichten, streuen sie var_dump() oder console.log() überall dorthin, wo sie ihr aktuelles Problem vermuten.

Zugegeben, das hat ein paar Vorteile: Es geht sehr schnell, und es funktioniert sogar dann, wenn du gar keine Infrastruktur fürs Debuggen hast. Andererseits kann das Einrichten eines Debuggers Zeit kosten, du musst wissen, wie es geht, und es neigt dazu, sehr zufällige und nicht reproduzierbare Fehler zu erzeugen.

Die Vorteile, einen Debugger zu haben, überwiegen die Nachteile, keinen zu haben, bei Weitem.

Setup

Für dieses Beispiel nutze ich PhpStorm und eine lokale TYPO3-Installation in einem Docker-Container. Je nach Programmiersprache und IDE gibt es kleine Unterschiede, aber am Ende sollte jeder moderne Debugger sehr ähnlich funktionieren. 

Ein paar Vorteile eines Debuggers

Den Code anhalten, wann du willst

Breakpoints

Breakpoints halten die Ausführung an und lassen dich untersuchen, was an einer bestimmten Zeile in deinem Code genau passiert. Du kannst so viele Breakpoints setzen, wie du willst, und du kannst sie sogar spontan setzen — wenn du den Code angehalten hast und er später noch mal anhalten soll, fügst du den Breakpoint einfach während des Debuggens hinzu. Kein Neustart des Programms von vorne nötig.

Bedingte Breakpoints

Du kannst sogar bedingte Breakpoints setzen. Diese speziellen Breakpoints halten deinen Code nur an, wenn eine bestimmte Bedingung erfüllt ist. Das ist besonders nützlich, wenn etwas zwei- oder mehrmals ausgeführt wird. Ein gutes Beispiel ist eine Schleife über ein Array, bei der du nur sehen willst, was passiert, wenn die Array-Daten einen bestimmten Wert haben. 

Der Breakpoint im Beispiel oben hält die Ausführung nur an, wenn $singleData eine Instanz von fancyObject ist.

Funktionen „im Vorbeigehen" auswerten

Sehr oft willst du nur wissen, was eine bestimmte Funktion ausgibt, ohne die ganze Funktion durchzudebuggen. Klar, du kannst den Code einfach nach der Ausführung anhalten, aber das reicht nicht immer. Angenommen, die fragliche Funktion wurde gar nicht ausgeführt, oder sie hat keinen Rückgabewert — was machst du dann? Du nutzt die Evaluate-Funktion deines Debuggers! 

Im Beispiel oben siehst du eine blaue Zeile. Dort habe ich einen Breakpoint gesetzt und der Code hat angehalten. Trotzdem will ich sehen, was passiert, wenn

$logManager = new LogManager((string)$requestId);

Wenn ich mit dem Prüfen fertig bin, klicke ich einfach auf „Next" im Debugger, und der Code läuft weiter, als wäre nichts gewesen.

Alle Variablen rund um deinen Breakpoint anzeigen

Ein weiteres cooles Feature: Du bekommst nicht nur die Variable, die du suchst, sondern eine Menge Informationen rund um deinen aktuellen Breakpoint — und du kannst sie sogar nach Bedarf ändern. 

Gehen wir das zusammen durch:

1. Das sind die Threads und Teile deines Codes, die bereits ausgeführt wurden. Du siehst die index.php, die dann zur Ausführung des Codes in Bootstrap.php geführt hat. Es gibt auch die Zeilennummer. Wenn du auf einen Eintrag dieser Liste klickst, springst du an die richtige Stelle im Code. 
2. Bei Punkt 2 siehst du alle Variablen, die aktuell gesetzt sind und benutzt werden. Du bekommst sogar Server- und magische Variablen, ohne extra danach fragen zu müssen.
3. Du kannst sogar die Namen oder Inhalte der Variablen ändern, und die neu gesetzten Werte werden in dieser konkreten Debugging-Sitzung durchgängig verwendet. Das ist sehr hilfreich, wenn du sehen willst, wie dein Code auf verschiedene Werte reagiert, ohne sie hart zu verdrahten und jedes Mal neu zu starten.

Da geht noch mehr

Ich habe nur an der Oberfläche gekratzt, was ein Debugger für dich tun kann. Es gibt so viele weitere Anwendungsfälle, dass es für diesen Artikel viel zu viel wäre. 

Probleme, die ein Debugger verursachen kann

Ehrlich gesagt: Ein Debugger ist nicht nur Sonnenschein. Irgendwann debuggst du womöglich den Debugger, weil du einen Pfad falsch gesetzt hast oder wegen etwas ähnlich Dummem. Hier also ein paar häufige Probleme, in die ich regelmäßig laufe.

Dein Programm hält zufällig an

Eine Kleinigkeit, in die ich manchmal laufe: Ich ändere etwas im Code, probiere es aus, und nichts passiert. Mein erster Instinkt ist natürlich immer: Ich hab's kaputt gemacht! In 90 % der Fälle hat aber eine im Hintergrund laufende IDE die Debugging-Sitzung abgefangen und den Code angehalten. Viel Spaß beim Debuggen, wenn mit deinem frisch geänderten Code eigentlich alles in Ordnung ist. 

Um das zu vermeiden (in PhpStorm), gib jedem Projekt einen eindeutigen Namen und stell sicher, dass deine IDE keine beliebigen Verbindungen annimmt — oder lass einfach nur eine IDE gleichzeitig laufen.

Dein Programm hält zufällig nicht an

Noch eine Kleinigkeit: Du schaltest deine Breakpoints oder den Debugger aus und vergisst, sie wieder einzuschalten. Man kann einzelne oder sogar alle Breakpoints auf einmal deaktivieren. Dann tut dein Debugger natürlich nichts. Das kann sehr nervig sein, wenn dabei Daten verändert werden und du sie nach dem Test ohne laufenden Debugger wieder zurücksetzen musst. Zum Beispiel wird ein Datenbankeintrag, den du debuggen willst, nach der Ausführung deines Programms geändert, und du musst ihn zurücksetzen, bevor du wieder mit dem Debuggen anfangen kannst. Das hast du aber sehr schnell raus.

Das System wird langsamer

Das ist meiner Meinung nach der einzige echte Nachteil. Je nachdem, wie kräftig deine Maschine ist, kann ein Debugger dein System deutlich ausbremsen. Leider weiß ich wirklich nicht, wie man das löst, außer deinem Entwicklungssystem mehr Leistung zu geben. 

Zusätzlicher Overhead in deinem Entwicklungs-Workflow