■

契約的プログラミング、というものがあります。
その対義ではないですが、防衛的プログラミングというものもあります。

契約的プログラミングとは、プログラムを作る際にある程度の前提を置いて製造する事を言います。
簡単に例を挙げると、ファイルをオープンして中身を読み込み加工して別のファイルに出力する、という単純なプログラムを作る場合、オープンするファイルが存在する事、ファイルの中身が正しいフォーマットで記録されている事、出力先のファイルが既に存在していない事等を前提として、作るのが契約的プログラミングです。
防衛的プログラミングとは、これらの前提を一切信用しません。オープンするファイルがあるかどうか、記録されているフォーマットは正しいか、無事出力出来る状況が整っているか、などを検査する為の機能も合わせて、プログラムを作ります。

どちらが正しいかと簡単に答えを出せるものではありませんが、仮にバグが見つかった場合、契約を決めた人間とプログラムを作った人間、どちらが責められる、または修正させられるかを考えると、防衛的プログラミングをした方が良いような気になってきます。（現実的には、そんな煩雑で単調で冗長な機能を都度組み込むくらいなら、テストをしっかりやろうという気になると思いますが。。。）

まとめてみると、こんな感じになるかと思います。

• 契約的プログラミング
  • 利点：プログラム一つの機能がサービスに対して必要最低限になる。
  • 利点：プログラムの持つ機能が少なくなる為、テストパターンも同様に少なくなる。
  • 欠点：プログラムが持つ前提条件が崩れると、動作しなくなる可能性が高い。
  • 欠点：欠陥が生じた場合、前提条件を崩した人間ではなく、それを受けきれなかったプログラムを作成した人間が責められるか修正させられる。
• 防衛的プログラミング
  • 利点：一つのプログラムで機能が完結する。
  • 利点：前提条件を崩されても欠陥が生じない為、そのプログラムを作った人間は責められないし、修正は前提条件を作る側に発生する。
  • 欠点：プログラムの持つ機能が多くなる為、テストパターンが膨大になる。

抜け漏れもあるかも知れませんが、だいたいこんなところでしょうか。

これはリー・コープランドという人が書いた「はじめて学ぶソフトウェアのテスト技法」にあった話なんですが、なるほどなと思ったのでご紹介しました。

Webアプリケーションでは、通信プロトコルとその送受信、次いで送られてきたメッセージをアプリケーション用に変換して、アプリケーションで処理をして、またブラウザが受け取れる形に整形する、など前提となる条件が多すぎるので、防衛的プログラミングは不可能だと思います。仮に頑張ってやるとしても、そもそもライフサイクルの短いWebアプリケーションでは満足な製造期間も確保できないでしょうし、現実的ではないですね。反面、組み込み系と呼ばれる単体で稼動する事を前提とした場合は、誤作動時の被害の甚大さもあり、防衛的プログラミングにならざる得ない事もあるかと思います。

話をWebアプリケーション向けにしますと、以上のような事などを踏まえて、プログラムの前提条件に対する依存度が改善できない為、次なる秘策と言えるものが「オブジェクト指向」ではないか、と考えています。変更というものへの柔軟さとそれを更に容易にする為に複雑さを解消する事で、完璧な防衛にならないにしても被害を最小限に抑える、というアプローチを実現しようとしているのだと解釈しています。

このあたりはまた後日、じっくり書くとしますね。