ログポイントと自動アタッチの導入

2018年7月12日 Kenneth Auchenberg、@auchenberg

過去数ヶ月間、Visual Studio Code でのデバッグ体験の向上に努めてきました。この投稿では、デバッグについてどのように考えているか、ユーザーから寄せられたフィードバック、そして VS Code でデバッグをより簡単にするために講じている手順についてお話しします。

VS Code の開始以来、デバッグはソースコードを記述および編集する場所、つまりエディタに不可欠な部分であるべきだと考えているため、統合されたデバッグ体験を搭載して出荷してきました。

VS Code のデバッグ体験は、Debug Adapter Protocol (DAP) を介して、Debug Adapter (DA) と呼ばれる特定の種類の VS Code 拡張機能と通信する汎用デバッガー 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 のデバッガーを接続する方法のレシピです。

起動構成の価値は、反復可能でプロジェクトやチームと共有できる構成を作成することで、適切なデバッグパラメータを使用してアプリを起動する際の認知的なオーバーヘッドの一部を軽減する方法を提供することです。

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

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

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

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

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

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

観察: 従来のデバッグワークフローは、プログラムロジックを検査するために実行を遅くすることに最も焦点を当てていますが、ログワークフローは通常、プログラムの状態と、アプリケーションの通常の実行中にそれがどのように変化するかを検査することを含みます。ここでの基本的な観察は、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 スクリプトがある場合、これを自動的に検出し、デバッガーを起動するデバッグアクションを提供します。以下に示すとおりです。

ログポイントの導入

ログが重要なデバッグ手法であるという学びに基づいて、既存のデバッグ体験に状態検査を追加する機会があると考えました。VS Code の3月のイテレーションで、ログポイントと呼ぶデバッグ機能の最初の実装をリリースしました。

ログポイントは、デバッガーに「中断」する代わりに、メッセージをコンソールにログするブレークポイントのバリアントです。

ログポイントの概念は新しいものではなく、過去数年間、Visual Studio、Edge DevTools、GDBなどのツールで、トレースポイントやログポイントといったいくつかの名前で、この概念の異なる種類が見られました。

ログポイントを使用する理由と時期

ログポイントは、多くの場合、アプリケーションの特定の部分で実行を停止したくないが、代わりにアプリケーションの寿命全体で状態がどのように変化するかを検査したいという観察に基づいています。

ログポイントを使用すると、アプリケーションの起動前にログステートメントを追加したかのように、オンデマンドのログステートメントをアプリケーションロジックに「注入」できます。ログポイントは実行時に注入され、ソースコードに保持されないため、事前に計画する必要はなく、必要なときにログポイントを注入できます。もう1つの良い利点は、デバッグが終了した後にソースコードをクリーンアップすることを心配する必要がないことです。

JavaScript 開発者にとって、これはもはやconsole.logを置き去りにすることを心配する必要がないことを意味します –– ログポイントを使用するだけです！さらに良いことに、console.logとログポイントを組み合わせることができます。console.logがすでに存在するソースコードのブロックにログポイントを挿入すると、デバッグコンソール内に両方の種類のログステートメントが表示されます。

クラウド コンテキストでのログポイント

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

Azure 上の Node.js でのログポイントの使用方法の詳細はこちらをご覧ください。

サポートされている言語

VS Code でログポイントが最初にリリースされて以来、VS Code デバッグアダプターによる採用が増加しており、現在、以下の言語でログポイントがサポートされています

• Node.js デバッガー
• Chrome デバッガー
• Firefox デバッガー
• Microsoft Edge デバッガー
• React Native デバッガー
• Python デバッガー
• Dart デバッガー
• Lua デバッガー
• Java デバッガー
• メインフレーム用デバッガー

VS Code のログポイント

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

次のステップ

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

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

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

/Kenneth Auchenberg - Twitter の @auchenberg