ソフトウェアの品質要因 その２「拡張性」
拡張性(extendibility)
■定義：拡張性(extendibility)
「拡張性」とは、仕様の変更に対するソフトウェア製品の適応のしやすさである。
拡張性と規模の関係
ソフトウェア製品のおいて、拡張性の問題のほとんどは規模に起因する。小さなプログラムの変更は、基本的にあまり難しい問題にはならないが、
規模が大きくなるに比例して、拡張性の問題は広がっていく。
変更を意識する
非オブジェクト指向的なソフトウェア工学の手法では、変化を十分に考慮していなく、初期の分析の段階で要求を凍結し、残りは設計と実装に費やすという工程を踏んでいた。
これは、仕様は「変わる」という前提を取り除き、固定された問題に対してのみ解決を目指す手法で、
実装は要求に対する機能のみにしぼって考えればよかった。この考え方は効率も悪くないし、
考え方として間違ってはいない。だがしかし、オブジェクト指向を中心としたソフトウェア工学が整ってきた今、
「ソフトウェアに対する要求は変わる」という中心的な問題を認識する必要がある。
ソフトウェア開発における変化は、不規則に不特定多数発生する。
要求の変更、要求に対する理解の変化、アルゴリズムの変更、データ表現の変更、
実装方法の変更・・・などといった変更に対してサポートするために、
常に「変更」について意識することが、オブジェクト指向技術*1の基本的な目標のひとつである。
拡張性を向上させるための２つの原則
■設計の単純さ(design simplicity)
単純なアーキテクチャは、常に複雑なアーキテクチャよりも変更に適応しやすい。
オブジェクト指向において、設計は「簡明さ」が重要である。
要するにシンプルであることを求めるということです。
はじめに頭に浮かんだ設計プランが、もし少しでも複雑であるならば、
もっとシンプルにすることはできないのか、再検討する価値は大いにある。
■非集中化(decentralization)
クラス(モジュール)の自治性が高まるほど、単純な変更が与える影響が１つまたは、
少数のモジュールにとどまる可能性が高く、システム全体に及ぶ変更の連鎖反応を起こしにくい。
これは分散性、あるいはクラス(モジュール)の独立性とも言う。
つまり、クラス(モジュール)が多くの責任を負わないことを意味し、１つの責任のみを負うことです。
これは、「単一責任の原則(the Single Responsibility Principle)」といい、SRPと略されます。
開発者向けに言えば「クラスの変更理由は１つでなければならない」とも言えます。
ただし、「単一責任の原則」は、絶対的なものではなく、どちらかというと相対的に捉えるべきこと。
将来的に変更される見込みがないところを、責任を分けるためだけに、
むやみに分割しても効果は期待できません。逆に、無意味な複雑さを産むだけ。
変更可能性のある場合にのみ、責任の分離を行えばよい。
変更可能性なんてわかりえない
将来に渡る変更の可能性について、正しく判断することなどできるのだろうか。アジャイル開発を語るとき、XP*2の有名なプラクティスの１つに、「YAGNI(ヤグニ)」というのがある。
"You Aren't Going to Need It"
「いま必要のあることだけをやれ」
つまり、変更可能性うんぬん言ってないで、今必要なものだけ作りゃいいじゃんというｗ
まったくその通り。と思ったり、それを言っちゃーおしまいよ。と思ったりしますが(´・ω・｀)
状況に応じて、いろいろと感じ方の変わる言葉ですねヤグニ。
