自分がデバッグするときの考え方

自分がデバッグするときの考え方について、メモ書き程度ですが記録しておきます。

1. 記録

不具合の発生方法・発生手順を記録する
- どの画面から遷移したか
- どの処理・どの機能を使ったときか
- どのデータを使ったときか（環境に設定されている条件や、対象データのIDなどをメモする）
- 並列で別の処理が流れていないか
エラーが発生した時の動作を記録する
- 例外が出力された時、その内容は何か
- ダイアログが出力されたら、その内容は何か
- ステータスコードは出力されているか。その値に意味が隠されていないか
- どんな値がDBに保存されたか

最新バージョンのリリース媒体を用意する
DBに事象が再現するデータを登録する
- A5M2 (A5:SQL Mk2) で select した結果をコピーするときに「Insert形式でコピー」をすると、他環境にすぐに適用できて便利です
- 注意点として、本番環境からデータを持ってくるときは、個人情報をマスク化してから利用すること
日付や時間に起因するバグであれば、動作環境の時刻を変更する
- 基本的に、システム日付に依存する処理はテストが大変なので、画面の値やDBのシステム制御用の情報などで日付を切り替えられるようにする
処理の内部で乱数が使われているときは、シード値を固定できるようにする

ログの観察
- ログの出力からどこまで正常に動作したかを確認する。エラーコードが出ていればそれを検索する
- スタックトレースが出力されていれば、その処理の経路を追いかける。
- printfデバッグを使うときは、環境変数などでログのレベルを制御できる仕組みを使う。
解析手法
- 全部のプログラムの動きを把握するのは困難なので、まずは静的解析をして怪しい部分の当たりをつける
- 静的解析：
  - プログラムコードを読んで動きを追いかけて、不具合に対する仮説を立てる。また、この時点で大まかなプログラムの流れを把握しておく
  - IDEの機能である「定義へ移動」や「すべての参照箇所を探す」で効率よく定義箇所や使用箇所を検索する。
- 動的解析：
  - 怪しいところにブレイクポイントを立てて、実際の動作を確認しながら、不具合に対する仮説を立てる。
  - ブレイクポイントを立てた箇所での変数の格納値なども確認する。
  - デバッグ中に変数の内容を改ざんして、動作が改善するか確認する。
複数環境の比較
- 2つの環境を用意し、問題なく動作している環境と、問題のある環境に差があるか確認する（データの積み方や設定項目の差異など）

以上です。