18日目 Chrome 開発者ツール 編「開発者ツールを征するものが、開発を征する」 2017年圧倒的成長振り返り一人アドベントカレンダー


この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 18日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。18日目の今日は、仕事としての Chrome 開発者ツール 編です。

開発者ツールを征するものが、開発を征する

どこまで自分の中で正確にコードを書いたとしても、最後はブラウザがどう解釈するのかで挙動が全て決まる。それがフロントエンドの世界の特徴だと思います。どんなに優秀なエンジニアでも IE 自体の挙動を変えることはできず、彼に従うしかありません。そのため開発者ツールを使いこなして、ブラザ内で起きていることの現状を正確に把握することこそが、開発の基盤になるということを痛感しました。

大きく分けて DOM Element (HTML, CSSの担当する領域) の状態と JavaScript の状態に分けられる

http://better-than-i-was-yesterday.com/google-chrome-devtool/

Chrome 開発者ツールでは、主に DOM Element の状態と JavaScript の状態の、二つの領域が重要だと感じています。(もちろんパフォーマンスやネットワークのタブなども重要なのですが、まずはこの二つの領域で正常な挙動が達成されなければ、それらのタブを確認するまでもありません。そいうう意味において。)

Elements タブで HTML と CSS を。Console と Source タブで JavaScript について確認します。

また Elements タブ内の EventListers は JavaScript の領域とつながっています。同様に Console のコマンドや、Source の EventLister Breakpoints などは Element と繋がっています。

ので、基本的には Elements タブと Source タブの二枚を行き来しながら、console タブは esc キーを押して出てくる下部のタブでデバッグする、という形を自分はとっています。

JavaScript のデバッグについて

Source タブを使った JavaScript のデバッグは React 開発を業務にしてから初めて行いました。

今までのように自分で書いたソースのデバッグであれば、正直書いたソースを見直す方が早かったのですが、他人が書いた API が入り組んだソースの場合、やはりこの Source タブを使ったデバッグが有効だと感じています。というのも、どの値がどのタイミングで変わるのかわからないものがたくさんあるので、それはやはりデバッグしながら詰めていくしかないのかなと。刻々と変化する変数を、クリアーに見ていけるのは Source タブならではだなと。

今後

開発者ツールの使い方をまとめています。動画コンテンツも増やそうと思っています。レッツユーチューバー。

http://better-than-i-was-yesterday.com/google-chrome-devtool/

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 18日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。18日目の今日は、仕事としての Chrome 開発者ツール 編です。

Leave a Reply

Your email address will not be published. Required fields are marked *