背景
コンポーネントが運用していく中で徐々にメンテ性だけではなく、
再利用性の観点(全再利用原則)の考察の優位性も出てきた際に、
再利用の単位でまとまっていてほしいし、かつ
メンテ性も維持しておきたいので、コンポーネントが細かく分割せざるを得ない。
すると、分けたコンポーネントのリリースの単位の考察も必須になってくる。
この考え方は、サービス設計の際にも重要な思想。
再利用・リリース等価原則
アジャイルソフトウェア開発の奥義には以下のように書かれている。
--引用--
「再利用の単位が、リリースの単位よりも小さくなることはない。」
--引用終わり--
再利用したいコンポーネントの内部の要素に、再利用したいものとそうでないものとが
混在しないように設計せよ っていう思想はCRPと共通であると感じる。
何をいってる原則か？
ここでは簡単のためにパッケージの事例で考えることにする。
クライアントパッケージaから見て再利用したいあるパッケージbのうち、
クラスX、Yはリリースver1.0のを使いたいけども、
クラスSはver1.2のを使いたいとかっていう時、
当たり前だけどクラスXとYは同じパッケージにまとめるけども、
Sに関しては別のパッケージに分けたくなるっていう原則。
つまり、再利用という観点でまとめられたコンポーネントを構成する
クラスやモジュールなどは、まとまってリリース可能な単位でないといけないってこと。
なぜ守るべきなのか？
もしも纏められ方が、同じVer番号を共有し、同じリリースプロセスを経ていなかったら
どのような問題があるだろうか？
そもそもリリース番号が振られていなかったりすると、互換性の担保ができなかっらりするし、
変更が何度か入ったコンポーネントの何個手前までのものならサポートしているのか？
さえ追跡が不可能になってしまう。
仮にVerが振られている状態でも、
パッケージaから見て、パッケージbのVerがVer1.2となっていたとしたら、
aからすれば詳細な中身を見ずとも、中身のクラスはすべてVer1.2の状態であってほしい。
にもかかわらず、一部分だけ古いVerのものが混在するような状態では、
めちゃくちゃ再利用時の使い勝手が悪いことは自明である。
それこそ、パッケージbの蓋開けて、すべてのクラスを見るんかい！ってなるから
情報隠ぺいもへったくれもない。
クライアントパッケージはそんなこと意識せずとも、利用したいわけだから、
リリース番号が同じ単位で、クラスやモジュールはまとまっているべきという、
この原則の発想はいたって自然なことである。