MORE契約プログラミングって知っていますか2016.01.05こんにちは、プログラマの安藤です。契約プログラミングっていっても、取引業務で口座の残高を操作するようなプログラムではありません。バグを出さないようにするプログラミング手法のことです。プログラムを構成する手続きには、すべからく処理を実行する前の前提条件があります。当たり前ながら手続きを実行した後には何らかの結果を残さねばなりません。ここで大事なことは、手続きの前提条件と結果をはっきりさせておくことになります。専門用語を持ち出すと、手続きを実行する前にかならず成り立っていなければならない前提条件のことを手続きの事前条件といいます。実行後に必ず成り立っていなければならない条件を手続きの事後条件といいます。先ほどの前提条件と結果をはっきりさせることっていうのを、「手続きの事前、事後条件を表明する」あるいはもっと簡潔に、手続きの表明っていいます。先生が1980年代に提唱した手法です。簡単にいうと上記の手続の表明を呼び出し側と実装側の間の契約とみなしましょうってことです。甲に与える」ということを書面(手続きの仕様)にするわけです。事前条件が破られたときは手続きを呼び出す側が契約違反。呼び出し側のコードにバグがあるってことになります。事前条件が満たされていて手続きが正常に終了したのに事後条件が破られる場合は手続きの中のコードにバグがあるってことになります。このように前もって手続きの表明をはっきりと文書にしておけば(手続きの仕様をコードと一緒に書いておけば)問題の責任の所在が明確になります。いざ不具合が起こったときにどこを修正するべきかはっきりするってわけです。これでバグの9割は回避できる。残りの一割が難しかったりするのですが。このようなことは、プログラミングを覚え始めのときに最初の指導者に叩き込まれるべきなんですが、残念ながらあまり意識しないでプログラミングしている人がまだまだ多い。そりゃあ、仕事していて手続き仕様のコメントばかりに時間かけてられないって気持ちは良くわかる。これをやっておかないとテストファーストができない。それに結局はデバッグ期間に手続きの表明をはっきりさせてゆくことになるぞ。デバッグ期間はなるべく短いほうが健康にいい(マジで)ところで、先ほどの事後条件違反のときの責任の所在の話。場合は手続き側のバグこの理屈からいえば、手続きが異常終了したときは、事後条件が破られていても手続き側のバグとはいえないってことになります。「異常終了って?そんなのありえない」と、いう声が聞こえてきそうですが、残念ながら世界はそんなに単純じゃない。