Design by contractでソフトウェア機能を記述する

Design by contractはソフトウェアの機能や関数/メソッドの事前条件、事後条件、いかなる場合でも不変である状態（条件）、を明らかにし、文書化する手法だ。機能や関数/メソッドが想定している範囲を明らかにし、想定外の使われ方を防ぐことにより不具合防止を支援する。

条件をソースコードに含めておき、条件を満たさない場合に、実行をやめたりするものを契約プログラミング（Programming by contract）と呼ぶ。assertのような言語仕様を使ったり、例外処理を使ったりして、機能や関数/メソッドが想定外の使われ方をしていることを明らかにする。

外部仕様に相当するドキュメントにはこれらの条件が比較的記述されていることが多いように思う。詳細設計、内部仕様やソースコードに記す場合には、対象の数が多くなることもあり、網羅的に記述するのはしんどいところだろう。形式的でないドキュメントに記す場合には、記述とチェックの両方が目視や手作業になる。

Design by contractの本質的な難しさは以下だと思っている。

• 正常系は書けるが異常系の網羅的列挙は難しい。
  正常系を客観的に書くのは異常系と比較するとラクにできる。異常系を網羅的に書くことは容易ではない。異常系をどこまで想定していいのかが判断がつかず、考えられる範囲で列挙したとしても十分に網羅できているかどうかがわからない。
• 条件の記述が既存の他サブシステム、他機能との関係にもとづいた相対的なものになる
  事前条件、事後条件、不変条件はなるべく未知のサブシステムや機能を考慮した記述になっている必要があるが、実際には相対的な記述になりがちで担当者が知らない範囲や母体の理解不足により考慮漏れが起こる。スクラッチから開発したり、同時期に開発されるサブシステムや機能は見通しがよい分、このような考慮漏れは少ない傾向にある。
• 正しく認識していても記述を間違えてしまう。
  「与えられる入力の配列のサイズは1000未満」と正しく認識していても、「配列サイズは1000以下」と記述してしまう等。事前条件、事後条件、不変条件の記述を間違えてしまう。修正に気がつくまでに実施したチェックがムダになってしまう。

Design by contractを導入する場合、どの粒度まで事前条件、事後条件、不変条件を記入するかを決めるのに時間をかけてよいように思う。自動化できなければ粒度とコストの間にはトレードオフの関係が成りたつからだ。品質の面では粒度は細かければ細かいほどよいが、コストの面では細かさが増すほどコストも増す。特に、条件の保守（拡張や修正による見直し）コストを見逃す場合があるので、配慮が必要だ。機能追加や改変に伴う条件の見直しは想定外のコストになる可能性がある。