防御的プログラミングしない後ろ向きの理由

防御的プログラミングしない「後ろ向き」の理由として、私が経験した中では、次のようなものがあります。

• きちんとした作りこみやテストを行わずに、システム全体の結合開始日が来たので結合したら、assertで停止してしまう。システムがブートできなからassertを外せと指示された。
• 自分のモジュールで防御的プログラミングを行っていると、呼び出し側が悪いのにいつも自分のモジュール内で停止してしまい、都度障害だと言われて調査させられる。そんなの嫌だから、防御的プログラミングをしない。
• QAチームによるテストで、問題があって防御的プログラミングにより「システムエラーと表示されて」停止すると、詳細な報告を求められる。毎回詳細に報告させられるのが面倒なので、防御的プログラミングをしない。

このような後ろ向きの理由で防御的プログラミングをしないことにより、発生した障害の調査時間が長くなり、結果的にはプロジェクトは遅延していくのです。

コメント 1

いつも興味深く拝読させて頂いています。
このようなお話を伺うと、分野は違いますが無停止杼換式豊田自動織機の「糸が切れた時に機械を自動的に停止させて不良品の発生を未然に防止する」という仕組みの斬新さを改めて思わずに入られません。ソフトウェア開発でもTPSやリーン生産方式という言葉をよく耳にするようになりましたが、その真意がソフト開発のものになるのはまだ時間がかかるのかなと感じます。
by E_Mattsan (2010-06-02 09:06)