デバッガーが有効に働くとき

まず自分は音声系の仕事をしていたので、
デバッガーを使おうにも使えないことが多かったです。

しかしデバッガーが使える環境であっても、
デバッガーに頼ることはほぼ皆無と言っても良かったです。

スタックトレースさえログに出ていれば、
100行未満しかないメソッドにまで問題が特定できます。

だいたいそれだけで終わってしまいます。

マルチスレッドでアクセスが入るインスタンスについては、
1～2メソッドの排他制御処理に着目すれば良いだけです。

それもパフォーマンスに気をつけなくてよいのであれば、
安全策を取ってそこで問題が起こる可能性も低くなります。

もしスタックトレースが出ていなかったとしても、
整備されたログ設計はおかしな箇所を容易に示してくれます。
(分からないならログ設計の不備なので、ログ出力の修正から行います。)

自分はログの命じるままに調べればよいだけで、
デバッガーが登場する前に話が終わるのです。

 

…まあこれは誇張を含んでいますけど、
言いたいことはそんな感じです。

デバッガーが要らないような設計をまずしないとってことです。

 

なんですが、そうなんですが！

 

最近はデバッガーを使わざるを得ない状況となってしまいました。

そうです、
既にどうしようもないソースコードを調べる場合です。

デバッグとは関係ないログばかりが出力され、
肝心な事は何一つ教えてくれません。

デッドコードがそこら中に仕掛けられていて、
修正したと思ったら通過しないなんてことも良くあります。

そして地獄の釜を割らんとするばかりのネストの深さ。

まず釜の縁(括弧の開始と終了)が大きすぎて画面に映りません。

その中にあるのは深淵の闇、
その闇を照らすことができる(ように見える)のがデバッガーなのです。

関係ないログがログファイルにも標準出力にも大量に出るので、
結局こうなってしまうのでした。

 

しかしこう考えると、
ソースコードのデバッグがデバッガー前提って、
かなり危ないのではないでしょうか？

デバッガーで容易にデバッグできてしまうことで、
ソースコードの汚さに気がついていないのではないでしょうか？

 

そう、デバッガーは必要ですが、
必要でないことを目指すべきなのです。

と、デバッガーを使いたがらない人が言い訳をしてみました。

(あ、デバッガーと伸ばしているのは、Microsoft日本語スタイルガイド的な理由です。)