Einführung von Logpoints und automatischem Anhängen

12. Juli 2018 Kenneth Auchenberg, @auchenberg

In den letzten Monaten haben wir intensiv an der Verbesserung des Debugging-Erlebnisses in Visual Studio Code gearbeitet. In diesem Beitrag werde ich darlegen, wie wir über das Debuggen denken, das Feedback unserer Benutzer präsentieren und die Schritte erläutern, die wir unternehmen, um das Debuggen in VS Code einfacher und unkomplizierter zu gestalten.

Seit der Einführung von VS Code bieten wir eine integrierte Debugging-Erfahrung, da wir der Meinung sind, dass das Debuggen ein integraler Bestandteil des Ortes sein sollte, an dem Sie Ihren Quellcode schreiben und bearbeiten – Ihrem Editor.

VS Code debugger

Das Debugging-Erlebnis von VS Code wird durch eine generische Debugger-Benutzeroberfläche ermöglicht, die über das Debug Adapter Protocol (DAP) mit einer spezifischen Art von VS Code-Erweiterung kommuniziert, die wir als Debug Adapter (DA) bezeichnen. Der DA spricht mit einem echten Debugger und übersetzt zwischen DAP und dem laufzeitspezifischen Debug-Protokoll oder der API des Debuggers.

Das bedeutet, dass der Kern von VS Code vollständig von dem spezifischen Debugger entkoppelt ist, und diese Architektur ermöglicht es VS Code, alles zu debuggen, solange ein Debug Adapter verfügbar ist, wie hier veranschaulicht

VS Code debugging architecture

Beobachtungen und Probleme

Heute gibt es eine große Gruppe von zufriedenen Entwicklern, die VS Code regelmäßig zum Debuggen nutzen. Im Rahmen unserer Mission möchten wir das Debuggen jedoch einfacher und für mehr Entwickler zugänglich machen.

Zu diesem Zweck haben wir Gespräche begonnen, um die Probleme beim Debuggen in VS Code besser zu verstehen und zu erfahren, warum einige Entwickler unseren Debugger überhaupt nicht nutzen.

Hier sind unsere Beobachtungen

Debug-Konfiguration ist schwer richtig einzustellen

VS Code ist ein Allzweckeditor mit einem generischen Debugger und ist nicht auf einen bestimmten Stack oder eine bestimmte Laufzeit spezialisiert. Aus diesem Grund können wir keine meinungsbildende Standard-Debug-Konfiguration bereitstellen, die für alle funktioniert.

Das bedeutet, dass VS Code Sie auffordert, Einstellungen für den Debugger zu konfigurieren und anzugeben, wie Sie Ihre Laufzeit mit den richtigen Parametern starten möchten usw.

Wir erkennen an, dass dies schwer richtig einzustellen sein kann, aber wir sehen keinen Weg, die Debug-Konfiguration für alle vollständig zu eliminieren. Wir glauben jedoch, dass die Debug-Konfiguration vereinfacht und je nach Kontext auf ein Minimum reduziert werden kann.

Ich komme später darauf zurück.

Verwechslung zwischen Start- und Anhangskonfigurationen

In VS Code haben wir zwei Kernkonzepte für das Debuggen: **Starten** (Launch) und **Anhängen** (Attach), die zwei verschiedene Arbeitsabläufe und Entwicklersegmente abdecken. Abhängig von Ihrem Workflow kann es verwirrend sein, zu wissen, welcher Konfigurationstyp für Ihr Projekt geeignet ist.

Wenn Sie aus dem Hintergrund der Browser-Entwicklertools (DevTools) kommen, sind Sie das Konzept des "Startens aus Ihrem Tool" nicht gewohnt, da Ihre Browserinstanz bereits geöffnet ist. Wenn Sie DevTools öffnen, **hängen** Sie DevTools einfach an Ihre offene Browser-Registerkarte **an**. Wenn Sie hingegen aus einem Java-Hintergrund kommen, ist es ganz normal, dass Ihr Editor Ihren Java-Prozess **startet** und Ihr Editor seinen Debugger automatisch an den neu gestarteten Prozess anhängt.

Der beste Weg, den Unterschied zwischen **Starten** und **Anhängen** zu erklären, ist, sich Startkonfigurationen als ein Rezept vorzustellen, wie Ihre App im Debug-Modus gestartet wird, **bevor** VS Code sich daran anhängt, während eine Anhangskonfiguration ein Rezept ist, wie sich der Debugger von VS Code mit einer **bereits** laufenden App oder einem Prozess verbindet.

Der Wert von Startkonfigurationen liegt darin, dass sie Ihnen eine Möglichkeit bieten, einen Teil des kognitiven Aufwands beim Starten Ihrer App mit den richtigen Debugging-Parametern zu reduzieren, indem eine Konfiguration erstellt wird, die wiederholbar und für Ihr Projekt und Team freigabebereit ist.

