防御的プログラミング

ソフトウェア開発でのデバッグ効率を左右する要因は多くあります。長年、様々なソフトウェア開発を行い、デバッグに苦労していると、デバッグ効率を向上させるためどのようなことを行うと良いかを考えたり、書籍を通してヒントを得たりして、色々と工夫をするようになります。

デバッグ効率を向上させる方法の1つとして、防御的プログラミングがあります。防御的プログラミングでは、たとえば、メソッドのパラメータが正しい値であるかをきちんと検査して、不正であれば、例外をスローするということがあります。あるいは、switch文のdefaultラベルでは必ずAssertionErrorをスローするとかも一種の誤った設計に対する防御的プログラミングです。もちろん、呼ばれた側の設計上のバグであれば、それを検出してもAssertionErrorをスローしたりすると思います。これは、自分の想定している設計以外の状況が発生したらそれを検出するという意味で防御的プログラミングと考えてもよいです。

つまり、誤りをできる限り早い段階で検出して、検出した時点でシステムを停止することで、デバッグ効率を上げる訳です。停止させれば簡単に現象の確認と原因調査ができるかもしれないのに、停止させないでシステムを動作させると、全く別の不具合として現れてしまい、調査に時間を要してしまいます。したがって、きちんとした開発組織であれば、防御的プログラミングの重要性を理解して、コード作成段階から徹底的に防御的プログラミングを行います。

防御的プログラミングだけが「銀の弾」ではありませんが、ソフトウェアエンジニアの道具箱に入っているべき道具の1つです。そして、防御的プログラミングは、「型」だと私は思っています。つまり、初心者には頭ごなしに教えるべきことだと思っています（「型」覚えずして上達なし）。したがって、「型」が教えられていなく、実践されていない開発組織というのは、「型の練習をしない柔道道場」のようなものだと思います。決して強くなれません。