ライブラリやフレームワークのトレンドが変わったという記事に対する「また0から勉強し直しか」という反応を見るたびに「え、結局やってることは一緒なんだからちょっと考え方と使い方を新しく理解すればあとは一緒でしょ？」と思ってしまうことが少なからずあります。
この記事では、新しいフレームワーク（以下、ライブラリも同様）を使ってやろうと思ったときに、今までの知識を無駄にしないための考え方について書いてみたいと思います。
「0から勉強し直し」のイメージ
たとえばRuby on Railsで今までWebアプリケーションを開発していた人が、来月からCakePHPの現場に移る場合について考えてみます。
そのとき「0から勉強し直しだ！」と思ってしまう方のイメージはこんな感じなのではないでしょうか。
DB接続やソーシャルログイン、ERBやJavaScriptなどすべてがRailsの上に成り立つイメージを持ってしまっているため、CakePHPに移ったらそれらを含めてすべて0から勉強し直しと考えてしまいます。
極端な場合、「いままで培ってきたものが全て無駄になった！」と思ってしまうかもしれません。
要素技術を分解して考える
そのような「0から勉強し直し」気分にならないためには、要素技術を分解して理解するのが効果的です。
たとえば、同じくRuby on RailsからCakePHPに移ることを考えた場合、ちゃんと要素技術を分解すると下のようなイメージになります。
RailsはあくまでDB接続やソーシャルログイン、ERBやJavaScriptなどをまとめて使いやすくしているだけであり、これがCakePHPに変わっても周辺の要素技術は何も変わらないことがイメージできます。
これは、Gemなどのライブラリについても同じことが言えます。
たとえばSorceryもdeviseも、結局はユーザー情報を適切にDBに保存したり、Twitterに適切にOAuth認証したり、といった部分は共通です。（もちろん実装方法は違います）
つまり「deviseをやめてSorceryを使う！」となっても、ライブラリの使い方や守備範囲が変わる程度です。一番大事な「ユーザー認証」という目的やそれを実現するための基本的な仕組みや理屈は大きく変わりません。
ライブラリが変わっても目的が同じである限り、「0から勉強」ではなく今までの知識の8割くらいは使いまわしたり応用したりして活用できるのです。
どう勉強するか
新しいライブラリをみるたび「また0から勉強し直しだ！」と考えてしまう場合は、自分が使っているフレームワークなりライブラリなり、なんでも良いのですが、それを「分解」して「中の処理内容を理解する」だけでだいぶ使いまわせる知識として整理できます。
例えばHTTPは分解すると、OSで実装されているTCPによるソケット通信をベースに、それをWebシステムでうまく利用するための仕様1によって成り立っていることが分かります。
TCPによる通信はとても自由です。一度サーバーとクライアントで接続が確立されれば、あとはデータを送るタイミングもデータの内容もお互いに自由です。多くのアプリ開発でサーバーが能動的にクライアントにデータを送信できないのは、「通信ってそういうもの」だからではなくて「HTTPの仕様に従って、クライアントライブラリもWebサーバーもそう実装されているから」というだけなのです。
ここまで知ると、今度はWebSocketのような、クライアント・サーバー双方向のデータ通信がなんら特別でないことが分かります。先ほど書いた通り、双方向にデータを送信できるのはTCPでは当たり前のことだからです。
余談ですが、TCPさえ使えればHTTPクライアント・サーバーとも実装できるため、たとえばAndroid端末をHTTPサーバーにする、といった発想にも結び付けられます。
宣伝でした。
さて、長々とHTTPについて書いてしまいましたが、これはひとつの例で、DB接続、OAuth認証、キーワード検索、セキュリティ、などなど、どの要素技術についても同じことが言えます。
ひとつひとつの要素技術を言語やフレームワーク、ライブラリを通して理解するのではなく、それ単体で理解することが大切です。
たとえば自分のRailsアプリケーションでWebSocketを使った機能を実装したいときに「Rails WebSocket」で検索するのではなく、「WebSocket」単体で検索します。それを理解した上で、Railsが（もしくはGemが）WebSocketをどう実装して我々はそれをどう使えば良いのかを理解します。
そうすれば、自分が使うフレームワークがCakePHPに変わってもDjangoに変わっても、「WebSocket」という技術は変わらず、特定の言語やフレームワークによって実現できる/できないが変わるものでもないことを理解できているため、あとはそのフレームワークに沿ったWebSocketを利用するためのAPIを探せば良いだけ、ということになります。
まとめ
なんとなくフレームワークやライブラリを使って開発していると、RubyのGemのようにその機能を実現するための手段が当たり前のようにたくさん用意されているため、それらを使わないと実現できなかったり、それを変えると0から勉強しなければならない気がしてしまいがちです。
実際はそのライブラリの先にある要素技術を単独で理解してしまえば、たとえ別のライブラリを使わなければならなくなったとしても8割くらいは同じ話だったりします。「0から勉強」ではなく「80から勉強」と考えれば、乗り換えるための精神的な壁は大きく下がるのではないでしょうか。
フレームワーク・ライブラリと個別の要素技術の関係を整理して理解できれいれば、新しいものへの学習コストも下がり、問題解決もしやすくなり、結果として開発全体が楽になります。ググるときは「急がばまわれ」の精神で、自分の使っている言語やフレームワークを検索ワードから外してみるのがおススメです。
なお、「要素技術を分解する」については、似たような記事を以前書きましたので、興味があれば併せて読んでみてください。
プルリクはGitの機能じゃない ～技術を分解して理解することの大切さについて～