https://qiita.com/kazukinagata/items/e1ef8f5fa880befa2695?utm_source=Qiitaニュース&utm_campaign=3dad64ba93-Qiita_newsletter_509_04_06_2022&utm_medium=email&utm_term=0_e44feaa081-3dad64ba93-34388437
ここのところちょっと時間に余裕があり、暇を見つけてはQiitaの質問に答えるという取り組みをやっています。以前StackOverflowでも同様の取り組みをちょっとだけしてたことがあります。
9日間で35個の質問に回答してみて、正直に思うのは「質問の質が悪すぎるなー」ということです。ただ、どう質が悪いのか上手く言語化できず悶々としていました。
そんな折、今朝googleのおススメ記事に飛び込んできたQuaraのこちらの回答を読んで、「これこれ！こういうことよ！」という気持ちになったため、これから質問する人に向けてこの内容を少し嚙み砕いてまとめてみます。
（自分をベテランと言っていいのかはさておき）日頃からコードを書いていると、デバッグには、その時使っている言語やフレームワークによらず、ある程度の行動パターンがあることに気付いてきます。
デバッグには難しいDebuggerを駆使しなきゃいけないんじゃないの？と思われる方もいるかもしれませんが実はそんなことはなくて（中にはそういう方もいると思いますが）、自分の場合Debuggerはほとんど使わず、Chromeの開発ツールと、jsならconsole.log、pythonならprint、Goならfmt.Print、Rubyならbinding.pryでほとんど事足ります。
自分が何か問題に直面した場合の行動パターンはおよそ次のような感じです。
エラーメッセージの表示場所は、サーバ上で実行されるものであればターミナルです。
Webクライアントのバグの場合、ブラウザの開発ツール（自分はChrome派）を見ることが多いです。htmlやcssに関してはElementsタブを見ます。例えばcssのstyle属性にタイポがあった場合、画像のように黄色いアイコンで不適切な属性を教えてくれます。
jsに関しては、ConsoleタブやNetworkタブをよく見ます。Consoleタブにはjs実行時のエラーがあれば、意図的に握りつぶされていない限り、エラーメッセージが表示されます。
Networkタブではブラウザが実行しているhttpリクエストを確認できるため、例えば使用しているAPIから4xxや5xx系のエラーが返ってくる場合に、リクエストヘッダやレスポンスの内容を確認するために利用します。
この場合、コード実行がそこまで到達していないことを疑います。例えば、if、switch、while breakなどで意図せず処理が抜けてしまっていることが想定されます。
すごく初歩的なバグのようですが、実はどんなにベテランでも作ってしまうバグ第一位だと思います。
あるいは、jsやpythonなどの動的型付け言語の場合、変数を意図せず上書きしてしまっている、配列（list）やオブジェクト(dict)などミュータブルなオブジェクトをイミュータブルのように扱っている、というのもありがちなパターンです。