Als wir jedoch mit Entwicklern darüber sprachen, wie sie ihre Anwendungen starten, sahen wir ein Muster und machten eine wichtige Beobachtung

Beobachtung: Viele Entwickler, die VS Code verwenden, lieben das integrierte Terminal und verlassen sich auf Befehlszeilentools zum Starten ihrer Anwendungen. Für viele ist es ein natürlicheres Arbeitsablauf, einen Befehl im Terminal auszuführen, gefolgt vom Anhängen des Debuggers aus dem Editor. Dies ähnelt dem Öffnen von DevTools, nachdem der Browser gestartet wurde.

Diese Beobachtung war entscheidend, und wir erkannten, dass viele Benutzer keine vollständige "magische" Start-Erfahrung in ihrem Editor wünschen. Sie möchten ihren Editor als Ort zum Bearbeiten und Debuggen von Quellcode behalten und das Terminal zum Starten von Apps, Ausführen von Build-Skripten usw. verwenden. Dies ist einer der Gründe, warum wir eine integrierte Terminal-Erfahrung innerhalb von VS Code haben, da wir glauben, dass eine gute funktionale Benutzeroberfläche gut mit dem Terminal koexistieren und integriert werden sollte.

Viele Entwickler verwenden keine Breakpoints, da sie Zustandsänderungen inspizieren

Bei der Betrachtung, wie Entwickler ihre Anwendungen debuggen, sahen wir auch ein weiteres interessantes Muster: Die Verwendung von Logging anstelle von Breakpoints.

Logging zum Debuggen ist kein neues Konzept, aber die Beobachtung war wichtig

Beobachtung: Traditionelle Debugging-Arbeitsabläufe konzentrieren sich hauptsächlich auf die Verlangsamung der Ausführung, um die Programmlogik zu untersuchen, während Logging-Arbeitsabläufe normalerweise die Untersuchung des Programmzustands und seiner Änderungen während der normalen Ausführung einer Anwendung umfassen. Die grundlegende Beobachtung hier ist, dass die beiden Techniken für unterschiedliche Debugging-Zwecke verwendet werden.

Diese Beobachtung ist besonders relevant für JavaScript-Entwickler, die sich hauptsächlich mit der Komplexität der Zustandsverwaltung befassen, und dies könnte erklären, warum die meisten JavaScript-Entwickler immer noch lieber `console.log`s zu ihrem Quellcode hinzufügen, anstatt einen Skript-Debugger zu verwenden.

Automatisches Anhängen an Node-Prozesse

Als wir darüber nachdachten, wie einige Entwickler das integrierte Terminal zum Starten ihrer Debugging-Sitzung verwenden, sahen wir eine einzigartige Gelegenheit. Durch die Nutzung der kontextbezogenen Informationen, die wir innerhalb von VS Code aus Ihrem Editor und dem integrierten Terminal haben, konnten wir Ihren Kontext erkennen und Ihre Absicht zum Debuggen nachvollziehen, und dies könnte eine wesentlich einfachere Debugging-Erfahrung für Node.js-Entwickler bieten.

In unserer **März-Iteration** von VS Code haben wir eine neue Funktion namens **Automatisches Anhängen für Node** veröffentlicht, die es dem Node-Debugger ermöglicht, sich automatisch an Node.js-Prozesse anzuhängen, die im Debug-Modus aus dem integrierten Terminal von VS Code gestartet wurden.

Sie aktivieren das automatische Anhängen, indem Sie den Befehl **Debug: Automatisches Anhängen umschalten** über die Befehlspalette ausführen. Sobald es aktiviert ist, können Sie das automatische Anhängen auch über die Statusleiste umschalten.

Auto attach

Diese Funktion eliminiert jegliche Debug-Konfiguration vollständig, da wir jeden mit `node --inspect` gestarteten Node.js-Prozess als Absicht zum Debuggen interpretieren. In Kombination mit dem integrierten Terminal ist dies eine wesentlich einfachere Debugging-Erfahrung, die es Entwicklern ermöglicht, ihre App auf ihre eigene Weise zu starten und gleichzeitig die Debug-Konfiguration zu eliminieren! 🎉

NPM-Skripte und Debugging

Viele Node.js-Entwickler verlassen sich auf npm-Skripte zum Starten von Anwendungen oder zum Starten von Debugging-Sitzungen, und wir haben auch in diesem Bereich tolle Neuigkeiten: Das automatische Anhängen funktioniert auch mit npm-Skripten. Wenn Sie `npm run debug` ausführen und das Skript `"debug"` ` "node --inspect"` oder ein anderer Befehl mit ` --inspect` ist, erkennt das automatische Anhängen dies und hängt den Debugger an 🎉

