Laravel shibuya #2 IRTメモ

PHP

テストコードについて学んだほうが良いのか

自分が思ったやつとか思い出したやつとかは【補】

• テストコード書くと工数が減るってほんと？？
  • そもそも工数が減ると聞いたことが無い
  • 不具合減る
• コストかかるよね
  • あとから効いてくる
    • 【補】Economics of Test Automation (xUnit Test Patterns)
      • qiita
  • そもそもテストしやすいコードを書こう
    • テストの工数削減に効いてくる
    • 設計能力の向上も見込める
  • 【補】テストコードのリファクタ
• 仕様変更時などにありがたみがある
  • ケースによりありがたみが変わる
    • お硬いB2B: そもそも直させてもらえるまでが長い
      • あまりありがたみがない
    • B2C: 契約とか結んでなくてもユーザが困ってるから直す
      • 何度も回すのでありがたみがある
• ちょっとずつ積み上げ
  • いきなりドカッと書くのは無理
• どこまで書く
  • 結局プロジェクトによる
    • レイヤードアーキテクチャでレイヤー切りまくり？
    • M・V・C？
  • ユニットテストは書かず、結合テストのみという選択
    • カバレッジは見る
• テストコードはエンジニアの不安を解消する
  • 一歩一歩仕様を固めていく
• テスト書けるのはエンジニアとして結構レベル高い
• エッジケースは自動テストが有用
• テストをしない理由
  • 対象機能の重要度が低い
    • 非常に軽微で、かつ全然使われていない画面
  • 対象機能への改修がない
  • スピード重視
• 内外どちらから書く
  • unit/featureどちらも同じくらい

Laravelはできるけど、PHPのOOPがわからない

• クラスをどう切ってどう置くの
  • F/Wに乗っかる
• クラス切るときとかにテスト必要だよね
  • テスト書かないリファクタはNG
• SOLID原則勉強しよう
  • クラスが永遠に増え続けるのどうするの
    • 巨大なクラスよりはよいのでは
    • 人手が少ないとつらい
      • IDE(PHPStorm)の力があればそんなにつらくない
• やりすぎてもいけない
  • 勘と経験
    • 元も子もない...
    • 痛い目を見て覚える
• 先人の「痛い目」の追体験としてのデザインパターン
  • 勉強するうえでも、経験と照らすと腹落ちしやすい
• OOPもデザインパターンも手段にすぎない
  • 目的にならぬよう
  • その手段が解決しようとしているものは何なのか？

Laravel

• 参加してないので「まとめ」のみ聞いた

コード保守に秩序をもたらすには

• みんなが「俺の設計が最高」と言う
• 民主主義
  • メリットとデメリットで比較衡量して多数決

フルスクラッチノーF/Wべた書きPHPをLaravelに移行したい

• そもそもOOPじゃない、とか
• まず仕様をテストコードで表現することから始める
  • 外部仕様(E2Eテスト)はseleniumとかで
  • いきなりがっつり書くのは大変なので並行運用できるとよい

LaravelのAPI開発何を気をつける

• 既存の複雑なDBをEloquentにしていくのはつらい
  • DBリファクタリング
• テストデータどう作る
  • Factory
    • パターンたくさん
      • そもそも全部テストする必要あんの
      • FactoryにFactoryを重ねる？？(よくわからない)

フロント

• Vue.js
  • 別repo?