LIGHT@NOON【Laravelアンチパターン編】振り返り

こんにちは、Fusic チーム LIGHT の近藤です！

今回は、4/20(火) に開催されたチーム LIGHT 主催イベント LIGHT@NOON Laravelアンチパターン編 の振り返り記事となっております。

当日ご参加くださった皆さま、ありがとうございました〜！

放送はアーカイブとして残してありますので、未視聴の方はぜひご覧ください！
https://youtu.be/qww8M6cktFc

目次

  1. 各章の補足とコメント返し
  2. 感想
  3. 次回予告

1. 各章の補足とコメント返し

ORM

櫻川さんが紹介していた N+1 を検知するプラグイン
https://github.com/beyondcode/laravel-query-detector

with プロパティ
https://github.com/laravel/framework/blob/5a65f25ba37d7b60e056ce9f2268d401925b6548/src/Illuminate/Database/Eloquent/Model.php#L75

with メソッドを無効にする without メソッド(恐らくこれだと思われます)
https://github.com/laravel/framework/blob/314bf875ba5d37c056ccea5148181fcb0517f596/src/Illuminate/Database/Eloquent/Model.php#L290

コメント

突き詰めていくと、フレームワークなんでも良くなる

これには完全同意です。
ただ、「好き勝手しやすさ」はやっぱりフレームワークによって違いますよね。
もともと規約で縛る思想の CakePHP より、 Laravel のほうが柔軟に、いろいろな設計思想に対応させやすい。
これは Laravel がここまで広まった理由の1つかもしれません。

Laravelで無駄に便利だなと思ったのはSoftDelete対応。

FuelPHP => Laravel の順で触った人間としては、これを知ったときはなかなか衝撃的でした。
私個人は論理削除反対派なので、SoftDelete のお世話にはならないのですが……。

こういった 一定数需要があるものは手軽に実装できる のが Laravel というフレームワークの強みですよね。
ただし、プロジェクトの規模やメンバーの習熟度によっては、その手軽さは諸刃の刃になり得ます。
LIVE 中話題になった N+1 問題も、「手軽さ」によって生まれる悲劇の1つではないでしょうか。

Facade

Facade を使わない開発についてコメント欄で紹介されていたスライド
https://www.slideshare.net/KenjiroKubota/laravelfacade

コメント

いまだにFacadeにするのか、ただのStaticなクラスを作るのかの違いがしっくりしてない

これについては、そもそも static メソッドの呼び出しが必要なシーンがどれだけあるか、という点が疑問です。
「コード中で明示的にインスタンス化せずとも呼べて便利だよね」以上の意味があるならば、
static クラスである必然性があり、迷うことはないと思います。例えば、クラス変数を利用したい場合など。

必然性による判断ができない場合は、テスト容易性の観点から考えると良いかもしれません。

LIVE 中でも語りましたが、 Facade は shouldReceive メソッドを持っているため、モック化が非常に簡単です。
Mockery の提供する基本的な機能のほとんどを利用できます。

一方、 static メソッドの場合は違います。
static メソッドのモックについて、Mockery はエイリアスの機能を提供しています。
しかし、

Even though aliasing classes is supported, we do not recommend it.

とあるように、 Mockery は お勧めしていません。
そもそも static クラスをモックしたいと思った時点で、クラス設計に誤りのある可能性が高いです。
その場合には、 Facade で代替可能である、と考えたほうが良いでしょう。

Laravel についてもう少し踏み込んだ理解のある方は「本当に Facade である必要があるか」も一考すべきでしょう。
Laravel の特徴の 1 つに、 DI(依存性注入) が容易であることがあります。
DI を利用することで、モック化したインスタンスを利用したテストが可能です。

Task Scheduling

Task Scheduleing の GUI ツールとして紹介のあった Laravel-totem
https://github.com/codestudiohq/laravel-totem

コメント

N分毎に実行したい、はアプリケーションなので、関心の分離的にもコードに落としたいですね

確かに定期実行処理は、いわゆるビジネスロジックな場合が多いですね。
Task Scheduling は単一障害点になる、という意見もありますが、
アプリケーションコード全体の設計を見たときには、利用するほうが良いように思います。

2. 感想

初めてのオンラインイベント、非常に緊張していましたが終始楽しくお話することができました。
あれから 3 週間も経っていることが信じられません（記事を書くのが遅くてすみません）。

司会と配信準備のすべてを担った吉野先生、
LIGHT@NOON のアイキャッチやロゴを考えてくれた礒谷さん、
当日社内 Slack でがやがや励ましてくれた坂井さん・岸田さん、
出演頂いた櫻川大先生、
そしてご視聴くださった皆様、ここまで読んでくださった皆様、ありがとうございました！

この振り返り記事が、誰かの学びのヒントになれば幸いです。

3. 次回予告

さて、次回の LIGHT@NOON は 2021/05/25 12:00〜

「初めての社内デザイナー編」！

我がチーム LIGHT の誇る、Fusic 唯一の Web デザイナー・礒谷悠莉さんが登壇します！

エンジニア組織に 1 人飛び込んできた磯谷さんが、
入社から 4 ヵ月経った今、これまでの振り返りやこれからについて語ります。

connpass ページはこちらから！

皆様のご参加をお待ちしております〜
https://fusic.connpass.com/event/211143/