概要
チーム移行するときに抑えておくべきポイントをまとめる
システムによって特性は異なるので優先順位や、必要かどうかは変化する
チェックすべきポイント
リポジトリを事前に見せてもらう
これから関わるプロダクトがどういうものか？事前に確認する必要がある。
ナレッジが管理されているか？
チームで活動していく上で必要なドキュメントが揃っているか？更新されているか？参照しやすい・検索しやすい状態になっているか？
各種図が存在するか？更新されているか？
システム構成図、ER図、クラス図、サーバ一覧などがあるか？
pngなど編集できないようなファイル形式で作らない。
ない場合は、システムの理解や問題発見につながるので早めにつくる。
セキュリティ対策できているか？
基本的なセキュリティについて、対策できているならその理由をまとめておく。
対策できていない場合は、ユーザやシステムに被害が出ないように最優先で対応する。
障害は検知できているか？
障害が起きてもわからないという状況をさけるため、障害検知は優先的におこなうべき。
ログ集約・監視はしているか？
「サーバ入ってファイルを見る」のような運用は辛いので、ログ集約・監視はやっておきたい。
パフォーマンスモニタリングできているか？
自分たちのシステムは、普段どれくらいのリクエストが来るか？CPU・メモリ利用率はどれくらいの値か？把握しておくべき。
パフォーマンスの異常を検知することで、障害の早期発見・事前解決につながる。
テストは書いてあるか？
テストが充分でないと起こる不都合について
- 単体テストの中で外部APIを呼び出したり、DB処理をおこなっているケース
APIのテスト、DB処理のテストは必要だが、単体テストの中でおこなうと、テスト失敗の原因が分かりづらくなったり、単体テストに時間がかかるので分けるべき。
さらにこのようテストをCI上でおこなうと、API呼び出しのためのトークンの登録なども必要になってくる。 - 単体テストが書いていないケース
コード変更の影響範囲がわかりづらい、結合テストが書いていないので検証に時間と労力がかかる。
CI・CDフローは整っているか？
自動テスト、自動デプロイできるようになっているか？
なるべく短い期間でデプロイするのが理想なので、デプロイに時間がかかったり、ミスが起きやすいフローになっている場合は修正する。
まとめ
これらの問題に対してチーム全体で話し合い、システムがどのような状況なのか？どこまでできるようにするのか？認識を合わせておく必要がある。
そうしないと、開発チーム間で認識の不一致が起きてしまう。
