「PHPフレームワークを調査すると「Symfonyは大規模向け、Laravelは中規模向け」みたいな話を聞いたりします。 大規模向けか中規模向けかというのはどこで判断するのでしょうか? 自分たちでフレームワークを選定する時に迷ったりします。」

世間ではリモートワークがはやりですが、オフィスがないバーチャル世界にはダイレクトワークがない七太郎です。

フレームワークを使わないで開発することも減った昨今、誰しもフレームワークで悩みますよね。LaravelもSymfonyも使ったことがある七太郎ですが、質問者さんの言っている事もなんとなくわかりますし、よくある質問です。

特にフレームワークを使う目的で効率的な開発は重要ですよね、ルーティング、テンプレートエンジン、ORM、オブジェクトコンテナ・DI、自動テスト補助、バリデータ、セキュリティ系機能(ヘッダやCSRF対応など)などといった典型的なものを再度作らず(選ばずに)に済みますし、デプロイやコード生成などのツール類も整備されていたりします。

なので、機能や性能を比較する情報は多くありますし、すでに質問者の人もしらべてみているのではないでしょうか。

で、SymfonyとLaravelどっちがいいかについていえば、大体同じ機能はそろっています。そもそもどれもPHPで書かれているのだから(C拡張が必要なPhalconや、ReactPHPなどPHPらしくない例外もありますが)できることにはあまり差はありませんし、仮に足りなくても補えたりします。

なので、七太郎的には何ができるかだけでなく、「イメージ」的な側面も冷静に考えてみてはどうかと思います。

というのも、七太郎の狭い世界の感想では今Symfonyでつくるぞ!といって集まる人がそんなにみかけません…。

逆に、Laravelだと「やってみようかな!」という人が多い気がします、採用条件に華々しく書かれる事もありますしね。

みな選定のときにはそういう雰囲気を感じているのではないでしょうか?

大規模な開発ならばチームを大きくしたり、チームの入れ替えをすることも最初にかんがえなければいけません、そこで新しいチームメイトの心理的抵抗を減らすのは重要ではないでしょうか。

ということで、もし理詰めで決まらず迷うようならば、今まだ雰囲気があるLaravelをおすすめします(結論)


以下は余談です。

ただ、七太郎はその2つから選ぶならSymfonyをやりたいな(やってみたいな)と思います。
Symfonyは4になって様々なFWからのインスピレーションで色々変化しましたし、LTSによるバージョンロックの仕組み(やり方)もSymfonyのほうが納得できる所があります。

https://github.com/symfony/lts

あとは、4からSymfony Flexの仕組みを用いて、同じSymfonyを下敷きにしつつ分厚くしたり、軽くしたりしやすく(?)なったようです。

ただ…覚える事が多いんですよね…。


メリットだけでなく、デメリットを冷静に考える必要があります。

SymfonyやLaravelなどのフルスタックなフレームワークには落とし穴もあります。

・フレームワークに振り回される

フレームワークもソフトウェアですから、日々バグがなおされ機能が追加されたりします。

バージョンアップは多くの場合良い事ですが、必ず下位互換性が保たてるとは限りません。フレームワークを活用したコードはフレームワークにあわせなければなりませんので、フレームワークのバージョンアップにともなう「余分な」作業が発生します。

今でこそSymfony、LaravelなどはLTS(長期間安定性)を提供していますが、いつかはLTSのサポートもきれます。

そういう意味ではアグレッシブなLaravelより保守的(と、思われている)Symfonyのほうが大規模に強いという話も聞きます。

ただ、Symfonyでも過去デフォルトのORM(DB)周りがゴソッとかわることは過去にありました(勿論元のものをつかいつづけたり、移行する期間はありましたが)、そうなると相当テストを書いていないと乗り換えるのは大変なチャレンジになりますよね。

・フレームワークにとらわれてしまう

フレームワークは「こういう風につかおう(作ろう)」という思想を持っているもので9割の目的にマッチします。

しかし、最初は問題にならなくてもその残り1割に後から該当することだってあります。

たとえば、フレームワークがPOSTにCSRFトークンを必須にした結果JSからのAPIアクセスが面倒になったり…、

そのフレームワークの提供するベストプラクティスに固執した結果、効率的なデータアクセスができず性能が犠牲にななったり…よくあります。

勿論それは使い手の技能の問題でしかなく、適切に実装することで回避できるのでしょうが、そうはいっても自分でできるかが問題です。

工数がかかりすぎて本末転倒「なんでこんな面倒なことをしなければならないのか…」と微妙な気分になることもあります。

なので、あえてフルスタックではなく機能がシンプルなフレームワークを選定する事もよくあります。

・同僚の経験や力量に依存する

いくら開発効率がよい「最強のフレームワーク」だったとしても、チームの人間がなれていなければ見積もりの精度がでなかったり(バッドを含む)ノウハウ不足でハマってしまう可能性があります。

勿論そんなことは皆は百も承知であって、Laravelが流行り始めたころに「使いたいけど、今回は無難にcakePHPにしよう」などといった風景はよく見ました。

そのように慣れたFWを選ぶ事も七太郎としては判断の一つだと思います。

長くなりましたが、後悔しない選択をしたいですね!そしてそれでも結局後悔することになると思いますので七太郎も頑張りたいと思います!

そんなふわっとした当然のことをいわれても…とおもったアナタ!ぜひPHPerKaigi 2018にきて色々な人にきいてみてはいかがでしょうか!チケット好評発売中です!

追記 五郎のコメント

「SymfonyやLaravelなどのbatteries includedなフルスタックフレームワークを使うより、自分でコンポーネントを選定してフレームワークに依存させないのがコードの寿命を延ばすだろう」


質問はこちらから!

https://peing.net/ja/phperkaigi


3/9、3/10に開催されるPHPerKaigi 2018 チケット発売中だよ!


PHPerKaigi 2018