パターン31:名前が付けられた安定したバージョン

   

 

問題:

どのような頻度で結合を行いますか?

コンテキスト:

スケジュールの大枠は決まった。

影響する事柄:

結合が連続して続き、開発者は動いている標的を追いかけようとしている。

結合と結合の間の時間が長すぎると、以前の結合バージョンの制約により、開発者の進捗が滞ってしまう。

安定はよいことである。

進捗しなければならない。

進捗は肌で感じられなければならない。

解決策:

変更が1週間に1回を超えないように、システムインタフェース(アーキテクチャ)を安定させなさい。システムインタフェース以外の部分についてはそれより頻繁に変更があってもいいし、結合されてもよい。

結果として生じるコンテキスト:

プロジェクトは撃つべき的を持つ。これは、顧客から見たプロセスの観点に影響し、アーキテクチャ設計者にとっても強い影響を与える。

論理的根拠:

影響する事柄の説明を参照してください。このパターンはAT&TのDennis DeBrulerによるものである。このパターンの要点は、変更の影響が予期できるように変更の導入を計画しなければならないということである。変更の内容を広報することよりも(ボリュームが大きすぎると注意されない)、開発関係者が変更が発生したことを知ることの方が重要である。「驚きを最小にする」というルールを破らないことが重要である。

安定の度合いに応じて、同時に複数個の結合バージョンを持つことが有効である場合がある。例えば、あるAT&Tのプロジェクトは、毎晩ビルドし(コンパイルされたことが保証されているのみ)、週毎に結合テストのためにビルドし(システム全体に渡る確認テストが保証されている)、そして(隔週程度で)テスト完了版のビルド(QAのシステムテストに対しても十分安定なもの)を提供した。