Logpoints と自動アタッチのご紹介

2018 年 7 月 12 日 Kenneth Auchenberg, @auchenberg

ここ数か月、Visual Studio Code でのデバッグエクスペリエンスの向上に努めてきました。この記事では、デバッグについてどのように考えているか、ユーザーから寄せられたフィードバック、そして VS Code でのデバッグをより簡単かつシンプルにするために講じている手順について説明します。

VS Code の開始以来、デバッグはソースコードを作成および編集する場所、つまりエディターに不可欠な部分であるべきだと考え、統合されたデバッグエクスペリエンスを提供してきました。

VS Code のデバッグエクスペリエンスは、Debug Adapter Protocol (DAP) を介して特定のタイプの VS Code 拡張機能 (Debug Adapter (DA) と呼ばれます) と通信する汎用デバッガー UI によって強化されています。DA は実際のデバッガーと通信し、DAP とランタイム固有のデバッグプロトコルまたはデバッガーの API の間で変換を行います。

これは、VS Code のコアが特定のデバッガーから完全に分離されていることを意味し、このアーキテクチャにより、Debug Adapter が利用可能であれば、VS Code はあらゆるものをデバッグできます。図に示すように。

観察と課題

今日、VS Code で定期的にデバッグを行っている多くの満足している開発者がいますが、私たちの使命の一部として、デバッグをより簡単にして、より多くの開発者が利用できるようにしたいと考えています。

この目的のために、VS Code でのデバッグの課題をより深く理解し、一部の開発者がデバッガーをまったく使用していない理由を学ぶための対話を始めました。

観察結果は次のとおりです

デバッグ構成は正しく理解するのが難しい

VS Code は汎用エディターであり、汎用デバッガーを備えており、特定のスタックやランタイムに特化していません。このため、すべての人に有効な偏りのあるデフォルトのデバッグ構成を提供することはできません。

つまり、VS Code では、デバッガーの設定を構成するだけでなく、適切なパラメーターなどを指定してランタイムをどのように起動するかを指定する必要があります。

これが正しく理解するのが難しいことは認識していますが、すべての人のデバッグ構成を完全になくす方法があるとは考えていません。ただし、デバッグ構成は簡略化でき、コンテキストによっては最小限に抑えることができると確信しています。

これについては後ほど詳しく説明します。

起動構成とアタッチ構成の間の混乱

VS Code には、デバッグの 2 つのコアコンセプトがあります。起動とアタッチです。これらは、2 つの異なるワークフローと開発者のセグメントを処理します。ワークフローによっては、プロジェクトに適した構成タイプを知ることが混乱する場合があります。

ブラウザ DevTools のバックグラウンドを持つ場合、ブラウザインスタンスはすでに開いているため、「ツールから起動する」という概念に慣れていません。DevTools を開くと、単に開いているブラウザータブに DevTools をアタッチしています。一方、Java のバックグラウンドを持つ場合、エディターが Java プロセスを起動し、エディターが新しく起動されたプロセスにデバッガーを自動的にアタッチするのはごく普通のことです。

起動とアタッチの違いを説明する最良の方法は、起動構成を、VS Code がアタッチする前にデバッグモードでアプリを起動する方法のレシピと考え、アタッチ構成は、VS Code のデバッガーをすでに実行中のアプリまたはプロセスに接続する方法のレシピと考えることです。

起動構成の価値は、プロジェクトとチームで繰り返し使用および共有できる構成を作成することにより、適切なデバッグパラメーターを使用してアプリを起動する際の認知的なオーバーヘッドの一部をオフロードする方法を提供することです。

ただし、開発者にアプリケーションの起動方法について話を聞いたところ、パターンが見られ、1 つの重要な観察結果が得られました

観察: VS Code を使用している多くの開発者は、統合ターミナルを非常に気に入っており、コマンドラインツールに依存してアプリケーションを起動しています。多くの場合、ターミナルでコマンドを実行し、次にエディターからデバッガーをアタッチするというワークフローの方が自然です。これは、ブラウザーが起動された後に DevTools を開くのと似ています。

この観察結果は重要であり、多くのユーザーがエディターで完全な「魔法のような」起動エクスペリエンスを望んでいないことに気づきました。彼らは、エディターをソースコードを編集およびデバッグする場所として維持し、ターミナルを使用してアプリの起動、ビルドスクリプトの実行などを行いたいと考えています。これは、VS Code 内に統合ターミナルエクスペリエンスがある理由の 1 つです。機能的な優れた UI は、ターミナルと共存し、うまく統合されるべきだと考えているからです。

多くの開発者は、状態の変化を検査しているため、ブレークポイントを使用しません

開発者がアプリケーションをどのようにデバッグしているかを見ると、別の興味深いパターンも見られました。ブレークポイントの代わりにロギングを使用することです。

デバッグのためのロギングは新しい概念ではありませんが、観察結果は重要でした

観察: 従来のデバッグワークフローは、プログラムロジックを検査するために実行を遅くすることに最も重点を置いていますが、ロギングワークフローは通常、プログラムの状態とアプリケーションの通常の実行中に状態がどのように変化するかを検査することを含みます。ここでの基本的な観察は、2 つの手法が異なるデバッグ目的に使用されるということです。

この観察結果は、主に状態の管理の複雑さに対処する JavaScript 開発者にとって特に重要であり、これが ほとんどの JavaScript 開発者がスクリプトデバッガーを使用する代わりに、依然として console.log をソースコードに追加することを好む理由を説明する可能性があります。

Node プロセスへの自動アタッチ

