debug [Computer and Networking ]

ソフトウェアのバグの話、その２。デバッグそのものは実は言われるほど難しいことではなかったりする。難しいのは正確にバグの内容を把握することだ。そのためにはテストが重要になる。また、開発者自身は往々にして無意識のうちにバグを避けてしまったり、見落としてしまうことがあるのだ。以前、テスト報告を受けて、自分ではその症状を再現できないことがあった。テスト担当者のところで見せて貰うと、確かに再現する。微妙に操作方法が異なっていた。テストは斯様に難しい。

プログラムが大きくなると、テストもデバッグも難しくなる。それを避けるために、プログラムは小さな単位(モジュール)に分解し、それぞれを十分にテストしてから順次組み上げてゆくという手法を用いる。オブジェクト指向プログラミングにはこういった側面もある。XP(eXtreme Programing)でいうテスト・ファーストだ。

日経 ITPro の記事、「テスト・ファーストなんて嫌いだ」

現実の仕事はと言うと、出来上がってから要求仕様の変更が日常茶飯事なので、そのような試みが水泡に帰すこともしばしばだ。個別の部品の動作が変われば、やはりそれを使う側にも影響があるのだ。

そういったリスクを更に減らすため、全体のプロトタイピングをおこなう。これはモジュール化の指標にもなるし、基本構想の致命的な欠陥を予め発見、回避できることもある。これは小規模なスパイラル型開発モデルとも言える。事前の仕様分析を十分したくともできないための苦肉の策か。そうではなく、仕様を明確にするための手段であると思いたい。

そうやって長年仕事を続けていても、未だに自分の書いたものについて「完璧だ」とはとても言えそうにないのは、プログラマの定めなのだろうか。トラブルなく動きつづけていても何か問題が残っているような気がするのだ。あるいは只の小心者か。

iwatam(kp9m-iwt@asahi-net.or.jp)さんの「ソフトウェア開発の落とし穴」