机上デバッグ

第5回 現代でも机上デバッグは有効?

2013.03.06

前回は、机上デバッグの効果を説明しました。今回は、現代のプログラミング環境で、はたして机上デバッグが有効なのか、考えてみたいと思います。

「机上デバッグ(3)-机上デバッグを行う理由」で、1980 年代前半のプログラミング環境について述べました。それに比べて現代では、

  • 数 GHz の CPU クロック
  • 数ギガバイトのメモリ
  • 数百ギガバイトから数テラバイトのハードディスク

このように高性能なパソコンを使用しています。その結果、たとえ数十万行程度の C のプログラムを全てコンパイルした場合でも数分でコンパイルが完了し、その直後すぐにプログラムを起動できます。また、make コマンドなどを使用していれば、変更したソースコードのみがコンパイル対象なので、数秒でコンパイルが終了するかも知れません。

このような環境であれば、「デバッグ→コンパイル→再実行→デバッグ→コンパイル→再実行→…」この繰り返しを短時間に実施できるので、机上デバッグなどという手間の掛かる方法は採用されにくいでしょう。

しかし、自分は現代においても机上デバッグは非常に有効な開発手段であると考えています。

2003年頃ですが、クラスタを使用し、複数のコンピュータで計算を行なうソフトウェアの開発を行なっていました。自分が担当した部分はアプリケーションとシステム (socketインターフェースなど) の中間に位置する、ミドルウェアと呼ばれている部分です。

基本設計の開始からベータリリースまでに 9ヶ月ありました。ソースコードの量は 5万行程度だったと記憶しています。ベーターリリース迄残り 5週間程度のところで、一通りコーディングが終了しました。それから 3週間ほどは、ひたすら机上デバッグを、繰り返し繰り返し実施しました。ベータリリースまでに必要となる機能部分のみ、5回ほど最初から最期までの経路を一通り確認し、期限まで残り 2週間あたりで、初めてコンピュータ上でプログラムの動作確認を実施しました。残念ながら、実際に動かしてみると、いくつかのバグは残っていました。その後コンピュータ上でのデバッグを行ない、予定通り主要機能が動作するようになりました。

仮にこの時、机上デバッグを実施せずに最初からコンピュータ上で動作確認を開始した場合、はたして机上デバッグを行なうよりも早く動作するようになったのか、それともより多くの時間を必要としたのか?それを確認することは残念ながらできません。しかし、コンピュータ上でのデバッグの際、机上デバッグによりソースコードを十分に把握していたため、コンピュータ上でのデバッグの際に、問題場所の特定が比較的楽に行なえました。

机上デバッグを行なわなず、実機上でプログラムを動作させた場合、

  1. 何か問題が発生する。
  2. どこで問題が発生しているのか、発生場所を特定する。
  3. なぜ問題が発生するのか、その原因を特定する。
  4. 問題の発生原因を修正する方法を考える。
  5. プログラムを修正し、問題が発生しなくなることを確認する。

という手順を繰り返しますが、この「2.どこで」を探すのに、実は非常に時間が掛かることもあります。実行すれば必ず発生する問題であれば、比較的容易に場所を特定することが可能です。しかし、例えば数10回実行すると1回発生する様な問題の場合、再現させるにも時間が掛かるし、発生場所を特定するにはさらに時間が掛かります。

机上デバッグを行なうことによりこれらの厄介な問題を全て事前に解決できるとはいいませんが、それでも机上デバッグは非常に有用な開発手法だと考えています。

興味のある方は、一度机上デバッグを行なってみてください。ここでは書くことができなかった新たなことが、きっと見つかるのではないかと思います。

以上で「机上デバッグ」の話は終りです。

著者プロフィール

asou

好きな OS は、FreeBSD です。が、最近購入した Mac mini がなかなか快適なので、Mac でいいかなと思うようになってきました。

記事一覧Index