4 Antworten

★ Beste Antwort

Was oft übersehen wird, ist die Verwendung des Network-Tabs parallel dazu. Oft denkst du, dein JavaScript hat einen Bug, aber das Problem ist eigentlich, dass ein API-Call stillschweigend fehlgeschlagen ist oder komische Daten zurückgebracht hat. Überprüf immer die Antworten vom Backend, bevor du in deinem Frontend-Code herumgräbst - das spart dir Stunden.

Der echte Trick ist ansonsten, Stack Traces lesen zu lernen. Wenn ein Fehler auftaucht, schau nicht nur auf die Stelle, wo es „Fehler hier" sagt, sondern verfolg den Weg der Funktionsaufrufe, die ihn verursacht haben. Oft liegt die eigentliche Fehlerquelle zwei oder drei Ebenen höher in der Kette. Und wenn du TypeScript oder einen anständigen Linter benutzt, fängst du schon einen großen Teil der Probleme ab, bevor du überhaupt anfängst zu debuggen.

Wie viele console.log()-Aufrufe packst du in den Code, bevor du merkst, dass Chrome DevTools bereits alles hat, das du brauchst?

Der echte Perspektivwechsel ist, das Debugging nicht als verzweifelte Schnitzeljagd zu sehen. Chrome DevTools hat die Sources, wo du echte Breakpoints setzen kannst - nicht nur „gib diesen Wert aus und hoffe das Beste" - und dann Zeile für Zeile durch den Code steppen kannst. Was die Leute viel zu wenig nutzen, ist das Beobachten von spezifischen Variablen, damit du in Echtzeit siehst, was sich ändert, während der Code läuft. Und dann ist da noch die Console Drawer, die immer griffbereit ist - perfekt für schnelle Checks, ohne die Ausführung zu unterbrechen.

Noch eine Sache, die mich unzählige Male gerettet hat: den Network Tab nicht nur nutzen, um zu sehen, ob Requests rausgehen, sondern um genau zu kontrollieren, was vom Server ankommt. Ich habe schon Stunden damit verbracht, Logik zu debuggen, die eigentlich ein Problem in den Daten war, die ankamen. Wenn die App komplex ist und einen internen State hat, sind Vue DevTools oder React DevTools (je nachdem, was du nutzt) absolute Killer - du siehst den State in Echtzeit mutieren und kannst zu vorherigen States zurückgehen. Das ist keine Magie, es ist nur, dass die Leute oft nicht wissen, dass es das gibt.

Ach, und noch eine letzte, banale aber wahre Sache: setz conditional breakpoints. Du willst nicht immer auf einer Zeile stoppen, du willst nur stoppen, wenn eine bestimmte Variable einen bestimmten Wert hat. Damit sparst du dir zumindest, tausendmal auf „continue" zu klicken.

Verschwende keine Zeit damit, wahllos Breakpoints in Funktionen zu setzen; nutze stattdessen die Chrome DevTools Conditions, um die Ausführung nur dann zu stoppen, wenn eine Variable einen bestimmten Wert erreicht - das ändert komplett, wie du Bugs in komplexen Apps verfolgst. Und wenn du vor einem Fehler stehst, der zufällig wirkt, offenbart der Network Tab oft das, was du im Code nicht siehst, wie Race Conditions oder missgebildete API-Antworten.

Wenn du mit dem Debuggen anfängst, wie viele Breakpoints setzt du, bevor du merkst, dass das Problem wahrscheinlich woanders liegt?

Oft fehlt einfach ein systematischer Ansatz. Chrome DevTools ist unglaublich mächtig, aber viele nutzen nur console.log und klassische Breakpoints. Probier conditional Breakpoints: Rechtsklick auf die Codezeile, wähle "Add conditional breakpoint" und schreib die Bedingung, die dich interessiert. Zum Beispiel ein Breakpoint, der nur auslöst, wenn `user.id === undefined` ist, statt dich jedes Mal anzuhalten. Dann nutze Logpoints (ähnlich, aber sie geben eine Nachricht aus, ohne die Ausführung zu stoppen), wenn du Werte tracken musst, ohne den Ablauf zu unterbrechen.

Ein Trick, den kaum einer kennt: Im Network-Tab von DevTools kannst du filtern und dir genau anschauen, was mit deinen Anfragen schiefläuft. Wenn sich die App merkwürdig verhält, ist oft das Problem, dass ein Request nicht das ist, was du denkst, oder die Antwort ist malformed. Nutze auch den Performance-Tab, wenn du Lag verdächtigst: Nimm auf, was passiert, und schau, wo dein Code wirklich langsamer wird. Zum Schluss lern, Watch Expressions zu nutzen: Im Scope-Bereich fügst du die Variablen hinzu, die dich interessieren, und siehst sie in Echtzeit aktualisieren, während du durch den Code gehst. Das spart dir eine Menge sinnloser Ausgaben.

ricci1987 asker Danke für die Tipps! Conditional Breakpoints und Logpoints kannte ich nicht, das ist genau das, was ich gesucht habe. Ich werde die Registerkarte Netzwerk gleich für Anfragen ausprobieren.

Deine Antwort

Anmeldenzum Beantworten.