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