ショートカット
ファシリテーター × あり方
コーディングの向こう側
Hello, ANOTHER world!
オブジェクト指向のはなし
プログラミングのはなし
C言語実力診断クイズ
eSkillBooks
コーディングの向こう側

バグ退治はいつやるべきか - PART2

バグよ、おまえは完全に包囲されている度

早期発見か、一網打尽か

2つの戦略を考えてみましょう。

  • 戦略A:
    たとえ作成途中でも、バグを見つけたら即座に修正
  • 戦略B:
    バグを見つけてもすぐには直さず、すべて作り上げてからまとめて修正
どちらが良い戦略かを決定するのは、同じ品質のソフトウェアを作るためにかかるコスト(または別の見方をすれば同じコストで作ることができるソフトウェアの品質)によって比べれば良いでしょう。だとすると、良い戦略は明らかにAです。バグは作った直後に作った本人の手で修正するのが一番確実で手間がかからないし、複数のバグが合わさった現象は解析が困難なので1つずつ発見される度に解決した方が簡単です。

バグ退治の具体策

バグは早い段階で取り除いた方が良いということは、「バグはコーディングの段階で退治すべし」ということです。そして、コーディングの段階でバグを減らすためにできる対策は少なくとも2つあります。

  1. バグをできる限り発生させないようにする
  2. 発生したバグができる限り早い段階でプログラマの目に触れるようにする

1つ目についてはコーディングをする上での習慣によってかなり達成できます。たとえばポインタのクリアを必ずするとか、if 分をブロック化するといった単純なことです。

2つ目の対策にはデバッグコードが非常に効果を発揮します。これは、バグを積極的に見つけるための技法です。バグが自分から姿を現すのを待っていては遅すぎます。こちらから罠を張って捕まえるようにするのです。

このようにすれば、コーディングしながらちょっと動作確認のためにプログラムを動かしてみるといようなことを繰り返している間に、ほとんどのバグが見つかります。そして、コーディングの段階で見つかったバグは、すぐに直すことができます。

ここで述べたような対策はどれも小さなものばかりだし、これだけやっていれば大丈夫というわけでもありません。使用する言語によっても対策は違ってくるはずだし、そのプロジェクトに特有の事情といったものもあるでしょう。また、バグを少なくする上で妨げになるような慣例や規則があるなら廃止を検討することも必要です。

さて、バグはコーディングの段階で発見・修正するのだとすると、テストは何のためにするのでしょうか?これについては次回にお話しします。

前へ

目次へ
テストは2種類ある

(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)