Wiz Engineer 技術共有会 5月第3週
弊社では週に一度、1時間の技術共有会を行なっています。内容としては、最近のTechなニュースや、気になること、仕事の役に立ちそうな情報をざっくばらんに共有しています。
DBの種類・設計・パフォーマンスちゃんとわかりますか？？
リレーショナルDBが弊社では一般的に使われているDBですが、最近では列志向型だったり、key-value型だったりDBの種類もかなり増えているので使い分けていきたい
パフォーマンスチューニングに関しては特に「APIが重い！」などよく言われる話で、パーティショニングやIndexあたりは押さえておきたい
大規模サービスのIDって被りそうですよね
自分たちが当たり前のように使っているuuidですが、ランダム文字列にも限界はあるわけで、大規模なデータを扱うとその弊害を考慮しないといけないそうです。
参考資料内のTwitterではタイムスタンプ、マシンID, 同一マシン内でのシーケンスIDなどを組み合わせることで「この時このマシンで！」を活用することでユニークを確保してるそうです！
参考：
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ
ソート可能なUUID互換のulidが便利そう
Laravel案件で用途別に標準採用したいパッケージ群
コードフォーマット
Laravel Pint
PHP-CS-Fixerベースのコードフォーマッター。
テスト
Pest
BDD系のテスティングフレームワーク。PHPUnitのAssertionsに加え、Expectationsによってよりシンプルに書ける。
静的解析
larastan
Laravel内で静的解析するのに便利。
APIドキュメント
Spectator
APIドキュメント整備の方法も議論の余地があるが、それはおくとして、実装したAPIリクエスト・レスポンスが生成されたOpenAPIに準拠しているかテストできる。
参考：
LaravelでAPI仕様書(OAS)と実装の乖離を簡単に防ぐならSpectatorがおすすめ！
Laravelに静的解析ツールのLarastanを導入し、厳しくチェックする
Pest
バグの見つけ方と向き合い方
バグのアプローチの仕方は2種類ある！
コードを読む
実際の挙動から読み解く
1はロジックを頭から確認することで「あれ？おかしくないか？」を閃く手法です。一方2は逆に実際のアプリケーションーの挙動から「きっとここまではうまく動いてるだろう」とおかしい場所をシミュレートできるアタリをつけるのに向いてます。
1、2を組み合わせて適切に対処できると良い！！
コスパ良く対処するには手から動かせ！
まずは何も考えずログを貼ったりおかしい箇所を動かしまくる！ケアレスミスとかはこれだけで見つかる
続いて「目」で挙動の確認する。↑で説明した挙動を読み解く作業です。
それでも解決しなかったら「頭」でロジックをシミュレートする
この `手->目->頭` の順でデバッグを行うことで、簡単なバグにこんなに時間を割いてしまった…!みたいなことが減ると良いですね