JavascriptのChromeでのデバッグ方法個人的まとめ2016

More than 1 year has passed since last update.

はじめに

Javascript開発でよく使ってるデバッグ方法についての個人的なまとめです。
当たり前の事ばかりですが、これからJavascript開発をやる方や興味がある方に少しでもお役に立てればと思います。

デバッグの鉄板 console.log

Javascriptの開発でconsole.logを使わない人を探すほうが難しいくらいだと思います。

sample.js
console.log('コンソール出すぜ');

実行結果

ChromeのDeveloper ToolsのConsoleタブで確認

スクリーンショット 2016-01-26 10.14.39.png

consoleでデバッグ時の色やアイコンを表示

console.logだと単なるlogですが、用途によってエラーや警告などを出すことが可能です。
これによって、複数のconsoleを設置した場合に何の情報なのか?が分かりやすくなります。

console.error

エラーハンドリングで引っかかった時にはこれを使っています。

sample.js
console.error('エラー出すぜ');

実行結果

スクリーンショット 2016-01-26 10.18.14.png

console.warn

個人的にはあまり使っていません。
処理は続行出来るものの、100%の期待動作でない場合とかで使っていましたが、結局期待動作ではないので、厳しめにconsole.errorにしてしまう事がほとんどです。

sample.js
console.warn('警告出すぜ');

実行結果

スクリーンショット 2016-01-26 10.19.37.png

console.info

console.logと一線を画したい時に使っています。
長いメソッドの中で値の変化などを追いたい時に、強調すべきポイントとかで使ったりしています。

sample.js
console.info('情報出すぜ');

実行結果

スクリーンショット 2016-01-26 10.29.28.png

こんな感じで、途中で一番見なければいけない値を見落とさないように使ってます。
(値3の内容が一番のポイントである場合)
スクリーンショット 2016-01-26 10.35.32.png

配列はconsole.tableが見やすい

以下のような配列があったとします。

sample.js
var array=[{
  key1:'value1',
  key2:'value2',
  key3:'value3',
}];

配列の中身をconsole.logすると、こんな感じになります。

sample.js
console.log(array);

実行結果

スクリーンショット 2016-01-26 10.50.57.png

ちょっと見難いですよね。

これを解決するのがconsole.tableです。

sample.js
console.table(array);

実行結果

スクリーンショット 2016-01-26 11.04.42.png

かなり見やすくなりました!

実行時間を計測

プログラムを書く上で実行速度は大切です。
Javascriptでももちろん処理速度を計測する方法があります。

sample.js
console.time('timer');

// 計測したい処理を記載

console.timeEnd('timer');

実行結果

スクリーンショット 2016-01-26 11.08.47.png

関数の呼び出し元を調べる

console.traceを使います。

ここまで紹介したconsole兄弟の最後の紹介です。
その他、consoleについてはまだまだたくさんあるのでご興味ある方は調べてみてください。

sample.js
function saba() {
  function aji() {
    function maguro() {
      // console.trace実行
      console.trace();
    }
    maguro();
  }
  aji();
}

// さば function実行
saba();

実行結果

スクリーンショット 2016-01-26 16.23.38.png

このようにどのメソッド経由か?が分かります。

ブレークポイントを使う

ブレークポイントを使用すると、プログラムの実行中に途中で停止、再開が行えます。

Developer ToolsのSourceタブを開いて、ブレークポイントを仕込みたい行をクリックします。

スクリーンショット 2016-01-26 11.27.54.png

この状態でページをリロードすると、設定したブレークポイントで処理が止まるので、ステップ実行が可能です。

ブレークポイントからの処理再開

ブレークポイントから処理を再開する場合は、ブレークポイントをセットしたSourceタブの右側に以下のようなボタン群があるかと思いますが、こちらから実行していきます。

スクリーンショット 2016-01-26 13.47.41.png

処理再開

そのままです。これを押すと実行が再開されます。

ステップオーバー

関数呼び出しがあった場合でも、関数へ処理遷移しないで次の行に進みます。

ステップイン

関数呼び出しがあった場合、その関数へ処理遷移をして、関数内の処理に進みます。

ステップアウト

関数が終了するまで実行し関数を抜けます。

画面上からの操作

ブレークポイントを設定した場合、Developer Toolsだけでなく、画面上にも
処理の再開とステップオーバーのボタンが表示されるので、そこからの操作も可能です。

スクリーンショット 2016-01-26 13.37.29.png

実行中に値の変更

ブレークポイントをセットして、sampleArray[1,2,3,4]をセットします。
通常に実行すると、console.logの結果は[1, 2, 3, 4]となるはずです。

スクリーンショット 2016-01-26 16.52.46.png

Developer Tools右側のScopeのsampleArrayには

Array[4]
0:1
1:2
2:3
3:4

とセットされている事が確認できます。

スクリーンショット 2016-01-26 16.55.14.png

このScope内のsampleArray[100,200,300,400]と変更してみます。

スクリーンショット 2016-01-26 16.56.38.png

この状態で次に処理を進めます

すると、Sourcesタブ内の結果も[100,200,300,400]となり、
スクリーンショット 2016-01-26 16.57.03.png

さらにConsoleタブの処理結果も以下のようになります。

スクリーンショット 2016-01-26 16.58.23.png

このようにブレークポイントをセットして、ステップ実行しながら値を変更していく事が可能です。

これにより、開発時にイレギュラーな値を渡してテストしながらの実装なども容易に行えるようになります。

Networkで通信をチェック

どういったHTTP通信がされているのか?
ちゃんとステータスコードやレスポンスが返ってきているのか?を確認する場合に、Networkタブの利用をします。

以下、http://qiita.com/ にアクセスした例です。
ちゃんと200 OKが返ってきている事が分かります。

