身につけるべきプログラマの習慣 その６

試験でのバグ出しは誉れ

バグ出しでたくさん発見されると成績を下げるという評価があります。これは最低です。

また、バグ出しなのに、自分のコードにバグが見つかるといちいちがっかりして落ち込む人を見かけますが、それもおかしいですね。

バグというのは、人間なのだから必ず入り込むものです。その率は人によって異なりますが、多かれ少なかれ必ず入り込むのです。

最終的にバグを取り去れば良くて、途中でのバグの件数自体は問題ではありません。

試験の局面においては極力バグを洗い出すことが重要で、次の行程に問題を残さないようにしなければならなりません。

だから、既にできたコードに対しては、極力バグを残さないようにできる限り多く発見することが誉れであって、恥ではないのです。

もちろん、バグにも質があります。単純なミスが原因なものもありますし、ロジックをよく理解しないまま当てずっぽうに書いたコードが動かない、という最低レベルのものまであります。

後者の場合、プログラマの資質にまで問題の範囲が及ぶことになります。動くはず、という確証のないままコーディング行程を終了させたのは深刻な問題かも知れませんね。

また、単純なミスであっても、あまり多発するようではデバッグを含め、余分に工数を要してしまうことにはなります。

プログラミング時にいかにバグを入れないようにするか、それもソフトウエア工学の１つです。そういったことをちゃんと守った上で発生するバグは、通常さほど深刻なものにはならないはずです。

もし、バグを恥じるのであれば、納品後に発生すること、あるいは、バグの量ではなく、悪質なバグに対してなのではないでしょうか。

笑い話？

３０年位前の、大手企業での実話です。

バグの発生率は統計的に決まっているという点に着目し、ある人の出したバグがその範囲に収まっていない場合、試験を通過させないというものでした。

これはバグが多発した場合もそうですが、バグが少なすぎても試験をパスさせないのです。

そこで、あるグループのリーダーは、バグが少なすぎるプログラマに対して、わざとバグを入れ込めという命令を下しました。

プログラミングの本質を理解していない、あるいは、その内容を理解しないまま評価しようとすると、こういう馬鹿げたことになるのでしょうね。無能な管理者が前提の方法論なのです。