　コンピュータは、人間が手でやるには難しい複雑な計算を非常に高速に実行できます^※1）。しかし、エンジニアの思い通りに動かすことは簡単ではありません。コンピュータは、あくまでも命令通りにしか動きませんね。そのため、エンジニアは、「何でうまく動かないんだろう」とため息をつき、異常動作した時のメモリのダンプを見ながら、デバッグすることになります^※2）。

※写真はイメージです

※1）「超高速で処理できる」という利点は、裏を返すと、「超高速でしか計算できない」という欠点になります。「高速で飛べる」のは、飛行機の大きな利点ですが、逆の見方をすると、「高速でしか飛べない」という欠点を抱えていることになります。そこで発明されたのが、空中で静止したり、後ろ向きにも進めたりするヘリコプターです。ヘリコプターは、燃費が悪く、構造も複雑ですが、「高速でしか飛べない」という欠点がある飛行機では入り込めない独自の市場を築いています（日本でも導入が決まった米国製のステルス戦闘機「F35B」は、垂直離着力や空中停止が可能ですが、垂直離陸した場合の燃料消費が異常に多く、また、1機100億円と異常に高価。飛行機として、垂直離着陸機は民間機レベルでは実現しそうになく、ヘリコプターの独壇場です）。長所と短所は、常に背中合わせですね。

※2）プログラマーの口癖はいろいろあります。筆者がよく言っていたのが、「オレの環境だと正しく動いた」です。例えば、完成したプログラムを同僚の環境にコピーして実行すると、先ほどまで正常に動いていたプログラムが、全く動きません。不思議ですね。調査してみると、自分のプログラムのバグが原因でした。つまり、自分の環境でたまたま動いていただけだったのです。動作環境が同じでないことが動作不良の原因となる場合もありますので、ご注意ください。

　うまく動かない原因が、初歩的なミスであるケースも少なくありません。このようなミスは、デバッグ時にバグとして見つかりますが、思わぬ「大物」が、市場へリリースした後で見つかることも少なくありません。インターネットに載っているIT系のニュースサイトを見ていて、「バグが何年間も見つからないままだった」という記事を読むと、人ごとではなく、ゾッとします。組み込み系のソフトウェアには、コンビニのATMをはじめ、長期間、24時間稼働をさせるソフトウェアも多く^※3）、注意深く実装、デバッグしたいですね。

※3）コンビニのATM制御プログラムのような、1年365日、1日24時間も稼働させる組み込みソフトウェアの対極にある「短命なプログラム」の例が、ロケットの発射制御プログラムです。発射の20秒前から動作し、発射3分後には衛星軌道に乗ります。合計、4分ほど正常に動けばOK。稼働時間が4分程度なら、メモリの返却漏れのバグがあってもプログラムがフリーズすることはありません。呼び出すモジュールは時系列で決まっているため、制御構造もシンプルです。ただし、バグにより発射に失敗した場合の損害額は極めて大きく、また、社会的な注目度も大きいため、開発やデバッグでは細心の注意が必要となります。

　今回は、「音楽プレーヤー」を題材としたプログラムのバグを見つけていただきます。100行程度のソースコードで、難しい記述はありません。人によっては、すぐに解答できるかもしれませんね。仕様通りに実行させるには、どこを修正すればよいか推察し、デバッグ能力を鍛えてください^※4）。

※4）この「バグ検出ドリル」シリーズの目標は、「バグを見つける嗅覚を鍛える」ことと、もう1つ、「他人が作ったプログラムを理解する」ことにあります。「バグ検出ドリル」のように、第三者が作ったプログラムのバグを見つけて修正するためには、まず、他人のプログラミング思考を見抜いて処理方式を理解し、ソースコードを解析してバグを見つけねばなりません。

　最近のプログラムは、第1バージョンをリリースしたあと、機能追加、性能向上、他のハードウェアへの移植など、延々と保守作業が続きます。おそらく、ソフトウェア開発の70％の時間とコストを保守フェーズへ投入していると思います。

　保守フェーズでは、「第1バージョンの作成者」と「第2バージョン以降の担当者」は別の場合がほとんどで、「他人が作ったプログラムを理解する」ことは、非常に面倒、かつ、苦痛ですね。「保守能力の向上」の意味でも、本デバッグ・ドリルを活用していただければと思います。

それでは問題です

　　　　　　 1|2|3 次のページへ