[]変更容易性
オブジェクト指向を使って再利用性の高いモジュールの開発を目指したことが何度かありますが、残念ながら上手くいきませんでした。部品はなんとかできあがったものの、抽象度が高すぎて新規開発する部分が多すぎたり、逆に抽象度が低すぎて再利用するには部品にかなりの手を入れないといけないという結果に終わりました。
理由は、私やチームが未熟だったということもありますし、部品の開発と部品を使ったアプリケーションの開発を分離していたので、作った部品と実際に部品が使われる環境とが大きく乖離していたということもあります。また、平鍋さんの記事にもあるように、一般にオブジェクト指向による再利用は難しいようです。
では、オブジェクト指向は使えない技術なのかというと、そんなことはありません。上の記事にもあるように変更容易性を高めるための優れた技術だと思います。私がオブジェクト指向に求めるべきものは再利用性より変更容易性なんじゃないかと、考えるようになったのは自分の設計を見つめなおしているときでした。
そのときも、高い再利用性を目指して設計していたのですが、自分で書いた設計を見て嫌になりました。「なんて変更しにくい設計なんだろう。あとでこの辺やあの辺が変化しそうなのに、これじゃ後で絶対手を入れる羽目になる。面倒すぎ。保守したくないな」と感じたからです。そう考えると、今の分析・設計のやり方に疑問を感じました。このままでは保守が大変になるのは目に見えていたし、これまでの経験上、高い再利用性が得られる保障もなかったからです。そこで思い切って高い再利用性を求めないことにしました。今の自分の実力では再利用性の高いものなんて作れない、それならせめて保守しやすいものを目指すことにしたのです。視点はいかに様々なシチュエーションで再利用できるかということから、いかに保守しやすくするか、後でできるだけ手を加えないで楽ができるように作るにはどうしたらいいか、ということへとシフトしました。
保守性の高い設計をする際に、私なりに気をつけたことが三つあります。
1. 必要なときには作り直す
どんなときでも再利用できる部品、そういうものができたらどんなに素晴らしいでしょうか。現実にはそれは困難です。再利用性の目標を高めれば高めるほど、実際に設計する部品はあいまいになります。また、できあがったもののそれが本当に将来の再利用に使えるのかどうかは誰にも検証できません。当たり前ですが、この「部品を適用できる範囲」という概念は非常に重要です。残る二つの項目も、この範囲という概念がなければ考えることができません。「高い再利用性」を目指していたとき、私はいつの間にか際限なく再利用可能な幻の設計を目指していたようです。それに対して、保守性を目指す立場から見てみると私はそのソフトウェア部品を保守すべき範囲がある程度見えてきました。そうしてようやく、範囲を逸脱したときには部品の保守を諦めて新たな部品を作る、という現実的な選ｎ択ができました。
2. シンプルにする
不要なものが多ければ変更は困難です。たとえちょっとした変更を加える場合にしても、大量の変更する必要のないものの中から変更すべきものを見つけ出さなければならないからです。また、変更すべきものとする必要のないものが密接に関係していると、本来は変更する必要ない部分にまで手を入れなければなりません。シンプルにするには、本当に必要なものは何か、必要最低限の機能／データを見つけることが重要です。ソフトウェア開発の本ではありませんが、「もの・こと分析」はシンプル化するための視点を与えてくれます。
テスト駆動開発（ビヘイビア駆動開発）とリファクタリングも有効です。
テスト駆動開発はどう作るかよりも先に、何をすべきかを明確にします。いいかえれば、手段ではなく目的を先に考えます。リファクタリングは、システムの外的な振る舞いを変えずに内的な構造を改良する行為です。テスト駆動開発とリファクタリングを組み合わせることで、目的を達成でき、しかも可能な限りシンプルな設計を目指すことができます。
3. 柔軟にする
もしも、予め何がどのように変化するかわかっているのであれば、そのような変化を受け入れられるように設計することができます。「既存の設計は変えず、要求の変化に対処する」。これはオブジェクト指向の原則の一つ、開放閉鎖原則です。この原則を満たす設計にするには、デザインパターンが役に立ちます。デザインパターンは再利用性だけでなく、保守性を高めるためにも多いに役に立つようです。ソフトウェアを保守し修正するということは、ある意味では再利用だからでしょう。修正した後のソフトウェアは、修正前のソフトウェアの大部分を再利用しているからです。それでは、予め将来起き得る変化を知ることはできるのでしょうか。将来どのように変化するか知ることは困難ですが、「どこが」変化しやすいかを知り、可変にすることはできます。たとえば、データ集合を保持するソフトウェアがあるとします。データの表現形式には、配列やリスト、XMLが考えられます。また、保持するにはメモリ上に持つ、ファイルやDBに保存することもできます。何が適しているかは、表現するデータの特性や利用目的次第で変化します。将来、これらがどのように変化するかがわかりませんが、どこが変化するのか、つまりデータの表現方法や保管方法が変化することは予想できるのです。
多くの場合、シンプルさと柔軟さは相反しますから、トレードオフを見つけなければなりません。経験則＆リファクタリング関連の本から得た知識からですが、以下のようなやり方が有効なようです。
・将来、確実にあるいは高い確立で変更が起きるものに対してのみ柔軟にし、それ以外はシンプルに保つ。
・本当に柔軟性が必要になったときにリファクタリングする。
まとめ
こうやって振り返ってみると、範囲を決めて、シンプルにして、柔軟にするという何とも当たり前のことなんですよね。私は今までその当たり前のことすらできていなかったわけだ＾＾さて、そうやって作った新しいソフトウェア部品の成果は素晴らしく保守性が高いものができました、と言いたいところなんですが、実は作ってからまだあまり時間が経っていないので何とも言えません。少なくとも最初に予想していた「あそことあそこの部分が変わると保守が大変になる」という感じはなくなり、今のところはそれらの部分に変更が起こっても部品は変えるような事態にはなっていません。
再利用性にしろ、変更容易性にしろ、どの程度の成果があったのか、計測が難しい。。なんとか見える化できないかな。
