防御的プログラミングとテスト駆動開発

1978年に大学でプログラミングを学び始めてから1990年代まで、私自身は防御的プログラミングを行ったことはほとんどありませんでした。また、ソフトウェアのテストと言えば、手作業でテストするのが普通の時代でした。それは、私一人が防御的プログラミングをしていないとか、私だけがテストを手作業で行っているとかではなく、それまで属した開発組織がすべてそうでした。

2000年になり、コンサルタントとして設計レビューやコードレビューを行ってきたソフトウェア開発組織に対しては、徹底的に防御的プログラミングを指導してきました。防御的プログラミングを行うことは、トータルで開発コストを下げる活動です。

パラメータの値を検査するコードを書き加えるのは、ほんの数分のプログラミングで済みます。しかし、防御的プログラミングを一切行っていないモジュールを結合して、発生した不具合の原因を調べるのは、数分では終わりません。数時間、一日、数日、一週間、あるいは、原因不明となったりします。

デバッグに数時間を費やした後に、防御的プログラミングが一切行われていないために遠回りしてデバッグせざるをえなかったような場合には、「誰だ、こんなコードを書いたのは」と思ったりもします。つまり、防御的プログラミングを行ってくれていたら、数分で原因が分かることもあるのです。

2003年から、さらにテスト駆動開発によるソフトウェア開発を2009年まで行っていました。ソースコードをリファクタリングしながら高品質に保ち続けるには、機能を自動テストする仕組み（モック、スタブ、テストフレームワーク、エミュレーション等）とテストコードは不可欠です。この場合でも、防御的プログラミングは必須です。システム全体を結合してテストする際に、テストコードでは想定していなかった使用方法や誤った方法による障害の調査を短時間で行うためにです。

ソフトウェア開発では、様々なベストプラクティスを上手く組み合わせることで、飛躍的に効率が良くなったりします。防御的プログラミングとテスト駆動開発だけが「銀の弾」ではありませんが、それらを全く行っていない組織と、着実に実践している組織では、開発工数として費やす時間の内容が大きく異なってきます。

どちらも全く実践していない組織は、手作業によるテストと障害の調査に多くの時間を費やすことになります。1990年代までなら、それでも良かったかもしれませんが、大人数による大規模なソフトウェア開発では、開発スピードの大きな差となって現れてくることになります。