最終更新日：20191006
#この記事は
『歴の浅い人が敢えて書く フレームワーク学習の心得』というタイトルで
railsを学習中に書いていた記事をリファクタリングしたものです。
学習当時の感覚と、その後様々なツールを使ったり設計する中で得た感性をミックスして
フレームワークはどのように学んだらよいのか、またなぜハードルが高く思えてしまうのか
プログラミング自体さほど経験の多くない学習者に寄った目線でまとめています。
#書いている人の概要
- 小さいころにHTML(当時4.0)とまだ複雑でなかった時代のActionScriptは触った
- 大学でC言語とshellを少し使ったがあまりセンスがなかった
- 会社員時代はエクセルならバリバリ使えるただの「ITに強い」人で非エンジニア
- プログラミングスクールにてモダンなプログラミングを約半年学ぶ
- インフラエンジニアをしながら更に半年くらいしてフレームワークを本格的に独学
- 更に半年くらいしてプログラミングスクールの補助教員と受託開発もはじめる
要約すると…
多少リテラシーはあるものの非エンジニアだった人が
エンジニアと指導の経験を積みつつある中で得た知見で書いています。
#結論
##1：必要なものは優れたチュートリアルの実践
これは2つの意味をふくんでいます。それは以下の2点です。
- 優れたチュートリアルを探さなければならない
- チュートリアルを書いてある通り実践すべきである
##2：難しい理由は設計者のエゴと学習者の怠慢
この2つの事柄の関係性はパラドクスです。
フレームワーク設計者の多くは学習者の「楽にプロダクトを作りたい」という欲望に対し、
罰を与えようという父性と甘やかそうという母性によって設計を左右させられています。
この父性と母性が行き過ぎた部分が学習を難しくしている部分として現れます。
#結論1について
##優れたチュートリアルとは何か？
「優れた」とは、フレームワークの設計に対して本質的かつ網羅的であるということです。
公式のチュートリアルであっても初期の学習にふさわしくないこともあります。
###学習に向かないチュートリアル
すぐに色々な事ができるようになるように書かれているチュートリアルは学習に不向きです。
大抵、フレームワークは得意なデザインパターンとそうでないパターンを持っています。
得意なデザインパターンに関してはショートカット関数が充実しているのですが、
ショートカット関数ではフレームワークの本質的な造りが分からず応用が利きません。
###なぜ、そのようなチュートリアルが出回るのか
フレームワークを利用する大きな理由の1つは開発の効率化です。
そのため、まずは簡単なものが手早くできてしまう印象が市場拡大に必要だからです。
市場が育たなければコミュニティの拡大もないですから、
設計者の目線がそちらに向かうのも自然と言えば自然かもしれません。
###よいチュートリアルの探し方
周囲にそのフレームワークを使っている人がいれば聞いてみたり、いなければ
その言語のコミュニティに参加してみて情報を集めるとよいです。
##書いてある通り実践すべき理由
###考えうる反論
学習者や指導者にはモチベーションを最優先する考えもあると思います。
つまり、作りたい通りに作るほうがよいのではないかという考え方です。
技術的に安定した言語を標準メソッドや公式にサポートされたライブラリの中で使う分には
私も好きに作ってデバッグを繰り返すほうが身に付くと考えています。
###フレームワーク固有の事情
ただ、フレームワークの場合は致命的に苦手なデザインパターンがどうしても存在するのと、
命令を走らせてコードの一部を書き換える処理があるために、コードのロールバックが
難しかったり手順を間違えると動かなくなり修復が困難なこともあります。
修復困難になった状態から正常な状態の戻すのはフレームワークの内部動作を
知り尽くしていないと難しいです。これを初期の学習者が行うのは不可能です。
###機能は可能な限り網羅してこそ使える技術として身に付く
全ての技術に共通して、一部の実装方法を学んでプロダクトが作れたとしても、
機能を網羅して知っていない限り良い設計にならないことは多々あります。
適切な設計によってプロダクトの完成速度が速まればそれだけ多くの設計と実装ができ、
ますます技術が身に付くようになります。
#結論2について
##設計における父性とは？
フレームワークを利用する理由の1つは開発の効率化だと書きましたが、
もう1つは保守性の向上です。全員が統一して「良い」書き方をしましょうという意味です。
ただ、この「良い」という概念が結構厄介で、あくまで主観的だったり
現時点の開発環境において好まれた設計パターンであるというだけだったりもします。
###例：Djangoにおける静的ファイルの分離
python系フレームワークのDjangoでは、画像やフロント系スクリプトをDjangoモジュールの
ディレクトリから分離して複製した上でWebサーバーに読み込ませるパスを生成します。
これはWebサーバーの処理プロセスがDjangoのディレクトリ内部にアクセスすることを
危険と判断して設計されたそうですが、この考えに反する設計の方が普通な気がします。
###例：Reactにおけるコンポーネントの親子関係
Reactではすべての要素を木構造にあてはめて制御しようとします。
このためチュートリアルも分岐のない木構造(Game -> Board -> Square)ですが、
jQueryやVue.jsがそうであるようにDOM要素は木構造を持たずに関係しあうことも必要です。
（React自身でさえ所詮はjavascriptに過ぎないので木構造を無視した実装も可能です。）
##フレームワークを学ぶ覚悟
学習者はまず設計思想の受け入れを求められているということを理解する必要がありました。
そして同時に、設計思想を外れた場合にどうなるかも知っておく必要があります。
それはネイティブな言語仕様と向き合うことになるということです。
laravelならphp自体の、railsならruby自体の言語仕様を時間をかけて学ぶべき時が
どこか遠くないタイミングで訪れるということを考慮し、それだけの学習時間を予定しておく
ということが近道なのです。
#余談
##フレームワークごとに感じたことなど
###laravel
画像ファイルなんかを普通なら相対パスで記述すればいいものを、
asset関数で早い段階でURLにパースして解釈しているので結構間違えてエラー出します。
リレーショナルテーブルを実装しようとしたときに実装不能な設計パターンがあって
laravel式のテーブル設計に変えることになった記憶があります。
画面はphp系だけあって書きやすいほうだと思います。
###rails
helperの位置づけが最初分かりにくいですね。各viewからは名前空間関係なく呼べてしまい、
一方でmodelから呼ぶ補助関数を集めるのは想定はされていないのが謎。
インスタンス変数・インスタンスメソッドとクラス変数・クラスメソッドの使い訳が
結構早い段階で要求されるので、ruby自体に慣れるのがまず優先になります。
「こうすべき」が結構ある割にたやすくレールを脱線できてしまうので
ベストプラクティスはどうなのかと悩まされることは多いです。
###Django
1回使ってからもう忘れてしまいました…。
運用環境に乗せる時の動き方が奇妙です。
###React
node.jsがあるせいで導入のハードルが高いように見えるのと、
Atomic Designとか状態管理とか堅い設計思想との親和性の高さが喧伝されているせいか
一見難しそうに見えていたのですが触ってみると実態は非常にシンプルです。
JSXが分かりにくいですが、babelでjsに翻訳してやると何をしているのかわかるのと、
なぜJSXを使うのか（単純に使わないとネストだらけになるのでメンテナンスしにくい）
が分かり、基本はやはりJSだということが掴めれば難解ではないです。
###Vue.js
サクッと使える印象通り、得意な設計パターンでは組みやすいのですが、
中の動きが見えにくいので思わぬエラーに見舞われるような気がします。
途中で「あ、結局Vue.jsも木構造」なのねと気が付かされました。