⛳
(個人メモ)振り返りと次回PJのTry
問題点と次回のTry
個人的な備忘として残します。
組織観点
- PRレビューにかける工数が少なかった結果、後からバグや可読性の低いコードが見つかり手戻りが発生した
- テックリードのPRレビューを必須かする
- PRのテンプレートを作成して、レビュイー、レビュワーの観点を明確にする
- 実装者が本番環境で最低限の試験をすることが明文化されていなかったため、初歩的なバグも検知が遅れた
- github flowで運営している都合上、自分が実装したfeatureはすぐに本番へ反映されるため、反映されたら最低限機能改修したところは確認する
技術観点
- ローカル環境では動くが、本番環境で動かないバグがあった
- Prismaのインポート漏れが原因のことが多く、Linterで防ぎたい
- 本番環境前のプレビュー環境のようなものを用意してそこで確認してもらう。プレビュー環境は簡単に構築&破棄できるものがいい。AmplifyとかVercelではブランチプッシュで専用の環境作れるがそんなイメージ
- Prismaのマイグレーションでデータ消えたり・・
- ルールがなかったので作る。ローカルは自由、本番はCICDで自動でマイグレーション適用する
- デバッグに必要なログがcloudwatchlogsに十分に出ていなかった気がする
- ログ出力を見越してアプリケーション設計/コーディングする
- 本番運用を見越してsentryとか入れたい
改めて今回のPJのTry
- レビューのルール決めて、テックリードのレビューを回す
けどレビュー必須とかってすると、週5じゃない都合上スピード落ちるので、どうするか・・ - プレビュー環境みたいなものを作る
- Remixを使う
- 高速で開発したい都合上、フロントとバックエンドは同じリポジトリ、同じホストで動かしたい。今回と同じように1つのAppRunner上で動かす
- ビルドが早くなるようにしたい、プレビュー環境とか作るなら
- ログが出るような設計
- storybook使ったテスト入れたい、sentry入れたい
- AppRunner+Aurora Serverless+踏み台のシンプルな構成
- Prisma使う？
今回の開発要件に関して懸念
- PWA初めて・・
- お客様によって機能の出しわけを行う、Feature Flagの適用
参考にしたい記事
PWAに関して
Remixのディレクトリ構成
Discussion