一部の開発者が統合ターミナルを使用してデバッグセッションを起動する方法を検討したところ、独自の機会が生まれていることがわかりました。エディターと統合ターミナルから VS Code 内に持っているコンテキスト情報を活用することで、コンテキストを検出してデバッグの意図について推論することができ、これにより、Node.js 開発者にとって、はるかにシンプルなデバッグエクスペリエンスを提供できる可能性があります。

そこで、VS Code の 3 月のイテレーションで、Node 用自動アタッチと呼ばれる新機能をリリースしました。これにより、Node デバッガーは VS Code の統合ターミナルからデバッグモードで起動された Node.js プロセスに自動的にアタッチできます。

自動アタッチを有効にするには、コマンドパレットから [デバッグ: 自動アタッチの切り替え] コマンドを実行します。アクティブ化すると、ステータスバーからも自動アタッチを切り替えることができます。

この機能は、node --inspect で開始された Node.js プロセスをデバッグの意図として解釈するため、デバッグ構成を完全に排除します。統合ターミナルと組み合わせることで、開発者は独自の方法でアプリを起動でき、同時にデバッグ構成を排除できる、はるかにシンプルなデバッグエクスペリエンスになります。🎉

NPM スクリプトとデバッグ

多くの Node.js 開発者は、npm スクリプトに依存してアプリケーションを起動したり、デバッグセッションを開始したりしていますが、その点についても朗報があります。自動アタッチは npm スクリプトでも機能します。npm run debug を実行し、"debug" スクリプトが "node --inspect" または --inspect を含むその他のコマンドである場合、自動アタッチはそれを検出し、デバッガーをアタッチします 🎉

また、一部の開発者が npm スクリプトをより視覚的に見つけて実行したいと考えていることも認識していました。そこで、2018 年 4 月のイテレーションで、UI から直接 NPM スクリプトを参照して実行できる新しい NPM スクリプトエクスプローラーを追加しました。デバッグ構成を簡略化するための取り組みの一環として、デバッグ構成を作成しなくても、エクスプローラーから直接 Node.js デバッグを開始できるようにしました。

--inspect のようなデバッグ引数を含む npm スクリプトがある場合、これが自動的に検出され、ここに示されているようにデバッガーを起動するデバッグアクションが提供されます

Logpoints のご紹介

ロギングが重要なデバッグ手法であるという学習に基づいて、既存のデバッグエクスペリエンスに状態検査を追加する機会が見られました。VS Code の 3 月のイテレーションで、Logpoints と呼ばれるデバッグ機能の最初の実装をリリースしました。

Logpoint は、デバッガーに「ブレーク」するのではなく、代わりにメッセージをコンソールに記録するブレークポイントのバリアントです。

Logpoints の概念は新しいものではなく、過去数年間で、Visual Studio、Edge DevTools、GDB などのツールで、Tracepoints や Logpoints などのいくつかの名前でこの概念のさまざまな種類が見られました。

Logpoints を使用する理由とタイミング

Logpoints は、多くの場合、アプリケーションの特定の部分で実行を停止するのではなく、アプリケーションのライフタイム全体で状態がどのように変化するかを検査したいという観察に基づいています。

Logpoints を使用すると、アプリケーションを起動する前にアプリケーションにロギングステートメントを追加したかのように、オンデマンドロギングステートメントをアプリケーションロジックに「挿入」できます。Logpoints は実行時に挿入され、ソースコードには永続化されないため、事前に計画する必要はありませんが、必要に応じて Logpoints を挿入できます。もう 1 つの利点は、デバッグが完了した後、ソースコードをクリーンアップすることを心配する必要がないことです。

JavaScript 開発者にとって、これはもう console.log を残しておくことを心配する必要がないことを意味します。Logpoints を使用するだけです。さらに良いことに、console.log と Logpoints を組み合わせることができます。すでに console.log があるソースコードのブロックに Logpoint を挿入すると、デバッグコンソール内に両方のタイプのロギングステートメントが表示されます。

クラウドコンテキストでの Logpoints

Logpoints は、クラウドコンテキスト (または実際には任意のリモートコンテキスト) で特に役立ちます。アプリケーションを再デプロイしなくても、リモート環境にロギングを挿入できるからです。同様に重要なことは、Logpoints でスクリプトの実行を停止しないため、通常のブレークポイントで実行中のアプリケーションを停止する場合とは異なり、ユーザーに影響を与えないことです。

Azure 上の Node.js 用の Logpoints の使用方法の詳細については、こちらをご覧ください。

サポートされている言語

VS Code での Logpoints の最初のリリース以来、VS Code Debug Adapter による採用が拡大しており、現在、次の言語で Logpoint がサポートされています

• Node.js デバッガー
• Chrome デバッガー
• Firefox デバッガー
• Microsoft Edge デバッガー
• React Native デバッガー
• Python デバッガー
• Dart デバッガー
• Lua デバッガー
• Java デバッガー
• Mainframe 用デバッガー

VS Code の Logpoints

VS Code 用の Debug Adapter に Logpoint サポートを追加することに関心がある場合は、プロトコルの これらの変更をご覧ください。また、上記のデバッグアダプターを見て、各ランタイムが Logpoints をどのように実装することを選択したかを確認することもできます。

次のステップ

今のところは以上ですが、これで終わりではありません。7 月のイテレーションでは、ユーザーからのフィードバックに基づいて、検出可能性を支援するために自動アタッチの改善に取り組んでいます (#53640)。

自動アタッチ、NPM スクリプトエクスプローラー、Logpoints の導入により、VS Code でのデバッグが容易になることを願っています。いつものように、フィードバックをお待ちしておりますので、GitHub または Twitter の @code までご連絡ください。

VS Code チームを代表して: ハッピーコーディング!

/Kenneth Auchenberg - Twitter の @auchenberg