弊社では週に一度、1時間の技術共有会を行なっています。内容としては、最近のTechなニュースや、気になること、仕事の役に立ちそうな情報をざっくばらんに共有しています。

DBの種類・設計・パフォーマンスちゃんとわかりますか？？

• リレーショナルDBが弊社では一般的に使われているDBですが、最近では列志向型だったり、key-value型だったりDBの種類もかなり増えているので使い分けていきたい

• パフォーマンスチューニングに関しては特に「APIが重い！」などよく言われる話で、パーティショニングやIndexあたりは押さえておきたい

大規模サービスのIDって被りそうですよね

• 自分たちが当たり前のように使っているuuidですが、ランダム文字列にも限界はあるわけで、大規模なデータを扱うとその弊害を考慮しないといけないそうです。

• 参考資料内のTwitterではタイムスタンプ、マシンID, 同一マシン内でのシーケンスIDなどを組み合わせることで「この時このマシンで！」を活用することでユニークを確保してるそうです！

Laravel案件で用途別に標準採用したいパッケージ群

• コードフォーマット

  • Laravel Pint
    PHP-CS-Fixerベースのコードフォーマッター。

• テスト

  • Pest
    BDD系のテスティングフレームワーク。PHPUnitのAssertionsに加え、Expectationsによってよりシンプルに書ける。

• 静的解析

  • larastan
    Laravel内で静的解析するのに便利。

• APIドキュメント

  • Spectator
    APIドキュメント整備の方法も議論の余地があるが、それはおくとして、実装したAPIリクエスト・レスポンスが生成されたOpenAPIに準拠しているかテストできる。

バグの見つけ方と向き合い方

バグのアプローチの仕方は2種類ある！

1. コードを読む

2. 実際の挙動から読み解く

1はロジックを頭から確認することで「あれ？おかしくないか？」を閃く手法です。一方2は逆に実際のアプリケーションーの挙動から「きっとここまではうまく動いてるだろう」とおかしい場所をシミュレートできるアタリをつけるのに向いてます。
1、2を組み合わせて適切に対処できると良い！！

コスパ良く対処するには手から動かせ！

まずは何も考えずログを貼ったりおかしい箇所を動かしまくる！ケアレスミスとかはこれだけで見つかる
続いて「目」で挙動の確認する。↑で説明した挙動を読み解く作業です。
それでも解決しなかったら「頭」でロジックをシミュレートする
この `手->目->頭` の順でデバッグを行うことで、簡単なバグにこんなに時間を割いてしまった…!みたいなことが減ると良いですね