前置き

「そもそもどうやってデバッグすればいいの」という質問に答えるために、自身がデバッグしているときの思考やフローを的まとめて見ました。
煮詰まったときの対処法もまとめてます。
※ webアプリケーションを想定してます。

#【開発エラー時対処フロー】

原因が直感的(経験的)にわかるとき => そのまま修正
直感的にわからないとき
- エラーメッセージが表示されているとき
  - エラーメッセージをよく読んで意味を理解する
  - 理解できない場合はググって理解する
  - 必要とあれば、書き方があっているかをドキュメントなどを見て確認する。
  - 上記でわかれば、修正。できなければ、下に進む
- エラーメッセージ出ないエラー(ex. 画面に想定のものが表示されない等) or エラーメッセージの発生原因を探る必要があるとき
  - ブレークポイントを張る or プリントデバック
    - 予期せぬデータが入っている場所、原因となっている場所を特定する
  - コード差分から原因の推定を行う
  - 正常に動作する入力と、異常動作してしまう入力の差分を見つける
  - 必要とあれば、書き方があっているかをドキュメントなどを見て確認する
  - XX分(ex. 10分)かけてもわからないときは、一度冷静になって別の視点で探す ※ 煮詰まったときは参照
  - YY分(ex. 20分)かけてもわからないときは、周りの人に相談する
    - 相談の際は、「現在行おうとしていること」「現状起こっている問題(エラー)」「現状の状態・変更点(コード)」「調査でわかっていること(わからないこと)」を簡単に伝える。 (※基本的には対話で伝わっていくので、整理にめちゃめちゃ時間掛ける必要はなし)

煮詰まったときは

煮詰まったときに意識したいこと - そもそもなぜ煮詰まるのか

基本的に煮詰まったときは、原因は大きく分けて２つ。
本質的に難しい課題を解いてているか、もしくは、課題設定が間違っているか。
前者は、例えば、既存アルゴリズムの高速化や、大規模設計など。
後者は、例えば、自身がエラーと推定している部分以外の部分がエラーに関係しているなどの場合。

特に後者の場合は、難しくない問題を自身で難しくしてしまっている場合がある。(というか経験的には殆ど後者)
バグがなかなか解決しない場合、自身が後者の罠にハマっていないか、意識する。

下記の手法が「煮詰まり」には有効なことが多い。

煮詰まったときに手助けとなる手法

ラバーダッキング = 問題点をテディベアに話してみる
参: http://www.aoky.net/articles/john_graham_cumming/talking_to_porgy.htm
コード差分を考える。(動くところまで戻る)
二分探索法: コードを半分コメントアウトしてバグが起こるかを繰り返し試す
一回寝て(時間をおいて)リセットする！
人に相談する