私はいままでバグに対して深く考察する機会を持ったことはありませんでした。なぜならプログラムの製作者も利用者も自分だったため、気にかける必要性はまったくなかったのです。
経験を振り返ると、むしろバグによって学べることが多かったと言えます。どういった処理が重いのか、どうしてリークが発生するのか、メモリやディスクに対しどう気遣えばいいのかなどは、1度バグを作らなければなかなか気づけないものです。ですから個人の学習においては、バグは師であり好敵手であり好ましい面を持っていました。
しかし企業で作業する以上、バグには毅然とした態度を保たねばなりません。彼らはもはや排除すべき敵であり、自社製品の弱みです。しかもバグが作る被害は単なる資金のみならず、信用や人手など企業にとって資金以上に大切なものも奪います。まさに企業生命がかかってしまうのです。
ところが団体での開発は、個人での開発以上にバグを作りこみやすいのが現実ではないでしょうか。
関係者が多いということは仕様の理解不足を招きます。打ち合わせの必要性が生じることで開発に費やせる時間が少なくなりますし、他者と協調するための締め切りは開発に対する丁寧さを損なうでしょう。スキルの差による様々な問題も生じるはずです。たとえオブジェクト指向が集団による開発に向いているとしても、それですべてが解決するわけではありません。
よって団体での開発では、徹底したバグの撲滅が求められます。その主な手段が「テスト」と呼ばれる工程です。その種類は単体テストから運用テストまで数多く存在し、その手法や支援ツールも多数考えられています。雑誌やネットにも比較的情報は多いように感じます。
しかし本来、テストによるデバッグよりも開発時にバグを作らない方が大切なはずです。これは治療よりも予防が、リサイクルよりもリデュースが重要なのと同じ理由で説明がつきますし、これを否定する意見はないでしょう。
ところがこれに対する情報はあまり多くない気がします。私が勉強不足ということもあると思いますが、フレームワークの活用や継承によるコーディング量削減、そしてコードレビュー程度しか言及されていないのではないでしょうか。バグを作らない工夫、それをもっと考察する余地がありそうです。
最近はこうしたことについて考えていました。保守性に富んだ設計、経験やバグ情報の共有、そして各メンバーのスキル向上に解決の糸口がありそうですが……。
