勉強日記

毎日投稿

Laravel shibuya #2 IRTメモ

PHP

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

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

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

Laravelはできるけど、PHPOOPがわからない

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

Laravel

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

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

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

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

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

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

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

フロント

  • Vue.js
    • 別repo?