わからなくても読む。いずれ理解することを目指す
導入
最近、設計について解説されている本や設計パターンの本をいくつか読んでいる。
そんな中、このツイートとこの話題を取り上げているブログをいくつか読んで、自分は今読んでいる設計の話が本当に理解できているんだろうかと不安になった。
UseCase がわからない...
— Yuki Anzai (@yanzm) 2019年2月15日
FizzBuzz で
「3の倍数のときは fizz が返る」
「5の倍数のときは buzz が返る」
「3の倍数かつ5の倍数のときは fizzbuzz が返る」
「3の倍数でも5の倍数でもないときはそのままの数字が返る」
これは
私自身、本を読んだだけで理解できたとはまったくもって言えないし、理解するのにまだ時間がかかると思っているけど
そんな状態でも読むことに意味があるんだと信じたいのでブログでまとめる。
読む対象は本だけではないです。ブログとかのインプットするもの全般です。
まずは用語だけでも目に入れておく
今回のケースは、本を読むことである程度理解できる人ではなく、
なんとなく、主張はわかるけど実際にどうやれば良いのかわからないという人がテーマになる。
私もそういうタイプの人間で、すぐ理解できなかったり、その場では理解できるまで読み込むようなことをしないタイプだけど、それはそれで良いと思っていて
まずは用語を目に入れて、どこかのシーンで「見たことある」というようにしておくことを心がけている。
そうすることで、他の記事を見かけた時に少しずつ前提知識がついていって理解が進むようになると思う。
自分が携わるシステムに触れる時に読む
業務でもプライベートでも、どこかでシステムに関わる機会はあるはずで
そのシステムが自分一人だけで作っているものでない場合、最初に作った人や大きな部分を構築した人の思想というのは絶対に入っているので
それを読んで、システムの理解だけでなく背景や思想まで読み取るような習慣をつけると、思いがけず過去にみた事ある設計パターンの理解に繋がることがあると思っている。
実体験してわかることもある
プログラミングを始めた頃、「オブジェクト指向」や「MVC」について、何を言っているか全くわからなかった。
設計図を作るから何?再利用できるなら関数で良いんじゃないの?って考えてたけど、ちょっと経験を積んで、有名なフレームワークのソースコードを読んでみると
ああこれがMVCか、なるほどこうすることで綺麗なコードになるんだと理解できるようになっていた。
なので、いきなり全てを理解できることはなくて、実際に使用されているシステムのコードを読むだとかその中で開発するという経験はあると理解が進みやすいと思います。
そういう意味では、一つのサービスだけではどうしても触れる領域というのは限られてくるので、小さいアプリを作ってみるとかOSSに参画してみるとかで機会を増やす方が良いと思います。
まとめ
ある意味、一つの勉強法の話かもしれないなと思いつつ、思ったことを書いた。
今回は設計の話で思ったことだけど、これって設計に関わらず全ての事象で言えることだよなーと思ったので、タイトルに設計というワードは入れなかった。
事前にちょっとずつ入れようという話ではあるんですが、別の考え方も持っていて、これってYAGNIの原則とは離れた考え方だよなと思った。
なのでそこは、完全に理解するのは必要になるまで不要ということで結論としたい。
YAGNIの原則で機能は必要になるまで実装しないのに、知識は今必要としなくても得る必要があるって考えてしまって人間設計的には良くないんじゃないかって最近考えるようになってる。でも必要になってから勉強し始めても遅いしなー。必要になるって予測して事前に知識を得るのが一番なのかな。
— taminif (@sbntaminif) 2019年2月14日