Immer wenn ich jemanden sehe, der JavaScript im Browser effektiv debuggt, nutzt er die DevTools-Werkzeuge dafür. Das Setzen von Breakpoints und das Springen darüber und Ähnliches. Anstatt überall in Ihrem Code console.log()-Anweisungen (und deren Freunden) zu verteilen.
Parag Zaveri schrieb über den Übergang und das hat offensichtlich bei vielen Leuten Anklang gefunden! (7,5 Tausend Applaudieren auf Medium, während ich dies schreibe).
Ich weiß, dass ich damit meine Schwierigkeiten habe…
- Ein Teil des Debuggens besteht nicht nur darin, Code einmal so wie er ist zu inspizieren; es geht darum, Dinge zu inspizieren, Änderungen vorzunehmen und dann mit dem Debuggen fortzufahren. Wenn ich viel Zeit mit dem Setzen von Breakpoints verbringe, werden sie dann immer noch da sein, nachdem ich meinen Code geändert und neu geladen habe? Antwort: DevTools scheint das ziemlich gut zu machen.
- In die Konsole zu schauen, um Ausgaben zu sehen, ist eine Sache, aber im Quellen-Panel herumzufummeln ist eine andere. Mein Code dort kann transpiliert, kombiniert und nicht ganz wie mein geschriebener Code aussehen, was die Suche erschwert. Außerdem ist es dort visuell etwas eng.
Aber doch! Es ist so mächtig. Das Setzen eines Breakpoints (nur durch Klicken auf eine Zeilennummer) bedeutet, dass ich meinen eigenen Code nicht mit zusätzlichem Müll vollmüllen muss, noch muss ich entscheiden, was protokolliert werden soll. Jede Variable im lokalen und globalen Geltungsbereich steht mir zur Verfügung, um sie am Breakpoint anzusehen. Ich habe in Parags Artikel gelernt, dass Sie möglicherweise nicht einmal manuell Breakpoints setzen müssen. Sie können zum Beispiel dafür sorgen, dass der Code bricht, wenn ein Klick (oder ein anderes) Ereignis ausgelöst wird. Außerdem können Sie Variablennamen eingeben, die Sie speziell beobachten möchten, sodass Sie nicht danach graben müssen. Ich werde versuchen, die richtigen DevTools häufiger zum Debuggen zu verwenden und zu sehen, wie es läuft.
Wo wir gerade vom Debuggen sprechen… Das beschäftigt mich schon seit einigen Monaten: Warum hat JavaScript keine Protokollierungsebenen? Anscheinend ist das ein sehr gängiges Konzept in vielen anderen Sprachen. Sie können Protokollanweisungen schreiben, aber diese werden nur protokolliert, wenn die Konfiguration dies vorsieht. So können Sie in der Entwicklung detaillierte Protokolle erhalten, aber in der Produktion nur schwerwiegendere Fehler protokollieren. Ich erwähne es, weil es schön wäre, nützliche Protokollanweisungen im Code zu belassen, aber sie nicht tatsächlich protokollieren zu lassen, wenn Sie beispielsweise console.level = "production"; oder etwas Ähnliches setzen. Oder vielleicht könnten sie während eines Build-Schritts herauskompiliert werden.