スクリーンショット 2016-01-26 14.18.55.png

デフォルトでHeadersタブが開いていますが、Responseタブを開くと以下のようにHTMLファイルが表示されている事が分かります。

スクリーンショット 2016-01-26 14.20.48.png

実際に受け取るレスポンスとして、Javascriptの開発の場合、JSON形式でのAPIレスポンスなどが多いかと思いますが、その場合はこのResponseのタブにJSON形式のデータが表示されます。

生の通信はDHC

通信処理を書いている時に、コードが悪いのか、通信のパラメータが不正なのか?
問題の切り分けをする為には通信したい内容をJavascriptのコード外で実行するのが最適です。

そこで使うのがDHCというChromeのエクステンションです。

インストールURL
https://chrome.google.com/webstore/detail/dhc-resthttp-api-client/aejoelaoggembcahagimdiliamlcdmfm

インストールするとChromeのアプリのところにアイコンが表示されているはずなのでこちらをクリックします。

スクリーンショット 2016-01-26 14.01.39.png

使い方

リクエスト先の設定

スクリーンショット 2016-01-26 14.08.51.png

HTTPまたはHTTPSが選択可能です。

ヘッダーのセット

スクリーンショット 2016-01-26 14.10.13.png

リクエストヘッダーのセットをします。

メソッドの選択

スクリーンショット 2016-01-26 14.11.25.png

リクエストBODYの入力

スクリーンショット 2016-01-26 14.12.02.png

リクエスト送信

スクリーンショット 2016-01-26 14.13.09.png

レスポンス

HTTPのステータスコードとレスポンス内容が返ってきます。
また、リクエスト時内容もレスポンスのところに表示されます。

スクリーンショット 2016-01-26 14.14.07.png

クッキーはEdit This Cookie

クッキーの閲覧、操作はEditThisCookieを使っています。
とにかく使いやすくて、個人的にはクッキーのデバッグはこれ以外に考えられません。

インストールURL
https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=ja

使い方

インストールして有効にしたら、Chromeの右上にクッキーのアイコンが表示されているはずなので、これをクリックします。

スクリーンショット 2016-01-26 14.25.26.png

クリックすると、そのサイトのクッキーの一覧が表示されます。
あとはデバッグ時に削除したり、値を変えたり色々とやってみてください。

スクリーンショット 2016-01-26 14.26.34.png

ローカルストレージの操作

クッキーだけでなく、ローカルストレージを使用するサービスも最近増えていると思います。
ChoromeのDeveloper Toolsでももちろん使えます。

ResourcesタブのLocal Strageから自由にKeyとValueの変更、追加、削除が行えます。

スクリーンショット 2016-01-26 14.39.57.png

同様にSession Strageについてもここから操作が行えます。

あきらめないで!minifyされたソース

Javascriptで開発していると、minifyされたソースをお目にかかる機会が多いと思います。

スクリーンショット 2016-01-26 14.28.45.png

デバッグしていたらminifyのソースが関連していそうだ。しかし、見れない・・・。
と諦める事はありません。

Sourceタブの左下にある
スクリーンショット 2016-01-26 14.30.53.png
をクリックしてみてください。

すると、ファイルが :formattedという形式で展開されます。

スクリーンショット 2016-01-26 14.32.00.png

(AngularJS固有) ng-inspector

普段AngularJSを書く機会が多いのでこちらも紹介します。

インストールURL
https://chrome.google.com/webstore/detail/ng-inspector-for-angularj/aadgmnobpdmgmigaicncghmmoeflnamj

使い方

インストールして有効にしたら、Chromeの右上にAのアイコンが表示されているはずなので、これをクリックします。

スクリーンショット 2016-01-26 14.35.11.png

AngularJSで書かれたサイトの場合、$rootScope,$scopeの中身がここから確認出来ます。

https://angularjs.org/ にアクセスした例
スクリーンショット 2016-01-26 14.36.43.png

ササッと見た目を修正出来るElements

レイアウトの確認MTGなんかで、「ここ、もうちょっとこんな感じのほうが」など意見が出る事があると思います。

そんな時にいちいちソースを開いてというのも面倒なので、ElementsタブでHTMLを変更して対応したりしています。

http://qiita.com/ をElementsタブで開いた一部
スクリーンショット 2016-01-26 14.44.11.png

画面上は
スクリーンショット 2016-01-26 14.45.25.png
と表示されています。

ここの

sample.html
<h2>プログラミング知識を共有しよう。</h2>

<h1>にして、共有シェアに変えてみます。

スクリーンショット 2016-01-26 14.46.23.png

実行結果

すると、変えたタイミングで画面上も変更されます。

スクリーンショット 2016-01-26 14.47.14.png

今は単純なタグと文字の置き換えだけですが、もっと複雑な事も出来るので、ブレストやデザイン、レイアウトに関するMTGで結構役に立ちます。

困ったらソースを読む

個人的によくあるのが、使っているライブラリが意図する動作をしてくれない。
ですが、ライブラリのコードもJavascriptで書かれているので、頑張ってコードを追ってみましょう。

変にトライ&エラーを繰り返すよりもコードを読んでしまって、「ここはこういうパラメータじゃないと動かないのか、間違ってたわー。。」「このライブラリはこういう用途はできないのか。。」と結論を早く導き出せる事もあります。

また、自身が関わっているプロダクトのコードであれば、書いた人に聞くのが一番の近道デバッグだと思います。

まとめ

ChromeのDeveloper Toolsは強力で、色んなツールもあるので個人的にデバッグは何とかなっているかなあという感覚です。
日々進歩していくはずなので、またどこかの機会でまとめようと思います。

完全に個人的なメモですが、どこかでお役に立てたら幸いです。

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.