コードのデバッグにデバッガーを使用する理由は何ですか?これで色々なソースコードが読めるようになります！

多くの学生は、デバッグにデバッガーを使用する必要がある理由を知りません。console.log は機能しませんか?また、デバッガーの使い方はわかっていますが、まだ理解できないコードが多く、複雑なソースコードをデバッグするにはどうすればよいですか?この記事では、これらのデバッグ ツールを使用する必要がある理由について説明します。

console.log とデバッガー

ほとんどの学生はデバッグに console.log を使用し、コンソールに表示したい変数値を出力すると思います。 [推奨される関連チュートリアル: nodejs ビデオ チュートリアル 、プログラミング教育 ]

これはニーズを満たすことができますが、オブジェクトの印刷に関しては機能しません。

たとえば、Webpack ソース コード内のコンパイル オブジェクトの値を確認したい場合は、次のように出力します。

しかし、次のことがわかります。オブジェクトの値もオブジェクトです。展開されませんが、[オブジェクト] [配列] 文字列が出力されます。

さらに致命的なのは、印刷が長すぎるとバッファ サイズを超えてしまい、ターミナルに不完全なメッセージが表示されることです。

デバッガを使用して実行すると、 in これらの問題が解消されることを確認するには、ここにブレークポイントを作成します。

#一部の学生は、単純な値を出力するときに console.log を使用するのが依然として非常に便利であると言うかもしれません。ああ。

例:

本当に?

その場合、ログポイントを使用することをお勧めします:

##コードがここで実行されると、次のように出力されます:

そして、コード汚染がありません。console.log を使用する場合、デバッグ後にコンソールを削除する必要はありませんか?

ただし、ログポイントは使用されません。これはコード内ではなく、単なるブレークポイント設定です。

もちろん、最も重要なことは、デバッガーが呼び出しスタックとスコープを確認できることです。

1 つ目はコール スタックで、コードの実行ルートです。

たとえば、このアプリの関数コンポーネントでは、この関数コンポーネントのレンダリングが workLoop、beginWork、および renderWithHooks のプロセスを経ることがわかります。

これをクリックすると、コール スタックの各フレームを見て、どのようなロジックが実行され、どのようなデータが使用されているかを確認できます。たとえば、この関数コンポーネントのファイバー ノードが表示されます:

#次にスコープがあります。各スタック フレームをクリックすると、それぞれのスコープ内の変数が表示されます。 function:

デバッガーを使用して、コードの実行パスと各ステップのスコープ情報を確認します。 console.log を使用しますか?

変数値のみが表示されます。

取得される情報量の違いは、単なるわずかな違いではありません。デバッグ時間が長くなるにつれて、他の人はコードの実行プロセスをどんどん明らかにしていきますが、console.log を使用している場合はどうでしょうか。 ?コードの実行パスが見えないため、状況は同じです。

したがって、ライブラリのソース コードをデバッグする場合でも、ビジネス コードをデバッグする場合でも、Node.js または Web ページをデバッグする場合でも、デバッガ ブレークポイントを使用することをお勧めします。console.log の使用はやめてください。ログを印刷したい場合は、LogPoint を使用できます。

また、問題のトラブルシューティングを行う場合は、デバッガーを使用して例外ブレークポイントを追加できます。そうすれば、例外がスローされるポイントに到達するとコードが中断されます。

コール スタックを参照して、エラーの前に行われたコードを分類することができ、スコープを通じて各変数の値を確認できます。

これらを使えば、エラーのトラブルシューティングが簡単になるのではないでしょうか?

そして、console.log を使用しますか?

何もありません。推測することしかできません。

パフォーマンス

前述したように、デバッガーはコードの実行パスを確認できますが、コードの実行パスは曲がりくねっていることがよくあります。

たとえば、React は各ファイバー ノードを処理し、各ノードは beginWork を呼び出します。処理後、次のノードが処理され、beginWork が再度呼び出されます:

