MVCの概念が特に有名ですが、近年の巨大システムは多層化された設計になっています。層間のやりとりは外部設計書という名目の書類で取り決められることが多いでしょう。このインターフェースを跨いだ両側の層の開発者はこの設計書という「契約」に基づいてプログラムします。そのため「契約に基づくプログラミング（programming by contract）」と呼ばれるわけです。
今回は、こうした多層化システムの開発でのバージョン管理についての考察です。

バージョンを管理するのはなぜか

そもそもなぜバージョンを管理する必要があるのでしょう？
一人で作って一人で使うようなプログラムでは特にバージョンを意識する必要はありません。不都合があれば直せばよいし、バージョン違いの複製も存在しないのであれば、そもそもバージョン番号なんていらないのです。

しかし、プログラムを配布するならば、利用者は自分以外を含めた複数となりますし、やれ障害が出ただとか、使い方がわからないだとか、そういった問い合わせへのサポートが少なからず発生するわけです。

その際に、バージョン番号というモノが必要になってきます。バージョンごとに挙動が異なるのですから、バグが出たのは何バージョンなのか、そこを確認できるようにしておく必要があります。そうしないと、修正したバグについての問い合わせがあるたびに既知のバグか未知のバグか調査する必要が出てきます。

多層化システムでは層ごとのバージョンが必要

業務で作る巨大なシステムは利用者の問い合わせに対応するためのバージョン番号は当然のことながら、層ごとに分割統治してバージョンをつける必要があるのではないでしょうか。このバージョンは利用者には提示されないバージョンですが、開発を円滑にするために必要なバージョンなのです。

例えば層が明確に分かれている例として、クライアント・サーバ方式のシステムを思い浮かべてください。
分からなければWebシステムとブラウザを想像してもらえば大丈夫。
システム全体としてのバージョンだけではなく、クライアントアプリケーションのバージョンとサーバアプリケーションのバージョンをそれぞれ管理しておく必要があることが容易に想像できるでしょう？

契約に基づくプログラミングをしていて、層の両側で開発者が異なるなら、層を挟んだ開発時のやり取りに互いのバージョン番号を知らせるのは効率のよい手法です。
開発チーム間でのやり取りが円滑になって憎き開発チームのメンバーに対する嫌がらせを考える時間を節約することも出来ます :-P

しかし、それではちょっと足りないのです。それは、「契約に基づくプログラミング」の「契約」の部分です。
契約にもバージョンを振る必要があるのです。

層ごとに組み替え可能なシステム

各層を独立したシステムと考え、層間の契約のバージョンも管理すれば、究極的には層ごとのバージョン組み換えが可能になります。このシステムはA契約1.03版とB契約1.12版に対応しているC層1.22版です、といった情報が管理されていれば、契約の部分が合致する範囲内でバージョンの差し戻しが可能です。

また、層の両方のバージョンが合わない場合でも、近いバージョンに対応していたソースを元に派生プロジェクトを作って対応することが出来ます(CVSやSubversionでのブランチを想定しています)。

もっとも、「契約」の部分はころころと仕様変更するべきではないのですが、現実問題として機能拡張の際に不足した分を追加するなどの修正が入るのが常です。この際に、契約のバージョンが変わるということを意識して見てください。すると、その契約をしているシステムのパーツはすべてバージョンアップが必要になるのです。

このような話題は、言われて見れば当たり前のようなことなのですが、無意識でいるか意識しているかで大きく変わってきます。多層化したシステムを設計されているなら層ごとのバージョンを意識して見てください。もっとフレキシブルに組み替え可能なシステムにすることができるかもしれません。