この記事を書いた理由
プログラムをデバッグするうえでの考え方や思い当たる原因を書いていきます。
考えの基となる材料や基本が無いと、何も思いつかないし、考えられません。
基本となる考え方
全体の流れ
問題(現象)発生→事実を集める(観察 or 分析)→仮説を立てる(推論)→調査→原因特定→対策
問題発生→仮説を立てる(推論・直感)→事実を集める(調査 or 観察 or 分析)→対策提案
問題の切り分け
問題発生→遡ってプログラムを調べる→箇所の特定(処理過程のどこで問題が起こったか)→仮説を立てる・事実を集める→原因の特定
プログラムが上から下と処理されていく過程で、どこで問題が起こったのかを特定することが最優先です。
闇雲に調査をしても時間が経つばかりなので、段階的に原因と思われる箇所を排除していきます。そのため、調査箇所でここで問題は起こっていないということを調べていき、原因を徐々に絞っていきます。起点はlogで、遡っていく形を取ります。
例
データ→プログラム1→プログラム1を呼び出すプログラム2
考える順序
ウェブアプリケーションの流れ
どこで問題が起きたのかを意識して調査しましょう。
バッチの流れ
どこで問題が起きたのかを意識して調査しましょう。
ログの追い方
バッチアプリケーションだったら・・・、というかまずはログを見ます。
まずはlogを追う。
↓
logにエラーメッセージが出ている
↓
エラーメッセージでgrepし、発生ソースを特定
↓
ソースの前後で怪しいところがないかを1行ずつ確認
↓
落ちているところ/怪しいところを確認
↓
落ちているところを手動で実行してみる。
↓
結果を考察する
SQLの検証の仕方
コードに埋め込まれたSQLが怪しいな、と思ったら以下のような検証をしてみましょう。
コードに書かれているSQLを整形し、実際に流れるかを試す
↓
JOIN部分を1つずつ消し、どこのテーブルのデータが無いかを調べる
WebアプリケーションのCRUDのたどり方
Webアプリケーションの内部ではCRUD操作が行われていることがありますがその部分で目的のデータが
取れない場合についてのたどり方です。
DAOコードに埋め込んだSQLを流して、取れるか調べる
↓
取れなければ、DAOコードの返り値を見る
↓
他にも関連するプログラムが呼ばれているかをさかのぼって、探す
調査観点一覧
フローチャートのように調査順序を記載してないので、追記していく予定です
データ
| 観点 |
|---|
| 対象のデータは正しいか |
| 別のデータではどうか |
| 実行スキーマは正しいか |
| 参照先テーブルは正しいか(DAO・シノニム) |
| DAOの条件は正しいか |
| 登録先・削除・更新先のテーブルは正しいか |
| レコードをいじったらどうなるか(削除フラグなど) |
| PL/SQLの引数の数、引数の値は正しいか |
| GUIソフトでPL/SQLを実行出来るか |
| SQLPLUSでPL/SQLを実行出来るか |
| SQLの実行結果は正しいか |
| 実行権限、select,insertなど権限は正しく設定されているか |
| Insert、Update先のカラムはnot nullか |
ソース
| 観点 |
|---|
| 処理ごとにデバッグ文を記載してみて、どこで落ちるか |
| 怪しいとこをコメントアウトしたら処理が通るか |
| 資材は更新されているか(eclipse) |
| ビルド・コンパイルされているか |
| デプロイされているか |
| SVNは最新か |
| クラスファイルの生成日時は最新か |
| 手動実行できるか |
| スケジューラーソフトから起動できるか |
| APサーバーのログに手がかりがないか |
| その他のログに手がかりがないか |
| 古いソースを使っていないか |
| 処理に沿って動いているか(ソースを追う) |
| Eclipseで1行ずつデバッグ |
| 他のソースで置き換えて実行できるか(定数とか) |
| 他のソースと比べてみてどうか |
| 実装漏れは無いか(反映されてない画面項目の変数がもれなく処理に追加されているかなど) |
| 処理順序を変更すると変わるか |