パターン指向リファクタリング入門から学んだこと3つ
パターン指向リファクタリング入門を読んで学んだことを3つ、後から思い出せるようにブログに残しておく。 それにしてもどうしてこんなに良い本が売られていないんだろう。
- 「ちょうどいい設計」でも「ずっといい設計」ではない
- テストがあってもリファクタリングは少しずつ
- パターンに引きずられてはいけない
「ちょうどいい設計」でも「ずっといい設計」ではない
ソフトウェアは「ある要求」を満たすために作られるが、往々にして要求に対して「凝り過ぎ」や「不十分」な設計が採用されてしまう。 そうなると複雑すぎて理解に時間がかかったり、逆に機能追加する度に重複するコードが増えていく、という現象を招く。
では、要求を必要最低限満たすような「ちょうどいい設計」をすればいいのか...というとそれだけでは不十分。 なぜならソフトウェアは名前の通り「ソフト」なもの、時間が経つにつれて要求も増えれば環境も変わるから。 ある時点で「ちょうどいい設計」であったとしても「ずっといい設計」であり続けることはできない。
だから、その時点での「ちょうどいい設計」を追い求め続ける必要が出てくる。これがリファクタリングが必要な理由。
テストがあってもリファクタリングは少しずつ
テストによって動作が担保されていれば、プログラムをどんどんリファクタリングできるのか...というとそこにも落とし穴がある。
何度も経験があるけれど、大きなリファクタリングにいきなり手をつけてしまうと、再びテストが通るようになるまでに予想以上に時間がかかってしまう。 何故か？リファクタリングのような複数の部品の組み換えを頭の中でイメージするのはかなりの容量を食ってしまうので、途中で全体像が把握しきれなくなり、道に迷ってしまうからだと思う*1。
そこでテストをなるべく壊さないように、もし壊したとしても次のステップですぐに復旧できるようにリファクタリングを行なうのが重要になる*2。 この「テストを壊さないように...」には技術が必要で、ここがパターン指向リファクタリング入門の大きな部分を占めている。
では、このリファクタリングを繰り返した先にパターンが...あるのだろうか？
パターンに引きずられてはいけない
パターンは過去の叡智が詰まった非常に強力な武器だけれど、あくまで解決策を示すだけであり、その実装は様々。 なので大事なのはパターンを使うことでなく、パターンによってどんな問題が解決されるかを理解し、現在の状況に合うように適切なパターンを導入すること。 状況をパターンに合わせるべきではない。
常に Alexander の言葉を念頭に置くべし。
一つ一つのパタンは、三つの部分で構成されるルールであり、一定の状況と、そこでの問題点と、その解決策を表す
時を超えた建設の道より
実際に実践するためにはパターンに対する深い知識が不可欠だけど、残念ながらまだはそこまで至っていないなぁ。。このブログを読み返す度に成長していたいものだ。
