技術者への提言3 <プログラミングとバグ>

2015-12-11_145511.jpg

よくプログラミング書法などが書かれた書籍や法律の書籍などに、誤り易い例として
次のような語句の正確な意味が述べられています。

     "〜以上"、"〜以下"、"より多い"、"より少ない"

このような基本的な言葉の意味が曖昧なまま使われては、致命的な欠陥があるプログラムとなります。

実際には、このような間違いはあまりないと思われがちです。
というのはよく間違える語句などは、初歩的なプログラミング教本に大抵説明されているからです。

ところがよくあるケアレスミスは、矢張り、大小関係などの判断分岐での単純なミスです。
これも単純ミスの一つですが、データサイズの誤りは発見しづらいものです。
デバッグ時に入力データに異常データを想定しない限り発見されません。

データサイズの誤りで最も発見するのに困難なバグは、異常データを入力してチェックしても発見されないバグです。

大方そのようなバグは複合的なバグであると考えた方がよいかと思います。
偶々同時に二つ以上のバグが絡むような状態であるとき、異常データを入力してもみかけ上正常に見えることがあるからです。

よりスピーディーにデバッグをしようとする昨今の傾向では、一遍に様々なバグを想定したデータを流す自動化したデバッグが通常行われますが、余程綿密な計算の下でデバッグを行わないと複合的なバグは発見されないこともあります。

何よりも大切なのが、プログラムのコーディングの前に、全データのサイズや個々の判断分岐の条件などをすべて一覧表にまとめておき、一覧表に沿ってコーデイングすることです。
ついつい時間に追われて、「最後のデバッグでまとめてバグを発見できればいいか」などと思いがちですが、いざそのとき綜合検査でプログラムのなんらかの欠陥が発見されたときは、バグ取りに多大な時間をかけることになります。

運よく欠陥が発見されればよいですが、先ほど述べたように、複合的なバグの場合、正常にみえてしまう場合もあります。
このような事態は最悪の結果を招きます。
すなわち、製品として出荷されてからプログラムの暴走が始まるからです。

私なども、現役でプログラミングなどに携わっていたころは、ときに時間に追われて横着をしたためにバグ出したりして、後でよく後悔したものです。
私の場合、規模が小さいものが多かったのでバグの発見も容易いものでしたが、大規模なシステムでは、横着することは絶対に禁物です。

2015/11/12 by Y.K