■
こないだの続きです。
変更に強い構成を作る
変更に強い構成、とはどういったものか考えてみます。
だいたい以下の要件が満たせているかどうか、ではないかと思います。
- 1つの変更が発生した場合、変更箇所が1箇所だけで済む。
- 1つの変更で変更した場所への回帰テストが、非常に小さい。
- 変更箇所を特定しやすい。
- 変更した際、他の部分に与える影響が少ない、または無い。
確かに、これらの要件が満たされていなければ、
- 1つのモジュールに変更が発生しただけで、複数（場合によっては全部）のモジュールに対して、同じ変更を加えなくてはならない。
- 1つのモジュールに変更を加える為に、別の機能にも変更を加えなくてはならない。
- 1つのモジュールに変更を加えたせいで、機能全体に回帰テストを実施しなければならなくなる。
といった辛い出来事に簡単に出会えそうです。
その結果を想像するとぞっとしますよね。
- 1つの変更
- 複数のモジュールを調査
- 他の機能も含めた複数のモジュールを変更
- 変更した全ての機能に対する回帰テストを実施
- 納期は既に過ぎていた
こんな感じでしょうか。
単なるプログラム構成、とするにはあまりに被害が大きいですし、こういったコストのかけ方をしているプロジェクトでは、きっとあっという間に赤字を出すようになります。
変更に強い構成を作る為のリスク
では、変更に強い構成を作らなくては、と言っても簡単に実現できるかと言うとそうでもないです。というか、簡単に出来るのであれば、我々の業界なんてとっくになくなってます。
そこで、いったいどんなリスクが潜んでいるのか考えてみました。
- 変更に強い構成を実現する為のコスト。
- 変更への強さが求められない可能性。
変更に強い構成を実現する為には、少なくとも経験豊富、または知識が豊富なアーキテクトの参画が不可欠だと思います。と言うのも、変更に強い為にはモジュールの結合度を下げる為、凝集度を上げた設計をする必要があります。その結果、Javaに代表されるようにモジュール数が爆発的に増加してしまった場合、成果物の管理対象がそのまま増えてしまいます。
また、変更に強い構成に設計した後も、プログラムに対する変更の全てが終わるまで監視し続ける必要もあります。構成要素がプログラムである為、アーキテクチャを無視した実装をしようと思えば出来てしまいます。開発者が、アーキテクチャ設計者の意向を履き違えたり、無視したりするだけで、変更への強度はあっという間に崩れ去ってしまいます。
構成を設計するコストと、それを維持していくコストが必要な訳です。
ここまで労力を払ってまで、変更に強い構成を実現しなくても良い、という意見もあります。
エンジニア目線ではあり得ない話ですが、変更に強い構成によって例えば仕様変更などで発生する作業が少なくなれば受注時に請求する金額が安くなってしまう、という意見です。非常に近視眼的な発想ですが、当面の売り上げを保ちたい等の事情があるだけで簡単にまかり通るようになってしまう意見です。こういった意見を持った人間が営業や管理職にいた場合、変更に強い構成を作ろうという発想はそもそも間違っている、という評価を受けるでしょう。
個人的には、これに更に
- 変更に強い構成であっても、必要な変更は減らない。
とも思う事が時々あります。
3層にレイヤリングした構成としていても、1つの要件が変更になった場合に殆どのケースが、この3層全てに変更が発生します。この場合、どのように設計しても、そもそも設計の前提となる要件が変わる訳ですから、その設計を変更する必要は必ず発生します。
変更に強い構成にする、という事は、無駄な変更を増やさない事であって、必要な変更は絶対に無くならないんです。まぁ、考えてみれば当たり前の事なんですけどね。
