なぜベストプラクティスが必要なのか？
Laravelの自由度が高すぎるから
Laravelは便利ですが、記述やディレクトリなどの自由度が高すぎてしまうという悩みどころがあります。
プロジェクトが進むにつれて、多くの人が自由にコードを書いてしまってすごく複雑になってしまう前に、コード記述の指針を示しておく必要があります。
初学者のために
巷にあふれているチュートリアルや本の通りに学習してしまうと、それに沿い過ぎた変な癖がついてしまう場合があります。
そこで、改めてベストプラクティスに目を通すことで、よりよいLaravelのコードを知ることができます。
Laravelのベストプラクティスとは？
公式(英語版)は、ベストプラクティスというよりも、Laravelによって提供される機能のHow Toって感じですよね。
そこで、alexeymezenin氏や有志によって作成されているlaravel-best-practicesを、ここではLaravelのベストプラクティスとして紹介します。
↓英語版より若干差分がありますが、日本語版もあります
BadなケースとGoodなケースがそれぞれ書いてあり、わかりやすいですね。
個人的に、大事だなーと思っている項目
（全部大事だと思いますが
その1
ファットモデル、スキニーコントローラ
DBに関連するすべてのロジックはEloquentモデルに入れるか、もしクエリビルダもしくは生のSQLクエリを使用する場合はレポジトリークラスに入れます。
バリデーション
バリデーションはコントローラからリクエストクラスに移動させます。
ビジネスロジックはサービスクラスの中に書く
コントローラはただ1つの責任だけを持たないといけません、そのためビジネスロジックはコントローラからサービスクラスに移動させます。
上記に則り、DB処理はRepositoryクラスに、ビジネスロジックはServiceクラスをそれぞれ作成して記述すれば、Controllerは単純なif文等の処理 + レスポンスの処理になるのが理想的だと思います。
その2
JSとCSSをBladeテンプレートの中に入れない、PHPクラスの中にHTMLを入れない
（中略）
もっとも良い方法は、データを転送するためJSパッケージに特別なPHPを使用することです。
これをやることで、JS/CSSファイルのHighLightがVScodeなどのIDE上で適応されるので、見やすいコードになります。
JSに値を渡す際は、PHP-Vars-To-Js-Transformerを別途使用すると、更にスッキリ＆楽です。
その3
コード内の文字列の代わりにconfigファイルとlanguageのファイル、定数を使う
(中略)
Good:public function isNormal() { return $article->type === Article::TYPE_NORMAL; } return back()->with('message', __('app.article_added'));
特に文言系の多言語化はやっておいて損はないです。
将来的に文言変更などを行う際、とても楽になります。
個人的に、特にクラスに持たせる必要のない定数チックなものが出てきた場合、安直にconfig/{project名}/xxxx.phpを切って色々置いていきたいんですが、割とチーム内で議論を呼んだのでここでは言及しません。w
バリデーション系のメッセージの日本語化の用意は、下記のコマンドでやると楽です。
プロジェクト開始時等にやっておきましょう。
https://readouble.com/laravel/9.x/ja/validation-php.html
php -r "copy('https://readouble.com/laravel/8.x/ja/install-ja-lang-files.php', 'install-ja-lang.php');"
php -f install-ja-lang.php
php -r "unlink('install-ja-lang.php');"
最後に
このように、Laravelのベストプラクティスを読んで実行してみるのはいかがでしょうか。
個人的には、「best-practicesにこう書いてあったから、こんな感じで書いてみたよ」「書いてあるから、こういう感じにしてみて」と言えるのが特に楽です。w
前職時代からお世話になってます。
また、100%準拠する必要はなく、チーム内で柔軟に適用していく感じがいいかと思います。
（特に命名規則など
他に、こういうのもあるよーというのがあれば、コメントにて教えていただければと思います！
ありがとうございました。