Laravel を採用したことの代償として、実務で実際に効いてくるのはどれですか。
Laravel の書き方から外れると途端に書きづらいこと、毎リクエストのブートと Eloquent のコスト、そしてバージョン追従の負担です。利点の裏返しとして必ず付いてきます。
面接官が見ているのはトレードオフを認識しているか。ここで止まる人が多い。
これは「Web アプリの新規案件で Laravel を選ぶ判断として、最も本質的な理由はどれですか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- フレームワークの流儀から外れた実装をしようとすると、途端に書きづらくなる
いちばん本質的な代償です。レールの上は速いが、外れると素の PHP より苦しくなります。 - 毎リクエストのブートと Eloquent のモデル生成にコストがかかる
事実ですが、多くの案件では致命的になりません。「遅い」より「流儀に縛られる」の方が実務では効いてきます。 - 年1回のメジャーバージョンアップに追従し続けるコストがかかる
これも実在する代償です。追従を止めると、依存パッケージごと動けなくなります。 - 特に代償はない。デメリットの少ないフレームワークである
トレードオフを認識していないと見なされます。「選んだ」以上、何を引き換えにしたかを言えることが期待されています。
面接官は何を見ているか
- フレームワークの流儀に縛られる点を挙げた
- パフォーマンス面の代償（ブート時間 / Eloquent のオーバーヘッド）に触れた
- バージョンアップ追従のコストに触れた
模範解答
3つあります。まず「Laravel の書き方」から外れると途端に書きづらくなること。次にパフォーマンス——毎リクエストのブートと Eloquent のモデル生成コストがあり、素の PHP や軽量フレームワークに比べれば遅い。そしてバージョンアップの追従。年1回のメジャーに追いつけないと、使っているパッケージごと詰みます。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
メジャーバージョンアップに追従できなくなった Laravel プロジェクトで、最初に現れる実害はどれですか。