勉強日記

チラ裏

Laravel.shibuya #1参加した

勉強メモ Laravel

中央右の中野美玖ちゃんは私です

イベントの情報

laravel-shibuya.connpass.com

IRT: Interactive Round Table

  • Laravelの島とPHPの島に分かれて話し合った
  • 前後半2回
  • ぼくは2回ともLaravelの島
    • 1回目は↓の本の共著者のおじさん(ytakeさん)の隣に座った
      本にサインもらえばよかった

www.socym.co.jp

  • 以下議事録

設計のベストプラクティス

  • fat controllerだった
    • controllerでDBとか叩いちゃってた
  • service切って全部移しました
  • fat serviceになったんだけど...これってどうなの?
  • ベストプラクティス教えて
  • ytakeさんより
    • ベストプラクティスは、ない。規模やチームによるから
      • 【ぼく所感】ドメインロジックが簡潔だったらDomain Modelを作るまでもなくTransaction Scriptで済んだりしますね
    • SOLID原則のSが一番大事
    • serviceって何のservice?
      • DDD?
        • 無理してDDDしなくていいよ
      • ほかの？
      • むしろOOPの習得が大事
    • 責務分けろ
      • 1メソッド1クラスとかでもいい
        • __invoke()マジックメソッド
      • 【ぼく所感】ADRパターンってやつですね
    • クラスの名前大事
      • utilとかserviceとかはやばい
        • ごった煮になる
    • 「設計」と「要件の分析力」は同じところがある

コードリーディング

  • ソースコード読むのきつい
    • とくに認証
  • 【ぼく、他多数】idehelper使え
  • phpstorm使え
  • ブレーク張るとか
    • psysh
    • tinker
  • 【ぼく】デザパタ勉強しろ
    • 認証まわりはGoFのFacadeパターンで、AuthManagerがFacadeオブジェクトで、guardに委譲してるんだな〜...とかわかると良い
  • そもそもコードを追うのをあきらめるという選択
    • ツールに過ぎない
    • 使い方をとりあえず学ぶ
  • ところで、laravelはISPがちゃんとしてますよね
    • 【ぼく補足】Illuminate\Contracts

【ぼく質問】Facade警察について

  • 結論:facadeはわるくない
  • fat facadeが駄目
    • 1メソッドにつき1つとかにする
    • 使い方を間違えないこと
  • どこからでも呼べるのは有能
    • bladeからでも

LT

  • SOLIDのLとかIとかDにまつわる話
  • Laravelのコードを読む話
  • バリデーション駆動開発の話

みっつめが強かった

SOLIDのLとかIとかDにまつわる話

  • DIは良い設計の必要条件

Laravelのコードを読む話

  • 黒魔術(とは言ってなかったけど)
    • 【ぼく所感】文字通りmagic methodですからね
  • メソッド名、コメント、タイプヒント、アノテーション等を見ていい感じに手を抜こう
    • コードを理解したいのか
    • なんで動かないのか知りたいだけなのか

バリデーション駆動開発の話

  • 不具合が起きたことではなく、不具合が起きる可能性があったことが問題
  • 仕組みで改善せよ
    • サーバサイドだとやりやすい
  • Bfter-Middleware層でEloquent Model -> JSONの変換をしてviewに流し込む
    • sname_case ⇔ camelCase 変換とかする
    • 【ぼく所感】PoEAAのFrontControllerに似た考え方
      • アレはすべてのリクエストを処理するヤツ
        • laravelのBefore Middlewareに対応すると考えていいでしょう
  • JSON Schema使え
    • composerでJSON Schemaのバリデータをrequireしていい感じに使う
    • テストコードを書かずにTDDっぽいことをできる
      • JSONが仕様書になる