バグが取れない

作者：滝本飛沫

あるプログラマーのデバッグ時の心の中の声、プログラマーがデバッグしている時ってこんなこと考えているのですね。

　今のプログラムにはバグがある。とても、このまま出荷するわけにはいかない。

　「バグ」、虫のことだ。いつ頃どこの誰が言い始めたのか私は知らないが、言い始めた人の気分がよく分かる言葉だ。きっとその虫はかわいらしい虫などではなく、うぞうぞっとした虫に違いない。いや、洋服に付く虫のように、姿は見えないが虫食いの穴によってその存在が分かる、この感覚が一番近いかも知れない。

　プログラムのバグに洋服の防虫防カビ剤は効かない。

　しかし、ある程度バグを防ぐコツのようなものはある。例えばＣ言語の場合、コーディングの書式を統一して全体を見易くしたり、変数や関数の命名に工夫をするなど一般的によく知られた方法や、計算式には演算子の優先順位にかかわらずカッコを使うなどの経験に基づく手段等、おそらく個人個人何らかの対抗策をもっていることだろう。

　ソースリストを印字して見る、読むというよりは眺めると言った方が近いと思う。もともとプログラムリストなんてものは、日本人にとって意味不明な記号の羅列なのだ。もっとも、リストが日本語になった所で難解なことには代わりがない。これはプログラム内蔵方式のコンピュータが生まれながらに持っている業とでもいうものなのだろう。

　だいたいプリンタというものはリストを打ち出すためにあるのだと思う。それがいつしか文書を印刷する道具になってしまった。といいながら、自分でも提出用のドキュメントはワープロソフトで作成し、レーザープリンタで印刷しているので文句は言えない。文句をいうつもりもなかったのだが。

　変数の動きを追う。関数のつながりを検討する。

　このプログラムは私が作ったものではない。ＢＡＳＩＣとアセンブラで組まれていたもとのプログラムを、２年前にＣ言語とそれにリンクできるアセンブラに書き直したのは私だが、その後の４バージョンは他の人が改造を加えている。

　今残っているバグも前のバージョンから引き継いだものだ。どのバージョンから混入したのか、私には分からない。

　プログラム中にデバッグ用の表示ルーチンを組み込み動作をつぶさに観察する。

　変数の動きとアセンブラからの戻り値とに食い違いが生じている。画面上の動作は異常だが、プログラムした通りに動いていることは間違いない。後はなぜこの変数がおかしな値となっているかが問題だ。

　プログラムを作る人のなかにはアセンブラは難解だと思っている人がいる。かくいう私も実はそうだったのだ。しかし、仕事となれば嫌も応もない。必要に迫られ、他人のリストを眺めているうち、どうにか必要なルーチンを組むことができるようになった。

　アセンブラのルーチンも疑ってみたが、特に問題はなかった。ちょっと前にセグメントのミスを修正したのでアドレスの間違いはない。もっとも、アドレスがずれると画面がおかしいどころではなくなるのだ。

　アドレス、セグメント、理屈としては簡単なのだが、単純であるとは言い難い。メモリモデルなんて楽器のベースではあるまいにロング、ミディアム、ショートだのと、あ、ラージ、ミディアム、スモールか。

　徐々にバグを追い詰める。

　見えている症状から、悪い所をつきとめる。ちょうど医者が患者の症状から病気を特定するようなものだ。病気の場合、病名が分かったからといってすぐに直せるわけではない。同様にバグも発生箇所が分かったからといってそれが必ず修正できるわけではない。

　表示の具合と、変数の扱い、それに該当する関数の戻り値を眺めて、バグの所在の見当をつける。関連する部分はわかる。後はどの処理が悪さをしているかだ。

　こういう、いうことを聞かない悪いプログラムをいじっていると、ふと、ゼロから作り直したい気がしてくる。これが仕事でないのなら半年ほど眠らせて、また新たに作り直しても良いのだが、仕事には客がいて、納期があるので、そういうわけにはいかない。

　納期まで後三日、ドキュメントは作ってあるが、送付の時間を考えると今日中になんとかしたい。

　ふと、一連の処理の順番と現れる症状と似ている気がした。順番を入れ換えると症状に変化が現れた。ここだ。

　プログラムを作る人の中には、リストの見栄えを気にする人がいる。「見難さ」ではなく「醜さ」を嫌がる人達だ。確かに自分のやり方にそぐわない、解りにくいリストを読むのは苦痛だが、スペースの一つや二つ、無かろうが多かろうがたいした問題ではない。

　このif文に違いない。それは確実なのだが、見たところ論理的に間違ってはいない。

　念のため、その部分をマスクして実行してみる。案の定、異常な動作が消えた。納得はいかないが、それにこだわっているヒマはない。急いで正式な修正をかけ、デバッグモードで試す。うん、完璧だ。処理的にもこちらの方が良い。

　今回のバグはなかなかの難敵だった。

　プログラムを組んでいてデバッグほど嫌な作業もない。しかし、より完成度の高い製品を出荷するためにはどうしてもそれが必要だ。

　プログラムを作り続ける限り、バグも発生し続けるのだから。

追記：このバグの論理的検証はこの後きちんと行っていることを蛇足ながらつけ加えておく。

ほぼ実話ですが、とっても古い時代の話です。BASIC+アセンブラって昔のプログラムでは当たり前で、ものによっては全部アセンブラで書かれていました。そんな時代もあったのです。