SPAをフルスクラッチで作ることになり、設計に対して関心が高まっていた。いきなりドメイン駆動設計は厳しいしそもそもオブジェクト指向についてよく分かっていないので、ネット上で評判がよかった本書を読んだ。
サンプルが Ruby で書かれているのも、選んだ理由。これなら読めると思った。
非常に読みやすく、よかった。
特に、「設計」に対する変な苦手意識や劣等感を払拭すると同時に、新たな視点を得ることが出来たのがよかった。
「設計」や「オブジェクト指向」というのは、今の自分には理解できないような高尚な目的のために、自分には理解できない高度な何かを行っているものだと、思っていた。
だがそうではなかった。
まず目的。
なぜオブジェクト指向で設計するのか。
それは、「変更に強いプログラムを作る」という、きわめて実利的でシンプルな目的のため。
ちなみに、最近自分が関心を持っているドメイン駆動設計についても、その目的は「変更しやすいソフトウェアを作ること」にあるらしい。
当たり前の話ではあるが、オブジェクト指向設計もドメイン駆動設計も、それ自体は目的ではなく、あくまでも手段に過ぎない。
この認識を持てたのは大きい。今後どんなに難しい話が出てきても、土台にあるのは、「変更を簡単にする」というシンプルで自分にも共感できる価値。
ともすれば高名な設計を取り入れること自体が目的になってしまうが、そうではない。
そしてやっている内容についても、自分とそこまで距離を感じなかった。
単一責任は普段から意識しているし、依存性の注入にしろダックタイピングにしろ、これまでに何度も実践してきた。ただそれらを、そういった用語で呼んでいなかっただけで。
もちろん見落とすことはよくあるし、様々な制約によって理想を実装に上手く落とし込めないこともある。
それに、例えばダックタイピングなんかは、意識してそれを使っていたというより、よりよいコードを求めて改善を重ねていたら結果的にそうなったということが多い。ダックタイピングという概念を知っていることで、最初からそれを選択肢として持つことが出来る。これは他の設計パターンやテクニックにも言える。
だが、「オブジェクト指向」や「設計」はそこまで自分から遠いものではないと感じたのも事実だ。どこまで自覚的か、どこまで徹底できているかはともかく、普段からやっていることではある。本書が入門書だからなのだろうが、「設計」に対する敷居の高さを緩和することが出来た。
これは俺にセンスがあるから、ではなく、職業プログラマになりたての時に優秀なメンターに色々と教えてもらったからだと思う。
numb86-tech.hatenablog.com
そして、これが最大の収穫だが、設計に対して新たな視点を得ることが出来た。
今まで、どこかに「正解」があると思っていた。「すごいプログラマ」は一瞬でそれを見抜き実装するのだと。
だがそうではなかった。「完璧な設計」がどこかにあるのだと思っていたが、そうではなかった。
そんなものは存在しない。
そもそも、設計が終わることはない。設計は変化していく。
そして、変化が前提になっている。まず完璧なものを作って定期的に変更する、ではなく、最初から変化を前提にしている。
だから、完璧な設計はどこにも存在し得ない。設計は常に変化の「途中」である。
そして、だからこそ、変更容易性というものが非常に重要になってくる。アプリケーションは変化していくものであり、それゆえに、変更に強いものでなければならない。
何を作るべきか、というのは思っているよりも自明ではない。それを知るための情報は不足しているし、自分自身の能力不足によって先を見通せないこともある。状況も常に動いていく。
ゴールは変化していく。だから、設計が「完璧」に到達することも決してない。
そんなことを考えていたら、まさに「あとがき」にこう書かれていた。
アプリケーションが完璧になることはありませんが、くじけてはいけません。完璧さというのは捉えがたく、おそらく到達もできないでしょう。
そして、本書の序盤に書かれてある「設計は漸進的なプロセス」「設計とは、アプリケーションの可変性を保つために技巧を凝らすことであり、完璧を目指すための行為ではない」といった言葉の意味を、理解することが出来た。
「正解」や「完璧」などないのだ、という視点を得られたのは大きい。
設計は漸進的な行為であるという視点を得られたことで、設計やプログラミングに対する考え方が大きく変わる気がしている。
