防御的プログラミング（２）

防御的プログラミングに関して、いくつか記事を書いています。

• 防御的プログラミング
• 防御的プログラミングとテスト駆動開発
• 防御的プログラミングしない後ろ向きの理由
• 防御的プログラミングしない後ろ向きの理由（２）
• 防御的プログラミングとカバレッジ

防御的にプログラミングするというのは、公開ＡＰＩの仕様にその内容を反映するということです。つまり、不正なパラメータが渡された時に、どのように振る舞うか（どのような例外をスローするかとか）を仕様書に記述する訳です。しかし、開発組織として防御的プログラミングの重要性を認識していない場合には、次のようなことが起きています。

• 開発者の多くが言葉としての「防御的プログラミング」を聞いたこともない。
• ＡＰＩの仕様書には正常な場合の処理内容しか書かれておらず、不正なパラメータが渡された場合の振る舞いが何も記述されていない。
• 結果として、APIの実装コードでは不正パラメータの検査されていない。あるいは、検査はしているが例外をスローすることなく、単純にリターンしている。※

「防御的プログラミング」は「銀の弾」ではありませんが、ソフトウェアエンジニアの道具箱に入っていていつも使用すべきものです。この道具を持たないでソフトウェア開発を行っている組織は、膨大な時間を障害調査に費やしている可能性が高いです。

※　検査はしているが単純にリターンしていると、その不正と思われる値が本当に不正なのか、正常値の範囲の一つなのかが不明瞭となります。

コメント 1

全例外をキャッチして、適当な別の例外にラップしてスローしたり、キャッチはするけど何の処理もしないで戻り値を返す人も時々いますね。FileNotFoundException をキャッチして-1を帰したりとか。

FileNotFoundExceptionをそのままスローしてくれればファイル名やパスが間違っている可能性に即座に思いあたるのに、-1や別の例外を帰されると、そのエラーが何であるかを追跡するだけで丸一日を浪費させられたりします。
しかも、それが当たり前と思い込んでいて、-1を帰すことの何が問題かを全員が分かってなかったりするから達が悪い。
by TM (2010-09-28 05:42)