Rails 歴5年の僕が Laravel で開発するようになって思ったこと。
こんにちは。エンジニアの廣瀬です。今年は桜の開花が早かったですね。国立駅前の大学通りの桜もとてもきれいに咲いていたのですが、もうすっかり散ってしまいました 😢
さて、過去の記事でも触れているとおり、クラシコムではアプリケーションのフレームワークとして Laravel を採用しています。また、過去に Ruby on Rails で構築したアプリケーションも Laravel へのリライト（移行）を進めています。
僕自身も入社以来 Laravel での開発に携わっているのですが、転職するまでは Rails での開発がメインだったので（だいたい5年くらい）、Rails (Ruby) と Laravel (PHP) との違いを目の当たりにしては色々と思うところ多い今日この頃です。
そこで今回は、ずっと Rails で開発をしていた僕が Laravel について思うことをまとめてみようと思います。似たような記事は数多くあると思いますが、フレームワーク選定の一助になれば幸いです。
はじめに書いておくと、好みで言うのであれば、僕は Rails (Ruby) の方が好きです。
※ 「この部分は他のフレームワーク・言語の方が優れている」という点もあると思いますが、あくまで Rails と Laravel の比較だと思って読んでください。
どちらにも自由さがあるけれど、自由さの性質が違う。
最近、とくに思うのはコレです。
Rails: オブジェクトや DSL の拡張が容易で「書きたいように」書けるけれど、ディレクトリ構成などのアプリケーションの根幹はあくまで "レール" に乗っていることが求められる。
Laravel: どうしても言語的にはヤキモキすることも多いけれど、新たな役割を持ったクラスやアプリケーションに合った独自のアーキテクチャを導入することに対してはとてもオープン。
Rails は、Ruby のオブジェクト指向言語らしい構文や演算子のオーバーロードなどのおかげで、コードレベルでの「こう書けたら気持ちが良いなー」は実現しやすいと思います。これは Ruby が「ストレスなくプログラミングを楽しむこと」を重視している言語だからこそであり、Rails もそこを最大限に活用しているフレームワークだと思います（黒魔術も含めて）。
対して Laravel は、正直なところ Ruby ほど気持ち良く書けないなーと感じる場面も多々……（あの PHP のネイティブ関数の独特な仕様とか）。それでも、PHP 7.x でだいぶ整った「型」には Ruby にはない安心感があります。Laravel がアーキテクチャの拡張に対して開かれているのも、DI (Dependency Injection) を実現するための型（インターフェース）があってこそでしょう。
やりたいことをどう書くべきか。
これらの違いは、以下のように言い換えられると思います。
Rails: ある程度の規模まではレールに乗ってサクサク作れるが、アプリケーションが成熟してきて「規約」にはないことをやりたくなってくると、途端に求められる技術力や難易度が跳ね上がる。
Laravel: アプリケーションの雛形はあるものの、どのクラスに何を担わせるかなど、設計については Rails 以上に早い段階で意識する必要がある。その設計さえイケていれば、だいたいのことはしっかり書ける。
Rails の場合、Rails やそのエコシステムが想定している範囲内であれば、やりたいことに対して「どう書くべきか」はほとんど悩む必要はないと思います。基本的なアーキテクチャが定まっているので、外部ライブラリや「こう書くべき」というプラクティスも豊富です。また、他の Rails のプロジェクトとの行き来もしやすいです。
しかしながら、Rails が用意している構成から少しでも外れると途端にしんどくなりがちです（Service クラスが云々という議論を何度見たことか）。そもそもそうなった時点でアプリケーションを分割するべきだとかいう議論もありますが、それはそれでどう分割するべきかが難題で、難しいことに変わりはありません。
Laravel は、作者である Taylor Otwell が "Don’t be afraid to create more directories to organize your application." と言っているように、最初から好きなように作れるものの、それは「お手本」に頼れないということでもあります。ネットで「どう書くべきか」を調べてみても、「俺だったらこう書く」的な記事が多い印象です。
なので、Rails と比べると、Laravel は最初の設計が肝心だなーと思います（あくまで相対的な話です。設計が肝心なのはどのフレームワークでも同じです）。Rails が「どこで何をやるべきかが分からなくなる」のに対して、Laravel はどんなものであれ作ることはできるので、容易に「どこで何をやっているかが分からなくなる」リスクがあるのではないかと思います。
まとめ。
Rails: アイデアを形にするスピードはやっぱり早い。Rails らしく書いている間はとても楽しい。けれどそのツケ（？）がいつかはやってくる。
Laravel: 最初からちゃんと考えて作らなければ痛い目を見そう。でもそれさえ乗り越えれば、とくに多人数での開発における安心感は大きい。
PHP が 7.x になって、Laravel の良さがより活かされるようになってきたのではないかなと思います。また、現在取り組んでいるショッピングカートの Laravel への移行ではドメイン駆動設計（DDD）を取り入れようとしているのですが、アプリケーションに最適だと思えるアーキテクチャを選べるのも Laravel の良いところです。（Laravel での DDD についてはまた別の機会に書こうと思います）。
フレームワークや言語の選定は、アプリケーションの性質や規模、また開発チームの規模や技術力なども含めて考える必要があるので、ケースバイケースとしか言いようがなく、「良いか悪いか」ではなく「合っているか合っていないか」という話だと思います。そういう意味で言うと、これからサービスの機能を改善していきたい、チームの人数も増やしていきたいという状況の中で、Laravel を選定したことは悪くない判断なのではないかなと思っています。
何より、僕は好みで言えば Rails (Ruby) の方が好きですが、Laravel (PHP) での開発も楽しいなと思う今日このごろです。
こんな僕のように、クラシコムでは他のフレームワーク・他の言語でやってきたエンジニアももちろんウェルカムです。場合によっては Laravel / PHP 以外の選択をすることもあるかもしれません。実際に社内ツールでは Go や Ruby で書かれたものもあります（Ruby は僕が勝手に作ったやつです）。少しでも興味を持たれたら、ぜひ一度オフィスに遊びに来てみてください。