■ [開発][プログラミング]防衛的プログラミングで開発効率をあげるには 
- 防衛的プログラミングと契約による設計(http://d.hatena.ne.jp/ABA/20050908#p1)
一見防衛的プログラミングのように見えるコードが書かれているのに実際にはエラーが出てもたまたま停止せずに素通りして動いているだけ、という危険なコードをよく見かける。
使い方を間違っているのに無視されたり、適当にスルーしつつ中途半端に動作してしまって肝心なときにバグるようなシステムを使うのは怖いし、ちょっと引数を間違えたくらいでわけのわからないところで止まってしまうようなつまらないバグを追いかけているムダな時間も意外と馬鹿にならない。よほどクリティカルな部分でないかぎりは少々チェックを入れたくらいで実行速度に影響がでることは稀だろうから、再現性の少ないバグを減らすためにも範囲外の入力や不正なデータが来ることをあらかじめ想定しておくほうが好ましい。再現しにくいバグほど厄介なものはないのだから、面倒だからといってそのようなチェックを省くことは結果として最終的な開発効率を落としているように思えてならない。
バグを適当に握りつぶすコードを書かれるくらいならその場でNULLポインタでもアクセスして止まってくれる方がはるかにマシ。しかし、バグが起こってその場で止まる場合にも、ただ「停止する」のではなく、あえて「停止させる」ことが重要だと思う。だから、不正メモリアクセスで止まるように書くのではなくて、明示的にアサートを置いておくべき。
しかし、ただ停止させることも最良の解決策ではない。とくにデザイナーが触るような実機上のツールで止まられても、デバッガが使えない状況では何が原因で停止しているのかすぐにはわからないし、もしかするとその人の作業には直接支障のない、全く関係ないデータが少しおかしいだけで停止してしまっているのかもしれない。このような場合には何がおかしいのかをエラーログに吐き出しつつ作業が続行できるようになっている方がチーム全体の作業効率が上がるし、そもそもどんなにおかしなデータを出そうとも基本的にはシステムが停止すべきではない。頻繁に停止するようなシステム上で実機ツールなどを使った作業を行うのはかなりのストレスを伴うため、精神衛生的にもよろしくない。
休日出勤で他のプログラマがいないときに、自分の担当外のツールがよくわからないバグで停止してデザイナの人が作業にならないためにその原因を調べ、それだけでほとんど一日が終わってしまった、などという経験をしたこともある。大抵の場合は別の人がおかしなデータを出力してしまっているだけの事が多いのだけど、どこか変なところで停止しているという状況だけでは、その部分のシステムの知識がないと原因を調べるだけでも必要以上の時間がかかってしまうことが多い。
なにか問題が起こったときには関係者でなくとも意味のわかる適切なエラーを吐き、それが進行に致命的な問題を与えることがないのであればその処理をスルー（エラーのあるモデルのみ非表示にする、イベントが起動できないのであればイベント処理をスキップする等）する、などの簡単な対処を行うだけでも原因の割り出しにかかる時間を大幅に抑えることができるし、危険なバグを未然に防ぐこともできる。他に大きな問題がなければそのまま作業が継続できるので、無関係な人の作業や、締め切り前のバグ出しの効率も上がる。
「適切なエラー情報を出力する」「致命的な問題でなければ可能な限り正常動作に近づける」、とここまで対処してこそ本当に意味のある「防衛的プログラミング」になると思う。一見遠回りで面倒なように見えても、最終的に「安定した製品を高い開発効率で作る」という目標を達成するためには適切なエラー処理をきちんと書いておくほうがむしろ楽なのではないかと認識している。
