職人的デバッグと科学的デバッグ

千葉 滋
Feature 私のデバッグ、 bit、vol.29、no.1、pp. 24-25、共立出版、January, 1997.

私はここ数年デバッグなんてしたことがない。と、こ
う書くと、いや、おまえがデバッグしているのを何度
も見たことがある、とか、彼にバグレポートを送った
ことがある、とかいう声がたくさん返ってくることだ
ろう。そんなタワケタことを書いている暇があったら、
あのバグを早く直せ、とお怒りの方ももしかしたらい
るかもしれない(すみません)。それでも私は最近デ
バッグなんてしたことがないのだ。少なくとも、この
場で経験談を披露するほどデバッグで苦労したことは
ない。

デバッグというのは、もちろんプログラムのムシを取
ることなのだが、ムシにもいろいろある。見つかる場
所で分類すると次のようになるだろう。

(1) コンパイル時:文法エラーや型エラーなどの形で
みつかるバグ。取るのは簡単。

(2) 実行時:プログラムが思ったとうり動かなくてみ
つかるバグ。すぐそこにいるのはわかっても、なかな
か取れないことも多い。

(3) 配布時:ユーザからのバグ報告でみつかるバグ。
仕様と呼ばれることが多い。

私だってもちろん毎日何千行ものエラーメッセージを
コンパイラからもらうし、コンパイル一発完動などと
いうことも滅多にない。でも大抵の場合、コンパイル
エラーをてきぱきと直して、テスト実行で思ったとう
りに正しく動いているのを確認して終わりである。 
(3) のバグも少しはあるが、ほとんどは「仕様です」
「次のリリースまでに直します」といってごまかせる
程度のものだ。

私は(2)のバグに悪戦苦闘などということは滅多にな
い。 仮に(2)のバグがあっても、デバッガでちょっと
追いかければ、問題の所在はすぐ明らかになる。そも
そもプログラムの挙動を見ただけで、どのあたりがお
かしいか予想が立つことも少なくない。時には(2)の
バグに悩まされることもあるけれど、そういう場合は、
プログラム自体の誤りというよりは、OSなどの下位シ
ステムの仕様を私が誤解しているのが原因だったりす
る。

その代わり、正直に言うと、私はプログラムを書くの
がとても遅い。いつもプログラムを書き始める前に、
全体のモジュール構成や主要なデータ構造について、
長いこと考えこんでしまい、なかなかプログラムを書
き始められない。書き始めてもなかなか前へ進まない。
とくに既に動いているプログラムに機能追加するとき
が遅い。だいたいの当たりをつけてさっさと修正を始
めればよいものを、頭の中で必要な修正をプログラム
にほどこしてみて、これで絶対まちがいなく動くとい
う確信がもてるまでは、プログラムを直し始められな
い。確信がもてないときは、確信がもてるように修正
方法を変えるか、あるいは修正そのものを止めてしまっ
たりする。

ずっと以前パートタイムのプログラマをやっていたと
き、私はプログラムにこれこれの機能を追加して、と
言われて、「構成上できません」と答えたことがある。
(ああなんて怖いもの知らず。)作り始めたときには、
その機能のことなど想像だにしなかったので、追加す
るためにはプログラムの基本構成をあちこち直さなけ
ればいけなかったからだ。もちろん、東大にある、あ
る建物のように、3階の上に後から4階を追加したよ
うなプログラムを書けばよかったわけだが、そういう
事はやりたくなかったのだ。(実際、その建物はひど
い雨漏りがする。)

一方、世間でハッカーと呼ばれるような人達は、違っ
たやり方でプログラミングするようである。アメリカ
にいたある日、私はある筋金入の Lisp ハッカーと一
緒にモニタの前に座って私のつたないプログラムにつ
いて検討していた。彼いわく、

彼「ここの部分は、もっとましなやり方で書ける。ちょっ
と貸してみて。(カチャカチャ...)」
私「ああ... でもそうすると、あっちが...」
彼「いいか、ちゃんとしたプログラミングというのは
こういう風に書くんだ...」
私「でもあっちも一緒に直さないと...」
彼「それは後で自分でやっといて...(カチャカチャ...)
よしこれで動くはずだ... あれ、くそ、間違った。
(カチャカチャ...)あちこち直したからバグってる
けど、だいたいこんな感じだ。後はやって。」

