「開発エラー時のデバッグフロー」と「煮詰まったときの対処法」についてまとめてみた。

前置き

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

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

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

煮詰まったときは

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

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

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

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

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

• ラバーダッキング = 問題点をテディベアに話してみる
  参: http://www.aoky.net/articles/john_graham_cumming/talking_to_porgy.htm

• コード差分を考える。(動くところまで戻る)

• 二分探索法: コードを半分コメントアウトしてバグが起こるかを繰り返し試す

• 一回寝て(時間をおいて)リセットする！

• 人に相談する