Wir erkannten auch, dass einige Entwickler eine visuellere Möglichkeit wünschten, ihre npm-Skripte zu finden und auszuführen. Daher haben wir in unserer **April 2018-Iteration** einen neuen NPM-Skripte-Explorer hinzugefügt, mit dem Sie Ihre NPM-Skripte direkt über die Benutzeroberfläche durchsuchen und ausführen können. Als Teil unserer Arbeit zur Vereinfachung der Debug-Konfiguration haben wir es auch möglich gemacht, Node.js-Debugging direkt aus dem Explorer zu starten, ohne eine Debug-Konfiguration erstellen zu müssen.

Wenn Sie ein npm-Skript haben, das ein Debugging-Argument wie `--inspect` enthält, erkennen wir dies automatisch und bieten eine Debug-Aktion, die den Debugger startet, wie hier zu sehen

NPM scripts

Einführung von Logpoints

Basierend auf der Erkenntnis, dass Logging eine wichtige Debugging-Technik ist, sahen wir eine Gelegenheit, die Zustandsinspektion in unsere bestehende Debugging-Erfahrung zu integrieren. In der **März-Iteration** von VS Code haben wir die erste Implementierung einer Debugging-Funktion namens Logpoints veröffentlicht.

Ein Logpoint ist eine Variante eines Breakpoints, die nicht in den Debugger "unterbricht", sondern stattdessen eine Nachricht an die Konsole protokolliert.

Logpoints

Das Konzept der Logpoints ist nicht neu, und in den letzten Jahren haben wir verschiedene Varianten dieses Konzepts in Tools wie Visual Studio, Edge DevTools und GDB unter verschiedenen Namen wie Tracepoints und Logpoints gesehen.

Warum und wann Logpoints verwenden?

Logpoints basieren auf der Beobachtung, dass Sie in vielen Fällen die Ausführung an einem bestimmten Teil Ihrer Anwendung nicht anhalten möchten, sondern wie sich der Zustand über die Lebensdauer der Anwendung verändert, untersuchen möchten.

Logpoints ermöglichen es Ihnen, On-Demand-Logging-Anweisungen in Ihre Anwendungslogik zu "injizieren", so als hätten Sie Logging-Anweisungen in Ihre Anwendung eingefügt, bevor Sie sie gestartet haben. Logpoints werden zur Ausführungszeit injiziert und nicht im Quellcode gespeichert, sodass Sie nicht im Voraus planen müssen, sondern Logpoints nach Bedarf injizieren können. Ein weiterer angenehmer Vorteil ist, dass Sie sich keine Gedanken über die Bereinigung Ihres Quellcodes machen müssen, nachdem Sie mit dem Debuggen fertig sind.

Für JavaScript-Entwickler bedeutet dies, dass Sie sich keine Sorgen mehr machen müssen, `console.log`s zu hinterlassen – verwenden Sie einfach Logpoints! Noch besser ist, dass Sie `console.log` und Logpoints kombinieren können. Wenn Sie einen Logpoint in einen Quellcodeblock einfügen, der bereits `console.log`s enthält, sehen Sie beide Arten von Logging-Anweisungen in der Debug-Konsole.

Logpoints in Cloud-Kontexten

Logpoints sind besonders nützlich in Cloud-Kontexten (oder eigentlich jedem Remote-Kontext), da sie es Ihnen ermöglichen, Logging in Remote-Umgebungen zu injizieren, ohne Ihre Anwendungen neu bereitstellen zu müssen. Ebenso wichtig ist, dass Sie mit Logpoints die Skriptausführung nicht anhalten, sodass Ihre Benutzer nicht beeinträchtigt werden, im Gegensatz zum Anhalten der laufenden Anwendung mit einem regulären Breakpoint.

Hier erfahren Sie mehr darüber, wie Sie Logpoints für Node.js unter Azure verwenden können.

Unterstützte Sprachen

Seit der ersten Veröffentlichung von Logpoints in VS Code haben wir eine wachsende Akzeptanz durch VS Code Debug Adapters verzeichnet, und heute gibt es Logpoint-Unterstützung für die folgenden Sprachen

Logpoints in VS Code

Wenn Sie daran interessiert sind, Logpoint-Unterstützung in Ihrem Debug Adapter für VS Code hinzuzufügen, werfen Sie bitte einen Blick auf diese Änderungen im Protokoll. Sie können sich auch die oben genannten Debug Adapter ansehen, um zu sehen, wie jede Laufzeit Logpoints implementiert hat.

Nächste Schritte

Das war es vorerst, aber wir sind noch nicht fertig. In unserer **Juli-Iteration** verbessern wir das automatische Anhängen, um die Auffindbarkeit zu verbessern (#53640), basierend auf Benutzerfeedback.

Wir hoffen, dass die Einführung von automatischem Anhängen, dem NPM-Skripte-Explorer und Logpoints das Debuggen mit VS Code erleichtern wird. Wie immer freuen wir uns über Ihr Feedback. Wenden Sie sich also an uns auf GitHub oder @code auf Twitter.

Im Namen des VS Code-Teams: Happy Coding!

/Kenneth Auchenberg - @auchenberg auf Twitter