彼が去った後、彼が残していった無数の小さなバグを
取るのに、私がその日の午後を費やしたことは言うま
でもない。

一般にハッカー達は、自らの職人的直感を大切にして
プログラムを書く。彼らのプログラミング・スタイル
では、だいたいの構成が浮かんだら、とにかくプログ
ラムを書き始める。そして素早く書き上げたら、時間
をかけて山ほどあるバグを取る。バグも行き当たりばっ
たりに取っていくので、プログラムはどんどん複雑に
なっていく。だからハッカーのコードはたいてい、汚
くて書いた本人しか意味がわからない。(なお前述の 
Lisp ハッカー氏は潔癖症的にきれいなコードを書く。)
だが、彼らの偉大なプログラミング能力と驚異的な体
力が、結局は、数々の素晴しいソフトウェアを生み出
すのだ。

なんのかんの言っても、素晴しいソフトウェアは皆ハッ
カーの手によるものなので、適当に書いてしっかりバ
グを取るハッカーのデバッグ・スタイルが世間ではも
てはやされるようである。これを職人的デバッグと呼
ぼう。だが私は、最初からバグが出にくいプログラム
を時間をかけて書き、デバッグでは苦労しない、とい
う私のスタイルも悪くないと思うのである。職人的デ
バッグの向こうをはって、これを科学的デバッグと呼
びたい。

科学的デバッグとは、これすなわちソフトウェア科学
を駆使したプログラミングである。ここでは、オブジェ
クト指向や、デザインパターンも、学者の空論ではな
くて、現実的で強力な武器である。結局、バグはプロ
グラムが複雑になりすぎて、プログラマの理解の範囲
を超えるから発生するのだ。だからバグが入りこむ余
地のないよう、わかりやすい、きれいなプログラムを
書けばよい。もちろん、オブジェクト指向、オブジェ
クト指向、と唱えるだけでは、きれいなプログラムは
書けないが、正しい境界でオブジェクトに切り分けら
れたプログラムは、自然ときれいになっているものだ。
正しい境界の見分け方を教えるのも、またソフトウェ
ア科学の役目である。

科学的デバッグでは、プログラマがソフトウェア科学
についてよく知っていなければならないし、職人的デ
バッグに比べてプログラムを書くのが遅くなるので、
あまり魅力的ではないかもしれない。とくに産業界で
は、長い時間をかけて、最初からバグのないプログラ
ムを書くよりも、素早く書き上げたプログラムを、大
勢のテスターを動員して、徹底的にバグを検査、プロ
グラムを修正した方が、能率がよいかもしれない。で
も私のように、大学に籍をおいていて、いつも一人か
あるいは小人数で開発をする者にとっては、科学的デ
バッグは、実際に動くソフトウェアを開発する唯一の
方法である。正直なところ、配布前の徹底的なバグ検
査など、とてもでないが実行できない。それに長い目
でみれば、読みやすいプログラムは、保守しやすい。

ソフトウェア科学者のはしくれである私は、できたら
科学的デバッグをこうして応援するだけでなく、科学
的デバッグに貢献するような手法を自分でも開発して
みたいと思っている。だから、私が現在やっているリ
フレクションの研究も、そういう手法のひとつを生み
出すことを目標にやっているつもりだ。

リフレクションというと、オブジェクト指向よりもっ
と曖昧模糊としていて、実用的には何の意味ももたな
い、と思っている向きもあるかもしれない。しかし、
例えば私の OpenC++ では、リフレクションを使って、
普通の C++ では作成できない速くて便利なクラスラ
イブラリを作成することができる。そういうライブラ
リを活用してプログラムを書けば、プログラマが新た
に書かねばならないコードの量が減り、バグの入る余
地が小さくなる。リフレクションが、科学的デバッグ
の一助になっている、ひとつの例である。

(終)