【JSの開発効率】爆速で快適に開発できる「debugger」を、多くの人が知らない説【上げませんか？】


![説.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365927/df0bf5d7-566b-c2ec-63cc-007396a3fd44.png)
Created By: [「説」ジェネレーター](https://www.sui-generator.tech/)

#あらすじ
最近、複数のコミュニティで目上のエンジニア様方と相談したり雑談したりしている中、
ひそかに気になっているコトがありました…。


( ´-\` ).｡o( *JavaScriptの開発で`debugger`つかわないの…？* )

経験が豊富で活躍してきたエンジニアの方々ほど、
`debugger`を使わない（または知らない）傾向が見られる気がしました。

おそらく、これまでの経歴で他言語をメインにしてプログラミングを行ってきたために、
「柔軟にデバッグしたい」という欲求すら生まれなくなってしまったのではないか…？と感じました。
（他言語のデバッグはかなり面倒な印象があるため。）

自分は生粋のJavaScriptっ子なので、`debugger`を使わないと効率がかなり落ちてしまいます。
この感覚を共有することで、お役に立てないかなと思い、記事を執筆することにしました。

↓少しばかり長い内容になるので、お忙しい方のために要約を用意しました↓

<details>
<summary>**３分で読める要約** [ click! ]</summary>
<div>
<br>
![debuggerおすすめですよ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365927/49a43333-22c9-59e8-78f0-b92b456f51f5.png)
<br>
※ 実は、この記事は`debugger`に対する熱い思いをつらつら綴っただけの、ただのネタ記事です。
※ この記事を読むことで、あなたの貴重な時間は確実に無駄になります。
　ご承知いただいた上で読み進めていただきますよう、お願いいたします。
</div>
</details>


#`debugger`とは？


```JavaScript:JavaScript
debugger;
```

ソースコードに`debugger`と書き込むことで、その箇所をブレークポイントにすることができる構文のことです。
> ブレークポイント（英: breakpoint）は、ソフトウェア開発のデバッグ作業において実行中のプログラムを意図的に一時停止させる箇所である。
By [Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AC%E3%83%BC%E3%82%AF%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88)

`debugger`が使えない他のプログラミング言語でブレークポイントを設置したい場合、
プログラムを停止させたい行に対して、ポチポチとクリックしていくことでブレークポイントを設置する方法が一般的です。
この方法はJavaScriptでも利用可能で、`debugger`を使った設置方法と区別する呼び名が存在しないため、
記事中では、上記の方法で設置したブレークポイントを「***ポチポチポイント***」と呼ばせていただきます。m(_ _)m


#`debugger`を使わない理由を聞いてみた


なぜ`debugger`を使わないのか伺ったところ、いくつか理由を教えていただけましたので、
これに対して感じた意見を述べさせていただきます。

いくつかの意見を伺いましたが、やはり使い慣れていない方が多いようで、
有効活用できていないだけなんじゃないかな、と思う意見も多かったです。


####JSは非同期処理の連続だから、ステップイン/オーバーによるデバッグは向かないのでは？
　→　それはむしろ**「`debugger`じゃないとダメな理由」**ですっ！！
　　　ステップ方式でデバッグしづらいからこそ、*ポチポチポイント*ではなく、
　　　気軽に大量にばら撒ける`debugger`でのデバッグが必要なのです！
　　　詳しくは、後の章で述べさせていただきます。

####便利なデバッグ/テストツールがあるから
　→　ツールを使う場合、導入作業の手間や、メンバーへのナレッジ共有の手間がかかります。
　　　それに対して、ソースコードに`debugger`と打ち込むのは１秒で終わります。
　　　さらに、`debugger`はJavaScriptの標準機能なので、導入作業やナレッジ共有は不要です。

　　　自分は`debugger`に不満を持ったことがないため、バニラJSでデバッグツールを使った経験がなく、
　　　具体的な反論ができず恐縮ですが、
　　　もしかしたら`debugger`さえあれば、必要なかったツールもあるのではないでしょうか…？
　　　~~（あえて少し煽ることで、`debugger`よりも便利なツールの情報が集まるという魂胆）~~

####消し忘れたときに大変なことになるから
　→　*ポチポチポイント*に比べたら、たしかにデメリットかもしれないですね。
　　　ただし、テストコードを書くのと比べれば、エディタのファイル内検索機能や
　　　一括置換機能をつかって総洗い出しができるので、むしろ対処がしやすい方かと思います。

　　　消し忘れたときどうなるのか、検証してみました。
　　　すると、ChromeDevToolsを閉じた状態では`debugger`は実行されず、
　　　処理が継続されるようです。
　　　なので、デメリットとしてはChromeDevToolsを開いているユーザーに、
　　　`debugger`の位置がバレてしまうといったところでしょうか。
　　　しかし、この仕様を逆手にとって、ChromeDevToolsを開いているユーザを
　　　`debugger`の無限ループにハメてしまう事もできるようです。


#`debugger`を使うメリット

*ポチポチポイント*方式でブレークポイントを設置するのは、とても面倒です。
例として、ChromeDevToolsを使ったやり方は下記のようになります。
1. 検証ツールを開く。
2. *Sources*タブを開く。
3. 該当のjsファイルを選択する。
4. ブレークポイントを設置したい箇所のコード行をクリックする。

この方法はさすがに面倒すぎるので、エディタの拡張機能などを使って、
コード上で直接*ポチポチポイント*する方法のほうがベターかとは思いますが、
それよりも`debugger`でブレークポイントを設置するほうが、よりお手軽に使えます！

また、*ポチポチポイント*の場合、
設置する際に、視点が コード → 行 → コード → 行 ... とZ型のように流れていくので
**思考が分散しやすい**のもデメリットです。
`debugger`の場合、視点はコードを書き込んでいるときと同じく上から下に流れていくだけなので、思考が分散しづらいです！

![スクリーンショット 2020-12-18 15.37.16 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365927/e4f92814-8948-5807-549b-42168458760d.png)
Created By: [PIXLR](https://pixlr.com/jp/)

#*ポチポチポイント* vs `debugger`

では***「オレの思考は分散しない！」***と思う人であれば、`debugger`を使うメリットは無いのでしょうか？
否、そんなことはないと思います！

以下のような状況には`debugger`が向いてます！

####コードをコンパイルするとき
minifyやフレームワークなどを導入した場合、
実際に実行されるコードは１行に凝縮されていたり、難読化が施されているため
*ポチポチポイント*の設置ができない状況になります。
そのため、ブレークポイントを使うこと自体諦めていた方もいらっしゃるかと思います。
もったいない！
`debugger`を使えば問題なくデバッグできますよ！

####複数の箇所で停止したいとき
上の章でも触れましたが、JavaScriptは処理がアッチに行ったりコッチに行ったりしやすいので、
ステップ方式で進めていくようなデバッグ方法は面倒だと思います。
そのため、ステップ方式ではなく、処理を確認したい箇所すべてにブレークポイントを設置して、
停止 → テスト → 再開 → 停止 → テスト → 再開 → ... と繰り返していく方法のほうが実用的です。

そのような使い方を*ポチポチポイント*で行う場合、
設置するときも除去するときも、狙った行までマウスを持っていって１つずつポチポチポチポチ…
…かなり煩わしくないですか？？

`debugger`にしておけば、該当箇所をファイル内検索して一括置換することで、いっきに削除できますよ！
 

####*ポチポチポイント*を設置したことを忘れそうなとき

*ポチポチポイント*を設置したはいいものの、別の箇所の開発や修正が舞い込んできて、すっかりそのことを忘れていたアナタ。
久々にファイルを触ったら、すっかり忘れていた*ポチポチポイント*が発動して処理が停止してしまった…
…イライラしませんか？（私はします！）

`debugger`を使っていれば、ソースコードをざっと見ただけでも`debugger`が設置されていることに気づけますし、
ディレクトリ内を一括検索すれば、全ての`debugger`を発見できますので、
ブレークポイントの存在を忘れてしまう確率は、ぐんと下がるかと思います！

####おなじ箇所の加筆/削除を何度も繰り返すとき

この記事を書くまで私は、ChromeDevToolsで*ポチポチポイント*を設置している状態で
タブが閉じられたりファイルが更新された場合、*ポチポチポイント*がどうなるのか知りませんでした。

確認してみたところ、タブが閉じられた後も*ポチポチポイント*は残り続けました。
そして、*ポチポチポイント*の設置された行が削除された場合、*ポチポチポイント*は前の行に移動するようでした。

しかし、*ポチポチポイント*の前後どちらに加筆/削除したいかなんて、
コードを書いてる本人しか知りえないですよね？
`debugger`であれば、ブレークポイントの前に処理を追加するか、後に処理を追加するか、
きちんと意識しながらコードを修正できるので、ストレスが軽減しますよ！

#`console.log()` vs `debugger`

さて、*ポチポチポイント*の設置よりも`debugger`のほうが使いやすいことについては、
しつこく言及させていただきました。
しかし、実は`debugger`の真のライバルは、*ポチポチポイント*ではなかったのでした…

前の章ではあえて書きませんでしたが、
**「`console.log()`で出力すればいい」**という意見がかなり多かったのです！！

しかし…いやいやいやいや…
**`console.log()`だけでは絶対に不十分です！**
例としてカンタンに思いつくケースを挙げてみました。



####変数（プロパティ）がうまく出力できないとき
`console.log()`で出力した変数が想定した値とまったく違ったり、そもそも`not defined`だったことなどありませんか？
そんなとき、`debugger`で止めてさえいれば、本当に出力したかった値はどこにいったのか、
探すのもカンタンだったのではないでしょうか？

ChromeDevToolsでJavaScriptを実行する場合、
`console.log()`と入力しなくても、変数名を叩くだけで値を出力してくれますし、
存在するプロパティ名であれば、予測変換してくれますので、デバッグの体感速度は数倍にも跳ね上がります！！

何度も`console.log()`しそうな予感がするならば、
最初から`debugger`で止めてしまった方が、絶対に早いのです！

####何度も試行錯誤したいとき
確かに`console.log()`でも、狙ったスコープ内で、狙ったタイミングの変数の値を確認できます。
しかし、状況に応じて複数の変数の値を確認したい場合や、複数の関数の実行結果を確かめたい場合はどうでしょうか？

`console.log()`で値を確認してみて、他にも確認したいことがでてきたら、
コードを修正して、画面を更新して、試して、
コードを修正して、画面を更新して、試して…　延々と繰り返すのは効率が悪くないですか？
`debugger`で止めてしまえば、コードの修正をしなくても、期待した結果を得られるまでいくらでもコードをいじり倒すことが出来ます。
この快適さを知ってしまえば、ただconsoleに出力するだけのデバッグなんて、二度とできない身体になりますよ！（嘘）


#まとめ
いかがですか？
`debugger`を知らなかったアナタも、`debugger`を食わず嫌いしていたアナタも、
すっかり`debugger`に興味が湧いてきたのではないでしょうか？

みなさんも、私と一緒に`debugger`を使いこなす一流の**デバッガラー（debuggerer）**を目指しましょう！

また、*ポチポチポイント*の良さを知ってる**ポチー・ポッター**の皆様の意見もどしどしお待ちしてます！
<br>
※ この記事は、`debugger`に対する熱い思いをつらつら長く綴っているだけのただのネタ記事でした。
※ 読者の皆様の貴重な時間をこのような記事で消費させてしまったことを、謹んでお詫び申し上げます。

<br>
　　\\<b>\\　<FONT COLOR=red>M</FONT> <FONT COLOR=orangered>e</FONT> <FONT COLOR=orange>r</FONT> <FONT COLOR=gold>r</FONT> <FONT COLOR=yellowgreen>y</FONT>　<FONT COLOR=green>C</FONT> <FONT COLOR=seagreen>h</FONT> <FONT COLOR=mediumturquoise>r</FONT> <FONT COLOR=cyan>i</FONT> <FONT COLOR=deepskyblue>s</FONT> <FONT COLOR=royalblue>t</FONT> <FONT COLOR=slateblue>m</FONT> <FONT COLOR=darkorchid>a</FONT> <FONT COLOR=hotpink>s</FONT> <FONT COLOR=deeppink>!</FONT>　/</b>/
　　![christmas_line5_character.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365927/e6a2f68e-b274-4947-3cf6-dae616e0d1ac.png)

#補足情報

####ChromeDevToolsのデバッグ機能について
ChromeDevToolsにも`debugger`と同じくらい便利なデバッグ機能がたくさんあります。
申し訳程度に挙げてみますので、ご存知なかった方はぜひ調べてみてください！

- エラーが出たときだけ処理を停止する **Pause on exception 機能**
- DOMに変更が加えられたときだけ処理を停止する **Break on 機能**
- 特定の値をリアルタイムに監視する **Create live expression 機能**


####Vue.jsで`debugger`を使う方法
Vue CLIで環境構築した際、debuggerがデフォルトで使用禁止になるようです。
設定を解除する方法を最近みつけたので、関連記事として共有させていただきます。
[Vue CLIでdebuggerを使えるようにする方法
](https://qiita.com/H40831/items/2dddcbd8ba7943e9c34b)