この記事を書いた理由#

プログラムをデバッグするうえでの考え方や思い当たる原因を書いていきます。
考えの基となる材料や基本が無いと、何も思いつかないし、考えられません。

基本となる考え方

全体の流れ###

問題(現象)発生→事実を集める(観察 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行ずつデバッグ
他のソースで置き換えて実行できるか(定数とか)
他のソースと比べてみてどうか
実装漏れは無いか(反映されてない画面項目の変数がもれなく処理に追加されているかなど)
処理順序を変更すると変わるか