デバッガを使う

この手の言い草はよく聞くけれど、私はデバッガはほとんど使わない。使ってもせいぜい、どうしても他に資料のないコアダンプを解析しなきゃいけない時だけで、普段はまるっきり使わない。そこにソースがあるなら、怪しい箇所を推理しつつprintfをつっこむ。なぜなら、私はプログラムを書く時に一番大切なものは、そういったツールを使う能力ではなくて、
思考力

であると思うからだ。それと共に、本当にクリティカルなバグには、デバッガは無力だからでもある。

デバッガなんて使わねーよ | おごちゃんの雑文

デバッガは万能ではないけども、無能でもない。

掲示板などで飛び交う質問には、「デバッガを使って、ブレークポイントを張ってオブジェクトの状態を見たら一発で解決するよ」みたいな話がごろごろしている。

ただ、そんな軽微なバグは、慣れるとそもそも作り込まなくなる。状態を見るにしても、状態遷移を追いかける場合に、多数のブレークポイントを置いてステップ実行しながら状態変化を追いかけるのは面倒だ。printfするようにして、ログを眺める方が楽な場合もある。

「本当にクリティカルなバグには、デバッガは無力」というのはよく分かる。マルチスレッドの同期バグとかにはかなり無力だ。

現象が特定できた後になら、並列スレッドをステップ実行して偶発的なタイミングを再現させて「ほら、こういう現象でしょう？」と証明することには使えるけども、特定する過程ではおよそ無力だ。

しかし、そんな難物と戦うわけでない人ならば、業務のロジックを書くだけならば、デバッガはとても強力な道具足りうる。新人教育とかにはデバッガの使い方ってのを含めておくべきだろうなぁ。

ちなみに、JavaだとCのようなデバッグのビルドとリリースのビルドで動きが変わるなんてハマりはほとんどない。せいぜい引っかかるとしてもアサーション回りぐらいじゃないかな。

デバッガでせん滅できる程度のバグはデバッガでせん滅してしまえばいい。
findbugsでせん滅できる程度のバグはfindbugsでせん滅してしまえばいい。
自分でせん滅できる程度のバグは自分でせん滅してしまえばいい。

残ったバグは…。