デバッガの弊害について

Posted on July 1, 2013

以上のようなタイトルをつけてみたが、デバッガがプログラマにとって欠かすことのできない重要なツールであることに異論はない。とくにデバッガを使ったプログラムフローの追跡は非常に効果的である。ただここではあえてデバッガにも弊害があるということを主張してみたい。具体的には以下の3点で弊害があると考えている。

  1. 網羅性の問題
  2. プログラムの理解の妨げる
  3. アブダクションを用いた思考を妨げる

網羅性の問題

デバッガが捉えられるのはプログラムのある一つの状態に限られる。もし、デバッガの示す値に依拠してプログラムを修正したら、その他のケースを漏らしてしまい完全にバグを修正できなかった、ということがありえるのではないだろうか。真の意味でのバグ修正は、そのバグに関連するすべて変数に関して、取り得る値のすべて組み合わせ(状態)を考慮したうえで行わなければならない。しかし、デバッガを使ってしまうと近視眼的に問題となっている状態に引きずられてしまい、本来は考慮されるべき状態を漏らしてしまう可能性があると考えている。

プログラムの理解の妨げる

大抵のバグはプログラムを正しく理解していれば修正可能であると仮定すると、デバッガを使うことは次の2点で正当化される。

  1. プログラムは理解していない(または理解するつもりがない)がバグ修正を 行わなければならない
  2. プログラムは理解しているが手間を省くためにデバッガを利用したい

後者は問題ないが、前者は無視できない弊害ではないだろうか。プログラムを理解していないのにバグ修正するなど本来は避けるべきだし、そういった修正が積み重なるとソフトウェアはどんどんおかしな方向に流れていく。また、プログラムを理解していないために適切なリファクタリングが実施されにくいなどの問題も発生する。プログラムを理解したうえでバグ修正をしろというのは現実的に厳しい要求であるのは理解しているが、デバッガを利用する際はこのような弊害がありうることを意識しておく必要があると考えている。

アブダクションを用いた思考を妨げる

アブダクションとは演繹・帰納に並ぶ論理的推論の一つで、結論から仮定を導くという形式をとる。アブダクションはエンジニアにとって演繹・帰納以上に重要な推論だと私は考えているが、その理由は以下の2点に集約される。

  1. 表面的に表れる事象から原因を特定する推論である
  2. 導かれる仮定が自ずと広範囲におよび網羅性の問題を軽減する

(1)は、例えばデバッガで言えば、バグから原因を特定する推論をさす。アブダクションを用いた思考に慣れてくると、バグから直接的に原因を特定できるようになる。常にデバッガを使ってバグ修正をしているようではこうはいかない。エンジニアリングの世界では、知ることのできる内部情報は基本的に限られていると考えるべきで、普段から自分をそのような状況に追い込んでおくと、いざというとき役に立つことがある。(客先で問題を解決しなければならないなどの状況)

(2)は、アブダクションの性質的に当たり前だが、限られた情報、つまり緩い制約条件のもとでは、仮定もそれなりに緩くなる、という話である。ことデバッグに関しては、導かれた緩い仮定が高い網羅性を自ずと生み出し、先に述べた網羅性の問題をいくらか軽減させるという重要なメリットを生む。これはつまり、プログラムを頭から理解しなくても網羅性の高いバグ修正が可能になることを意味する。

ではどうするべきか

以上のような弊害を克服するためには、あえてデバッガを使わないという選択肢を考えてみるのもよいと思う。私はJava開発にもEmacsしか使わないし、それで不満を感じたことはあまりない。Eclipseの高機能デバッガを羨しく思ったことは全くないし、printfデバッグ最強だと心の中から信じている。この記事は私がデバッガを満足に使えないことを正当化するために書いたものでは決してないことを注記しておく。