バグ退治はいつやるべきか - PART2 |
||
|
早期発見か、一網打尽か |
||
|
2つの戦略を考えてみましょう。
|
||
| どちらが良い戦略かを決定するのは、同じ品質のソフトウェアを作るためにかかるコスト(または別の見方をすれば同じコストで作ることができるソフトウェアの品質)によって比べれば良いでしょう。だとすると、良い戦略は明らかにAです。バグは作った直後に作った本人の手で修正するのが一番確実で手間がかからないし、複数のバグが合わさった現象は解析が困難なので1つずつ発見される度に解決した方が簡単です。 | ||
バグ退治の具体策 |
||
|
バグは早い段階で取り除いた方が良いということは、「バグはコーディングの段階で退治すべし」ということです。そして、コーディングの段階でバグを減らすためにできる対策は少なくとも2つあります。
|
||
|
1つ目についてはコーディングをする上での習慣によってかなり達成できます。たとえばポインタのクリアを必ずするとか、if 分をブロック化するといった単純なことです。 |
||
|
2つ目の対策にはデバッグコードが非常に効果を発揮します。これは、バグを積極的に見つけるための技法です。バグが自分から姿を現すのを待っていては遅すぎます。こちらから罠を張って捕まえるようにするのです。 |
||
|
このようにすれば、コーディングしながらちょっと動作確認のためにプログラムを動かしてみるといようなことを繰り返している間に、ほとんどのバグが見つかります。そして、コーディングの段階で見つかったバグは、すぐに直すことができます。 |
||
|
ここで述べたような対策はどれも小さなものばかりだし、これだけやっていれば大丈夫というわけでもありません。使用する言語によっても対策は違ってくるはずだし、そのプロジェクトに特有の事情といったものもあるでしょう。また、バグを少なくする上で妨げになるような慣例や規則があるなら廃止を検討することも必要です。 |
||
|
さて、バグはコーディングの段階で発見・修正するのだとすると、テストは何のためにするのでしょうか?これについては次回にお話しします。 |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)