Blog ブログ

こんにちは、プログラマの安藤です。

　さて、契約プログラミングっていっても、取引業務で口座の残高を操作するようなプログラムではありません。バグを出さないようにするプログラミング手法のことです。

プログラムを構成する手続きには、すべからく処理を実行する前の前提条件があります。そして当たり前ながら手続きを実行した後には何らかの結果を残さねばなりません。
ここで大事なことは、手続きの前提条件と結果をはっきりさせておくことになります。

専門用語を持ち出すと、手続きを実行する前にかならず成り立っていなければならない前提条件のことを手続きの事前条件といいます。
また実行後に必ず成り立っていなければならない条件を手続きの事後条件といいます。
そして先ほどの前提条件と結果をはっきりさせることっていうのを、「手続きの事前、事後条件を表明する」あるいはもっと簡潔に、手続きの表明っていいます。

契約プログラミングというのは、Bertrand Meyer って先生が1980年代に提唱した手法です。簡単にいうと上記の手続の表明を呼び出し側と実装側の間の契約とみなしましょうってことです。

契約とは要するに「条件つきの約束」であり「甲が条件Aを満たしたときに限り、乙は仕事をした結果 B を甲に与える」ということを書面（手続きの仕様）にするわけです。

事前条件が破られたときは手続きを呼び出す側が契約違反。つまり呼び出し側のコードにバグがあるってことになります。
事前条件が満たされていて手続きが正常に終了したのに事後条件が破られる場合は手続きの中のコードにバグがあるってことになります。

このように前もって手続きの表明をはっきりと文書にしておけば（手続きの仕様をコードと一緒に書いておけば）問題の責任の所在が明確になります。つまり、いざ不具合が起こったときにどこを修正するべきかはっきりするってわけです。
これでバグの９割は回避できる。まあ、残りの一割が難しかったりするのですが。

このようなことは、プログラミングを覚え始めのときに最初の指導者に叩き込まれるべきなんですが、残念ながらあまり意識しないでプログラミングしている人がまだまだ多い。

そりゃあ、仕事していて手続き仕様のコメントばかりに時間かけてられないって気持ちは良くわかる。けどね、これをやっておかないとテストファーストができない。それに結局はデバッグ期間に手続きの表明をはっきりさせてゆくことになるぞ。デバッグ期間はなるべく短いほうが健康にいい（マジで)

ところで、先ほどの事後条件違反のときの責任の所在の話。手続き側のバグの定義がちょっと持って回った言い方に思えませんか？

この理屈からいえば、手続きが異常終了したときは、事後条件が破られていても手続き側のバグとはいえないってことになります。

「そんな！呼び出し側に何の落ち度もないのに手続き側のバグじゃないなんて!!」
「異常終了って？そんなのありえない」

と、いう声が聞こえてきそうですが、残念ながら世界はそんなに単純じゃない。

手続き A が 手続き B を呼び出して、B がまた 手続きC を呼び出す場合。

( A は B の事前条件を満たした) → Aに落ち度はない。
( B は C の事前条件を満たした) → Bに落ち度はない。
このときに、C が事後条件を満たさなかったせいで B は事後条件を守れなかった。

このような場合、手続き B にバグがあるとしてしまうとBが可愛そう。Bにはなんの落ち度もないのに。それにかえって責任の所在が曖昧になります。
 それならばC のバグかっていうと、これもそうとは言い切れないことがあります。 C もまた他の手続きを呼び出していることがあるからね。

この呼び出しの連鎖を最後までたどっていくと、 OS のシステムコールを介して、実際のハードウェアを操作し、現実世界を飛び回っている信号を扱うことになります。

ゲームを通じて現実世界を操作するの図

あれ、不具合の原因がプログラムの外にいっちゃったね。プログラムのどこにもバグが無いのならあとは知らね、めでたしめでたし。

って そんなわけがない！！！

論理的に完璧にバグの存在しないプログラムってだけじゃあ製品としては不完全なのだ。

こと、ここに至ってこれまで論理と妄想の世界に浸っていたゲームプログラマは、無慈悲な現実世界に向き合って途方にくれるのでした。けどね、世の中の役に立つコードを書いているプログラマはずっとそういうことをやっているのよ。

ともあれ、いまどきのゲームプログラマはプログラムの範囲外で起こったエラーにも対処しなけりゃなりません。完璧に閉じた世界でハードをすべて制御できていた２０年前が懐かしい。

エラー処理の話に続きます。

採用情報