Index
達人プログラマという本を参考にしました。
ITエンジニア本大賞2022の大賞に選ばれているので、知っている方も多いと思います。
達人プログラマーの20章でデバッグ時の心構えとか、どのようにデバッグするかとかを書いてあり、とても面白かったので、自分なりにまとめてみようと思います。
では早速本題へ
デバッグ時にメンタルがおかしくなるのはよくあることです。
そんな時に以下の３点を思い出してください。
- 誰かを非難するのではなく、問題を修正すること
- 責任転嫁しない
- パニクらないこと
バグの原因が自分のミスなのか、他人のミスなのかどうかは関係ありません。
いずれにしても自分の問題です。
バグ修正をやらない理由を探したり、プロジェクトのプレッシャーを断ち切り気持ちを切り替える必要があります。
誰々のバグなんだから….みたいなことはやめましょう。
納期が目前に迫っていたり、上司に背後に立たれたりすると簡単にパニックに陥ります。
本来のペースを取り戻すには何がバグを引き起こしている真の原因を考えることが重要なのです。
バグ、バグレポートを最初に目にした時の反応が「そんなことはあり得ない」というものであれば、明らかに自分のミスです。
一刻も早く「実際におこったのだ」という一連の考えに辿り着きましょう。
単純にバグを修正したくなる欲望に負けてはいけません。真の原因は自分が見ているレベルとは別の次元で起こっている可能性があります。
問題の外見のみに目を向けるのではなく、常に問題の原因の根を見つけるように努力しましょう
- コンパイラの警告レベルを最大に上げる
- 適切なデータを全て集める
コンパイラが発見できるレベルの問題を骨を追って探すのは時間の無駄です。
目の前に立ちはだかるもっと難しい問題に集中しましょう。
バグの報告はいつも正確ではないことを頭に入れておきましょう。
最初に報告された情報よりも多くの情報を集めるには、バグを報告してきたユーザーにインタビューするのが手っ取り早いです。
- バグを再現させる
- エラーメッセージをよく読む
バグを修正するにあたり、最初にやることはバグの再現です。
再現できない限り、本当に修正できたかどうかは確認する方法はありません。
そしてもっとも重要なのは
- コード修正前にテストを失敗させること
テストを作り出す過程の中で、解決策が見えてくることがあります。
説明不要でしょうが、いきなりコードを見るのではなく、エラーメッセージをちゃんと読みましょう。
以下のパターン別の紹介します。
- クラッシュしなかった場合
- クラッシュした場合
単におかしなデータが帰ってきたことにより起こっています。
デバッガーを使って誤った情報が発生していることを確認しましょう。
またスタックトレースを追いかける場合は、何をどう追いかけたのか、メモをしておくようにしましょう。
記録しておかないと、どこまで作業を遡れば良いかわからなくなります。
クラッシュした場所から遡っていくのも一つの手ですが、データセットから手をつけた方が簡単な場合があります。
やり方
- データセットのコピーを入手する
- 二分探索法を使い、データセットを半分にしてローカルで稼働しているアプリに入力する
- クラッシュしなければ、②を繰り返す
- 報告を受けた問題は、元となるバグの直接的原因でしょうか？それとも単なる症状でしょうか？
- そのバグは本当に使用しているフレームワークに存在しているものでしょうか？
- この問題を同僚に説明するとしたら、どのように説明すれば良いでしょうか？
- 疑わしいコードがユニットテストをパスしていたのであれば、テストは十分だったでしょうか？
- このバグを発生させた条件が、システム内部の何処か他の部分に残っていないでしょうか？
