laravel.shibuya #4 IRTまとめ

---

IRT1 -- Laravel Track

フレームワーク規定のもの以外のモジュール構成（名前空間、クラス名）をどうするか

• 意図
  • Laravelのモジュール構成？
    • Taylorさん: 「どこに何置いてもいいよ」
      • app下にフラットに置く
      • 機能ごとに切る
        • Entitiesとか
      • コンテキストで切る
        • OrderとかDeliveryとか
  • サフィックス/プレフィックスどうする
    • つける
      • OrderEvent
      • DeliveryListener
    • 名前空間で切ってるからつけない
      • Events\Order
      • Listeners\Delivery
• app下にフラットに置いてる人いる？？
  • あまりいない
• 「appの兄弟に置く派」が結構多い
  • Laravel非依存のものを置く
    • POPOとか
    • Eloquentとかに依存するやつはapp
  • composerで入れる
  • appの兄弟にlibとかpackagesとか置く
    • 別のrepositoryにするほどではないもの
• Laravelの機能を使うものもapp外に置く派
  • パッケージルートにServiceProviderを置く
  • 試行錯誤中
  • 切り方はコンテキスト別にしている
  • メリデメ
    • メリット
      • Clean Architectureを実践しやすい気がする
      • 逆に、コンテキスト別で切らないと変更があちこちに跳ねる
    • デメリット
      • 手間増える
      • 共通処理をどこに置くか悩ましい
        • Logとか
• サフィックス/プレフィックスどうする
  • ケースバイケース
    • 「Laravel由来系はつける」派
      • XxxEventとかXxxControllerとか
      • みんながわかる
      • 付けないと、検索したときに同名のものがいっぱい出てきて不便
    • ものによっては付けない派
      • Modelとかにはつけない派
      • UseCaseにもつけない
    • Eventは？
      • 公式はModelCreatedとか過去分詞
      • 【補】JavaScriptなんかもこれ
      • 付けなくても名前衝突しなそう
        • Notificationとかが名前衝突しちゃう
        • でもListenerとしか紐付かないから問題ない説

レスポンス速度改善

• そもそもパフォチューをどれくらい気にしてる？
  • DB抜きで、純粋なPHP部分
  • あまりいない
• パフォチューのモチベーション
  • FargateのCPUが高いので、できる限り何もさせたくない
• やってること例1
  • 画像系はCDNに逃がす
  • DBはよほどひどい設計でない限り遅くはならない
  • 1 + N問題等はきっちり潰す
    • debug bar等使って
  • やたら重いMiddlewareを使わない
    • 【所感】例えばどんなのか聞きそびれた…気になる
  • 定量目標として、ブラウザでラウンドトリップタイム100msくらいを目指す
  • RDBのキャッシュは使っていない
    • 実装例
      • KVS
      • キャッシュをファイルで持つ
    • なるべく避けたい最後の手段
      • 面倒を見るのが大変
• やってること例2
  • 無駄なミドルウェア切る
    • 速度は結構変わるそう
  • プロファイリング
    • 使用メモリなど
  • DBキャッシュは結構使う
  • 最終手段: Apacheをビルドし直してStatic Link
• キューイングによる処理の分離
  • 完了を待つ必要性の薄いもの
    • メール
    • ログ

IRT2 -- PHP Track

手が遅い。何をして手が早くなったり業務に対して自信を付けられたりしたか

• 背景
  • 機能の実装は問題ない
  • 迷うポイントがいろいろ
    • あまり良いコードとは思えない
      • 書き方
      • 責務の分割できてない
      • 手続き型になっちゃってる
  • イケてるコードを早く書きたい
• ドメイン知識が重要説
  • プロジェクトにJOINしたばかりでは、速度は出ないしミスも多いもの
  • 「書く前に何を書きたいかが脳内で決まってて、あとは書き出すだけ」が理想
  • 「ここにこれを生やすのはナイ」という勘所がわかるようになる
• まずは計測
  • そもそも何に困ってるのか・何がボトルネックなのか
    • 例: 仕様の理解が甘い
    • 例: IDEの機能を使えてない
• 何か真似してみる
• そもそもイケてるコードって何
  • 局所的なコードと設計全体とでまた違うよね
  • 即効性のあるもの: 共通語彙を使うと「伝わる」コードになる
    • start/stop, begin/endとか
    • Readable Code的な思想
    • DDDのユビキタス言語もこれ
• 「悩んで何も書いていない時間」が遅くなる一番の原因
  • ルールを決めて悩む時間を減らす
    • 自分のルール
    • フォーマッティング等はツールに任せる
      • 【所感】CIで取り締まれますね
  • ある種の宗教論争もある
    • 三項演算子 or if文とか
      • 【所感】そもそも前者は「式」、後者は「文」だから同列のものではない
• デザパタ学ぶべき？
  • GoFはJavaの機能不足を補うための苦肉の策が多い
  • SOLID原則とかのほうが大事
  • 既存のコードに手を入れなくていい = 早くなる
• オブジェクト指向は手段にすぎない
  • 手続き型でもテストとか全然できる
  • 手段が目的にならぬよう

IRT3 -- PHP Track

APIのメジャーバージョン切る？

• 切らない
  • URLの変更を伝えなくてすむ

開発環境(IDE,エディタ)

• 宗教戦争
  • VSCode
    • 本業がフロントエンドだから
    • Sublime -> vim -> VSCodeへ至る
    • Intelephense-backed
  • Atom
    • 困ってない
    • PHPStormに浮気しそう
      • 30日無料
      • プロパティのプロパティとかメソッドとかの補完が強い
      • 有料ゆえアップデートが速い
      • 定義ジャンプ最強
        • あらゆるFW対応。引くぐらいすごい
        • インタフェースと実装両方拾ってくれたりする
          • これは他のLSPでもいけたりする
  • Emacs
    • ELisp書いてカスタマイズできるのが強い
    • LSPも対応
  • Vim
    • IDE化に情熱を捧げてきたが、ある時から最小構成にした話
      • プラグインに頼らないように
      • .vimrcが30行くらい
      • バニラに慣れておくと、リモートに大抵入ってるので運用時に助かる
    • 起動が速い
      • .vimrcが短いと特に
      • 気が散る前に仕事にとりかかれる
• 自分を信用しない。機械的に怒ってもらう
  • 静的解析
    • PHPStanとか
• lightning test
  • 書き換えたら即テスト

ORMとの付き合い方

• 裏で何が起きているか意識するのがつらい
• 道具は使いどころ
  • 自分は守ればいいとして、他人をどう縛る
    • 文化や仕組み
      • レビュー
      • CI

後

• 局所最適よりも一貫性