小さな道路を通ってから幹線道路に戻り、別の小さな道路を通過したのと同じように、デバッガを使用すると、現在の小さな道路の実行パスのみが表示され、他の小さな道路は表示されません。小さな道路のパス:

現時点では、パフォーマンス ツールと組み合わせることができます。パフォーマンス ツールを使用して、コード実行の全体像を確認し、次に、デバッガーを使用して、各コードの実行パスの詳細を調べます。

ソースマップ

ソースマップは非常に重要です。実行したコードはコンパイルおよびパッケージ化されたコードであり、基本的には読み取ることができないためです。この種のコードをデバッグしても意味がありません。sourcemap を使用すると、元のソース コードを直接デバッグできます。

たとえば、vue では、ソースマップを関連付けた後、ts ソース コードを直接デバッグできます:

nest .js は次のとおりです:

ソースマップを使用しない場合は、ソース コードを理解したいと考えますが、デバッグしているのはコンパイルされたコードです。それ？

一行読む

前述のデバッガ、パフォーマンス、およびソースマップは、コードをデバッグするためのツールにすぎません。デバッグ ツールを知っていてもまだ実行できる場合はどうすればよいですかコードが読めないの？

これは不可能だと思います。

なぜそんなことを言うのですか？

react ソース コードを例として挙げます。

switch ケースを理解できますか?三項演算子って理解できますか？関数呼び出しは理解できましたか？

コードのすべての行を読み取ることができ、コード全体はこのコード行で構成されているのではありませんか?

さらに、ステップ実行してコードの実行パスを知ることができます。

コードの各行は理解できるのに、すべてをまとめて読むことができないのはなぜですか?

コードが多すぎて時間が足りないのでしょう。

最初は1行、1関数、小さな関数の実装プロセスを理解し、少しずつ積み上げて理解すればするほど、より多くのコードを理解できるようになります。

概要

この記事では、デバッグ ツールを使用する理由と、複雑なコードを理解する方法について説明します。

console.log には欠点が多すぎます。大きいオブジェクトを完全に印刷できない、端末バッファを超えてしまう、オブジェクト属性を拡張できないなど、すべての人に使用することはお勧めできません。印刷したい場合でも、LogPoint を使用できます。

デバッガを使用すると、コードの実行パスであるコール スタック、各スタック フレームのスコープを確認でき、コンソールの実行中にコードが最初から現在までに何を経験したかを知ることができます。 .log は変数の特定の値のみを知ることができます。

さらに、エラーを報告するときに、例外ブレークポイントを使用してコードの実行パスを整理し、エラーの原因をトラブルシューティングすることもできます。

ただし、デバッガーでは実行パスが 1 つだけ表示されます。パフォーマンスを使用してコード実行のプロセス全体を記録し、デバッガーを使用してパスの 1 つの実行の詳細を詳しく調べることができます。

さらに、元のソース コードをデバッグすることのみが意味を持ちます。そうでない場合、コンパイルされたコードをデバッグすると、情報が大幅に少なくなります。 SourceMap を使用すると、Vue、React のソース コードであっても、Nest.js、Babel などのソース コードであっても、ソース コードに接続できます。

デバッグ方法を学んだ後は、さまざまなコードをデバッグできます。コードの各行は基本的な構文であり、理解できるため、理解できないソース コードはありません。理解できない場合は、単に理解できる可能性があります。コードが多すぎるため、コードを 1 行ずつ、関数ごとに読み、各関数の実装を明確にし、ゆっくりと蓄積するのにさらに忍耐が必要です。

Debugger、Performance、SourceMap などに基づいたデバッグ コードをマスターすると、さまざまな Web ページや Node.js コードをデバッグできるようになり、さまざまなソース コードを読んで理解できるようになります。 [推奨される学習: JavaScript ビデオ チュートリアル ]

以上がコードのデバッグにデバッガーを使用する理由は何ですか?これで色々なソースコードが読めるようになります！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。