デバッグログってやっぱり重要だよね

良エントリ。

A-1. 例外クラス名・例外メッセージを読む
A-2. スタックトレースを見て例外発生箇所を特定する
A-3. デバッグログをみて挙動をトレースする
A-4. 例外クラス名・例外メッセージ・スタックトレース・デバッグログを記録
A-5. 原因特定のための情報が足りてない場合にその情報をログに出力する
A-6. それでもわからない場合はデバッガを起動する

を無理矢理

３．失敗の原因について仮説を立てる
４．仮説にもとづいて予測する
５．その予測を実際にプログラムを動作させて確認する
デバッグ方法について - wyukawa’s blog

に当てはめるとA-2が３でA-3、A-5、A-6が４、５かな。

僕自身のやり方で言うとA-2で例外発生箇所を特定したらデバッガで追うかな。。。
前提条件としては言語はJavaでIDEはEclipseで例外が発生するタイプのバグを調査するときです。
例外は発生しないけどDBに不正な値が入ってしまうようなバグはソースをざっと見てデータの流れを理解したら即デバッガかな。。。

で、思ったのはデバッグログってやっぱり重要だよねってこと。

「A-5」も重要です。これをすっ飛ばしてデバッガを起動する人をよく見掛けますが、
デバッグログを見てもわからないっていうのは、そのアプリのプログラムが
デバッグログの出力要件を満たしていないということです。(例外メッセージも同様)

これはポイントですね。昔上司が顧客先環境での総合試験中に発生した問題（例外で落ちたとかではありません。ページが一部見えないという現象で自社の開発環境では問題なく見れてました）に遭遇した際、ログをみて原因をほぼ特定してスゲーと思った記憶があります。しかもこの上司はいわゆるトラブってから急遽駆り出だされたわけで、ソースはもちろん仕様だってそんなに把握していたとは思えません。もちろんきちんとログを出力していた開発者もすごいです。で、僕はというと、大量のログ一式（しかも僕が使ったこと無いAPサーバだったのでどれが何のログかわからなかった。。。）を開発者に丸投げしようとしてました。。。すんません。m( )m

「A-5」はある程度は、仕組みで吸収することも大切です。共通部品を作る人の
作業になりますが、FilterやAOPなどである程度重要なのはデフォルトで出力
されるようにしておくといいです。

これも重要ですが、細かいレベルのログ出力はやはり開発担当者まかせになると思います。僕のような普通のレベルの開発者だとログ出力のことまで考えが回りません。なのでそこをカバーするのはコードレビューになってくるでしょう。
またちょっと違う話ですがSystem.out.println("methodA start")とかがリリースまで残ってたりすることがあります。これはいらんだろとか思うわけですが、昔自分もやってました。。。というわけで（どんなわけで？）ログ設計は難しいです。少ないのは駄目だけどあんまり多いとちょっと、、、ってなりますが、無いよりは有るのがマシと割り切って出したほうがいいですね。（System.out.printlnじゃなくてロガー使ってても）"methodA start"はいらないと思いますが。