概論
Laravel5は開発環境を整えるのがすごく楽だし、開発もすごく楽にしてくれるのですごくよい。
しかし不満もあって、将来のLaravelの姿に懸念を抱くものがある。
このメモによってLaravelの見据えている将来かコミュニティの意思を知ることができればよいなと思うので、意見やアドバイスが欲しい。
きっかけ
Laravel5になって変わったところはいくつもあるが、一番論争が起きているのはModelディレクトリの削除である。
自分はこのModelディレクトリの削除に懸念を抱き、調べてみても納得できる情報はなかった。
なので、自分の考えを正すべきなのかどうかが気になった。
前提
懸念点を挙げる前に、軸となる自分のフレームワークに対する考えを整理しておきたい。
そもそもそこが間違いだというのならご指摘いただきたい。
フレームワークとは
- アプリケーションの雛型
フレームワークの利点
- 開発速度をあげる
- セキュリティの担保
- 品質の担保
上記の利点を担保するものは、それぞれのフレームワークの工夫によると思うが、下記が主流だと考える
-
CoC （設定より規約）
- こういう枠組みで組むと良いという思想やレールに沿って開発することで余計なことを考えずに済む
-
自動化を意識した構造の提供
- テスティングのしやすさ
- デプロイのしやすさ（dotEnvファイルなど）
-
各種汎用ユーティリティの提供
- バリデーション
- コマンド
- ORM
- など
Laravelの懸念点
ここから本題に入る。
私が懸念に思っているのはModelフォルダの削除の件だ。その修正自体よりも、背景にある思想が未来を危ういモノにしているのではないかと感じる。技術的な面と思想的な面から、私の考えを挙げる。
技術的な面
- MVCのMへの誤解を解くためとのことだが、フォルダの削除ではそれを解決していない
そもそもモデルフォルダが悪いのではなく、誤った開発者が悪いのでは？
- デフォルトがapp直下にモデルを作成していくスタイルは煩雑な構造を生み、デフォルトは非推奨に等しい
- CoCに従えないためメンテナンス性が犠牲になる
思想的な面
- フレームワークとしての責務を放棄している
- CoCの観点では余計なことを考えずに済むことがフレームワークのメリットであるが、自由に構造を構築することを推奨しており、設計を開発者にまかせている
- 実装方法を限定し、誤解されたまま広まってしまうことが怖いと Dayle Rees は言及しているが、実装を限定しないことによって誤った実装方法を選択するリスクも存在する
その他
自分が考える懸念点は以上だが、上記によるデメリットをもう少し深く補足しておく。
フレームワークとしての責務（CoCに則らず、開発者に実装を任せる）の放棄がそんなにまずいか？
フレームワークとしてのメリットが享受できないだけでなく、本フレームワークの将来が不安である。
想定される懸念としては以下。
- 独創的な実装方法により、バージョンアップができない（コストがかかる）可能性がある
- 同じくフレームワーク側のマイルストーンの策定が難しくなる可能性がある。
- 共通の仕組みを利用しないことになり、コミュニティでも問題解決がしづらくなる可能性がある
- 実装方法を限定しない、ということは実装方法を改善すべきかどうかの議論もできない
- つまり、開発的な理由ではなく政治的な理由で改善がなされないことも予想される（日本的な考えかもしれないが）
この考えはただの杞憂かもしれない。本当に職人だけが愛して利用するフレームワークなら誤った選択はしないだろう。しかし、多くの人に利用してもらうということを掲げている以上、そうはならないはずだ。むしろ初心者にはLaravel wayを示してあげる必要がある。
まとめ
モデルフォルダの削除自体が問題ではなく、フレームワーク開発者（コミュニティ？）の姿勢に不安を感じる。
フレームワークがフレームワークの責務を放棄しているため、ゆるやかに腐っていくことを懸念している。
フレームワーク側としては、実装方法を提示して誤解や誤った方法での実装をさせたくないという考えだが、実際のモデルフォルダの削除自体はなんら解決していないし、自分でフォルダを作るという方法を提示したことでさらなる誤った実装が広がる可能性がある。さらにそれは今後のフレームワークのバージョンアップの足かせになるであろうと予想される。
おおまかな枠組みを考えて提供するのはフレームワーク側であり、利用者もそのメリットを享受するために選択する。フレームワークに存在しない機構は利用者が考えるべきだが、MVCの枠内ならデフォルトはフレームワークが用意してあげるべきでは？
以上