三流プログラマが脱三流するために書くブログ

PHP, オブジェクト指向プログラミング, デザインパターン, リファクタリング, DDD, 関数プログラミング, etc.

35. Cloud Developer - Laravel #1 (初心者向け) 勉強会で Laravel について話したスライドの補足

この記事について

昨日こちらのイベントで登壇して、Laravel について話したんですが、スライドだけだと情報量が少ないので、補足の記事を書くことにしました。

喋ってないことも書いてるので、参加された方もいちおう目を通していただけると、補完できていいのではないかと思います。

Cloud Developer - Laravel #1 (初心者向け) - connpass

スライドはこちら

記事中にもありますが、以下の Qiita の記事のダイジェスト版+α 的な感じです。

Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る - Qiita

前提知識

初心者向けってことだったんで、Laravel 自体の紹介だったり、基本的な仕組みについてもお話しましたが、それより以前の前提知識というか、現状のウェブアプリケーション開発の歴史や現在の潮流に関して、私の認識をざっと書いておきます。

1. フレームワークを自作するのは特別な理由がない限りやめた方がいい

2018年にもなって、新たにウェブアプリケーションをつくるのに、既存のフレームワークを使わないという選択肢はもはやないと思いたいですが、あってもおかしくはないな、とも思うのでいちおう書いておきます。

1990年代から2000年代初頭くらいまで、フレームワークを使う、という発想すらなかった時代、みんながそれぞれに「フレームワークっぽいもの」をつくっていました。

なので、昔はそれなりの規模のウェブアプリケーションつくるのには今以上のコストがかかっていたし、コアの部分はみんな触りたがらない、みたいなこともありました(それで開発スピードが落ちたり、コピペコードが蔓延したり、いいことはあまりなかったです)。

私は、ユーザーにすばやく価値を届けることが第一目的だと思っているので、フレームワークに相当する部分からつくりこんでいくと時間もかかりますし、不具合も多くなるので、どうせ機能が膨らむなら、最初から既存のフルスタックフレームワークでつくるのがいいと思っています。

PHP のよさのひとつとして、ファイルひとつでウェブアプリケーションがつくれる、というのはもちろんあるんですが、ちょっとしたウェブサイトならありえても、ウェブアプリケーションの世界ではその選択肢はないに等しいです。

巨人の肩に乗りましょう。

2. PHPフレームワーク乱立問題は収束に向かっている

Ruby on RailsRubyウェブアプリケーションをつくる上でデファクトスタンダードである、というのはひとつの強みだと思っていて、学習コストや知識の集約の面で効率がいいことは間違いありません。

反面、異なる設計思想でつくられた別のフレームワークがないということは、競争を通じた進化がない、ということでもあり、必ずしもいい事ずくめではないとも思います(そういう意味では、 hanami が興隆してくると、Ruby ウェブアプリケーションの世界も変わるかもしれないですね)。

そして、PHP においても、少なくともフルスタックフレームワークにおいて、これから新たにウェブアプリケーションをつくろうとするのであれば、Laravel 以外の選択肢はないと思っています。

ひとつ躊躇する点があるとしたらスピードでしょうか。ベンチマーク結果を見ると明らかに遅いので、レスポンススピードが求められるようなアプリケーションでは、選択肢から外さざるを得ないかもしれません。

そもそも PHP 以外の言語(Java, Go, Node.js)にするという選択肢もあるのでなんとも言えないですが、軽くて速く動作させる必要がある、というシチュエーションは意外と多いかもしれません(私はハイパフォーマンスが要求されるアプリケーション構築の経験はほとんどないのですが、ECサイトなどの比較的同時接続数が多いアプリケーションを PHP で書いたときは、軽量フレームワーク使ってました)。

2018年、PHP でプログラミングはじめました、という方々を Twitter や勉強会でお会いしますが、そういったひとたちの中で、最初から Laravel 使ってます、というひとが増えている印象があって、とてもいいことだと思っています。

Laravel は学習コストが高い、みたいなことも言われているみたいですが(私も学習コストはそれなりにあるとは思いますが、それはどのフレームワークでもあんまり変わらないんじゃないかと思ってます)、日本語の情報も増えてきてますし、 YYPHP とか LaraCafe とか、Slack 使ったもくもく会とか勉強会も増えてるので、オンラインで質問することもできますし、まぁなんとかなるんじゃないでしょうか(私宛に Twitter で質問していただいてもぜんぜんオッケーです)。

基礎を学ぶ前に、とりあえず Laravel を動かしてみて、体験してみてから、基礎の学習に入るくらいでいいんじゃないでしょうか。

余談ですが、いままでの話は、フルスタックフレームワークの話で、軽量・マイクロフレームワークではまだ乱立状態ですね、Phalcon はちょっと異色なのでおいといて、CodeIgniter、Slim、Aura 辺りでどれを使えばいいのか、まだ選定に迷うところなのではないかと思います(個人的には Slim 推しですが、CodeIgniter はフルスタックと言っても差し支えないくらいの機能性があるので、将来的に機能が膨らみそうならアリだと思います)。

Laravel の特長

特長に関しては特に追記することはないんですが、パフォーマンス的な懸念が強ければ、Lumen という、Laravel から重い機能を省いたマイクロフレームワークがあるので、それも検討してもいいかもしれません(個人的には、どうせ開発進めていくとフルスタックほしくなるタイミングが来る可能性が高いので最初から Laravel でいいんじゃないか、と思っているので、おすすめはしないですが)。

Lumen - PHP Micro-Framework By Laravel

Laravel のアーキテクチャ概要

懇親会のときに、Resource クラスの話をしてて、スライドには入れてなかったんですが、ちょっと補足すると、Resource は、レスポンスデータをクライアントの要望に合わせて整形するためのクラス群(単一リソース用とコレクション用があります)です。

Eloquent: API Resources - Laravel - The PHP Framework For Web Artisans

FormRequest をリクエストからコントローラーへの DTO として使う例は紹介しましたが、Resource を使うと、コントローラーからレスポンスに対する DTO が使え、データ変換の責務をカプセル化することができるようになります。

ぜひ使ってみてください。

Laravel でウェブアプリケーションをつくるときのベストプラクティスを探す

フレームワークのお作法にできるだけ合わせるっていうのは、むだな学習コストをかけないっていう目的があって、前提知識のところにも書きましたが、私のスタンスは、できるだけ速くユーザーに価値を届けることが大事、というものなので、そこを踏まえて言うと、学習コスト高くなっても別の目的を達成したい、っていうことであれば、その限りではないです。

チームや組織のポリシーしだいですね。

いちばん大事なのは、知識や経験がアップグレードされたら、ベストプラクティスもアップグレードしていかないとね、っていうことで、何年やってても「へーこんなことできんのかー」みたいな新たな発見のあるフレームワークなので(私だけかもしれないですがw)、継続して取り組んでいきたい所存です。

最近は Laravel 関連の勉強会も増えているので、色んな場所で色んなひとと、意見交換したり、議論したりしたいです。

引き続き、よろしくお願いいたします。