Debug手順
つい最近とてつもなく下らないバグに４時間以上も時間を費やしてしまった。
言語仕様として、２年くらい前に組み込まれた機能なので環境が悪いと勝手に思い込みコンパイラを入れなおしたりしました。*1
色々と環境周りをいじくり回してもバグがとれない・・・・その日は諦めて帰宅しました。
次の日にじっくりとソースを見てバグをやっと発見！原因はクラス名の重複でした。
「こんな下らねー事に５時間も費やしたのかよー！マジで逝ってしまいた(＞_＜;)」っと思いました。
自分のシステム手帳にはDebugをする時のTipsが書いてあります。このTipsを最初に読んでおけばもっと早く終わっただろうなーっと思います。
何冊か本を読んで自分なりに纏めたTipsです。
Debugする時に読み直す為にBlogに張っておきます。よろしければ参考にしてください。
- 始める前に正しい心構えが必要
自己弁護はやめろ！「そんなハズは無い」なんて事は絶対に思うな！
起こり得る事しかおきていない「実際に起こった」と認識しろ！
コンパイラや環境のバグが原因なんて事は99.9％ない！*2
- デリケートで感情に支配されやすい。
気持ちを切り替えて精神を集中だ。
プレッシャーを断ち切れ。
たんなる問題解決だ。
- まず、再現だ。
必要ならばバグを再現するメソッド、関数、データを作れ。
ひたすら再現する事に努めろ。
- 何がプログラムをそのようにしたかのみを考える。
この工程では絶対に治そうとしない。絶対にだ。
あらゆる仮定を出して検証する。
思いつくバグの原因をデザインして視覚化しながら進めろ。
頭の中だけで整理するな！
- 検証には全ての関連データを集めろ。
そのデータを正確に観察する。
数値、文字に出してデータの視覚化をしろ。
テキストに吐き出せ。プリント文を出せ。検証データをダンプしろ。必要ならばメソッド、関数、データを作れ。
検証せずに仮定だけで終わらす事は絶対にするな。
バグの原因となる仮定を確実に塗りつぶせ。
この工程でも絶対に治そうとしない。絶対にだ。
- 問題の根を見つけろ。
- 下記の事を紙に書いて整理しながら進め。
紙に書く事によって混乱を防げ無駄に頭の記憶を使うな！文字だけでなくデザインしろ。
(1) 再現
(2) 仮定の選出
(3) 調査方法
(4) 原因
(5) 修正方法
- それでもバグが取れなければ次の日にもう一度リトライしろ。次の日には視点が違う自分がいる。
最終手段は周りに聞け、ネットに頼れ。誰かと一緒にデバックを進めろ。
以上の事を意識しながらDebugを進めると思ったより効率よくデバック出来るようになりました。
ってか以前デバッカが使えない時の開発がありました。組み込み関係は時系列の関係でデバッカが使えない時があります。
実際その時の開発にはこのTipsが役に立ちました、なかったら危なかったと思います。
後、個人的にはデバックする時には出来る限りデバッカは使わない方が良いんじゃないかと！？デバッカを使う事に集中し過ぎてしまう傾向がある。
出来るだけバグの仮定の選出には想像力を働かし、検証も出来るだけアナログな方法をお勧めします。データのダンプは大量の検証データを確保できますが、デバッカは一つのみです。
Debugはまるでゴルフのパターの練習みたいなもんだ。
ボールをカップに入れる行為と同じで非常に心構えが必要と思う。
無駄に沢山パターを打つよりも芝を読んで集中しよう
