思い悩むblog 改め Buriに片思い日記

「ないわー祭」はコチラ
■YomeAlerm@Google Code
■FamilyManagementException研究会@Google Group
■ColdFusionフレームワーク[cfneo]
■Buri日本ユーザーグループwことburi-ja

2007-06-14 契約的プログラミングと防衛的プログラミング

[] を含むブックマーク のブックマークコメント

契約プログラミング、というものがあります。

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


契約プログラミングとは、プログラムを作る際にある程度の前提を置いて製造する事を言います。

簡単に例を挙げると、ファイルオープンして中身を読み込み加工して別のファイルに出力する、という単純なプログラムを作る場合、オープンするファイル存在する事、ファイルの中身が正しいフォーマットで記録されている事、出力先のファイルが既に存在していない事等を前提として、作るのが契約プログラミングです。

防衛的プログラミングとは、これらの前提を一切信用しません。オープンするファイルがあるかどうか、記録されているフォーマットは正しいか、無事出力出来る状況が整っているか、などを検査する為の機能も合わせて、プログラムを作ります。


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

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

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

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


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


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


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

EnogunoCapEnogunoCap 2007/06/15 12:34 M男です。 なるほど・・・たしかにオブジェクト指向なら、とっかえとか多そうなところは契約PGMで、お金とかが絡んで失敗が許されないところでは防衛PGMで、なんてメリハリの利いたアーキテクチャを表現できますね。いろんなフェーズで。

itengineeritengineer 2007/06/16 00:28 そのプログラムや実装する機能にもよりますが、基本は契約的プログラミングにならざる得ないかな、と思ってます。例に挙げたファイル入出力のような簡単なプログラムならともかく、業務システムになるとUIやRDBが絡むので、防衛線を引くにも「ある程度まで」といった線引きは必要になるんでしょうね。
ただし、厳密に言うとお金が絡まない機能はそもそも作るべきではないので(便利ツール除く)、そういった視点で見るならば全て防衛的プログラミングでの実装をすべきでしょう。。。ま、無理ですが。

トラックバック - http://d.hatena.ne.jp/itengineer/20070614