デバッガの弊害について

Posted on July 1, 2013

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

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

網羅性の問題

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

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

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

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

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

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

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

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

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

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

ではどうするべきか

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