デザインは精緻、 コーディングは華麗、 そしてデバッグは…泥沼。
どうしたわけか、私が最近作るプログラムはデバッグがしにくい環境のものが多い。デバッグ、すなわちプログラムの誤り（バグ）を探す作業には普通デバッガという道具を使う。最近の私は、デバッガがないマシンや、デバッガの動作が不安定なマシンの上での仕事が多いのである。例えば、マシンが出来たてのほやほやで、現在ＯＳやツール類を作っている最中だとすればデバッガはまずないと思ったほうがよい。あるいはそのマシン上でのデバッガを作るのが仕事だったりすると、当然デバッガはない。
デバッガがないマシンで仕事をするのはまだよい。困るのは不安定な動作をするデバッガ、言い換えればまだバグのあるデバッガを使わなくてはならないときだ。プログラムを一歩一歩動作させていくステップ実行の最中にデバッガが暴走したり、変数の値を調べようとしたらデタラメな値が表示されたり、いったいプログラムのデバッグをしているのか、デバッガのデバッグをしているのかわからなくなってしまう。
まともなデバッガがない環境でもデバッグはしなくてはならない。「デバッガがないからプログラムは完成できません」では仕事にならない。そんなとき、プログラマがまず考えるのが、デバッグ・プリントである。これは、プログラムの中に文字列を表示するコードを埋め込んでやることである。プログラムを動作させると、画面に文字列が表示され、プログラムが現在どこを走っているのかがわかるという仕掛けである。例えばこんな感じだ。
get_cmds: start.
file_open: 'record.dat'. OK.
file_read: Read 8 bytes.
get_word: av[0]='show'.
hash('show')=32.
file_read: Read 9 bytes.
get_word: ...
こんな文字列が大量に画面に表示され、プログラマはそれをにらんで、いまプログラムがどう動いているかを把握するのである。もし、プログラマが「関数 get_cmds の動きは正しいことがわかったから、 get_word を詳しく調べたい」と思ったとしよう。そのときは get_word の中にデバッグ・プリント用のコードをさらに埋め込んで、再度コンパイルしなくてはならない。必要な情報がうまくとれなかったら、さらに埋め込んでまたまたコンパイル。デバッグ・プリントをやっていると、たいていコンパイル回数は多くなり、時間も多くかかる。このデバッグ・プリントは、もっとも原始的なデバッガであると言えよう。
デバッグ・プリントは原始的だが、デバッガのバグで悩むこともないし、手間はかかるが確実な方法である。しかし、デバッグ・プリントが万能なわけではない。不都合が起こる場合もある。
デバッグ・プリントで起こる問題の一つはタイミングである。デバッグ・プリントは画面に文字列を表示するので、そこに若干の時間がかかる。詳しい情報を知りたくてデバッグ・プリントを大量に入れればそれだけ多くの時間がかかる。しかしプログラムのそこが、タイミングに敏感な部分だとすると、困った事態となる。デバッグ・プリントを入れたときと、デバッグ・プリントを外したときでプログラムの振舞いが変わってしまうからだ。料理で言えば、味見をするのは結構だが、味見自体に時間がかかりすぎて味が変わってしまうようなものである。 - もう一つの問題。テキストエディタやワープロなど、画面に文字を表示するプログラムのデバッグをするのにデバッグ・プリントは使えない。プログラム自体が表示している画面にデバッグ・プリントの文字列がばらばらと表示されてしまったら、画面が壊されてしまうからである。こんなときは、ＲＳ−２３２Ｃなどの通信回線に向かってデバッグ・プリントを行ない、デバッグ文字列は他のマシンの上に出るようにしてやる。これをリモートデバッグという。 - 他にもたくさん注意点はあるが、重大なものをもう一つだけ。あるプログラムを客先に納めたところ、しばらくしてこんなＦＡＸがやってきた。「順調に動作しているのですが、画面に "av[0]=" という意味不明の文字列が表示されます」これは恥ずかしい。デバッグ・プリントの消し忘れである。製品版にデバッグ・プリントが混入していてはならない。料理で言えば、味見のためのスプーンを料理の中に入れたまま、お客さんに出したようなものである。
デザインは設計書ができればよい。コーディングはソースができればよい。しかしデバッグは、そのプログラムを正しく動かさなくてはならない。そのためにプログラマは必死でバグを探し、それをつぶしていく。デバッグ環境が貧弱なら、プログラマは自力でデバッグ環境をととのえるしかないのである。
(1992年12月15日、Oh!PC)