5.5コードレビューとシーケンス図の解釈

自動化は一度書いて終わりではなく、チームで安全に変更し続ける営みです。そのための2つの実践がこの節のテーマです。1つはコードレビュー——変更を本番に入れる前に第三者が読み、バグ・可読性・セキュリティを点検する仕組み。もう1つはシーケンス図の読解——複数のコンポーネント（クライアント・API・認証サーバ）がどの順で・何をやり取りするかを図から掴む力です。どちらも「暗記」ではなく、提示されたレビュー状況・図を解釈して次の一手を判断する題材として学びます。

5.5.1コードレビューの原則と利点

• レビューの狙いはバグの早期発見・可読性/保守性・セキュリティ・知識共有。変更を本番前に第三者が読むことで、平文パスワードのハードコードや危険な削除、境界条件の見落としをリリース前に捕まえられる。属人化を防ぎ、チームで設計意図を共有する効果も大きい。
• 良いレビューの実践：PRは小さく（差分が小さいほど見落としが減る）、正しさ・可読性・セキュリティに焦点を当て、人格でなくコードを対象に建設的に指摘する。指摘は具体的・根拠付きで、修正提案を伴うと良い。CIの自動チェック（lint/テスト）を通した上で人のレビューを重ねると効率的。

5.5.2シーケンス図を読む

• シーケンス図は、上部のアクター/オブジェクト（例：Client / Auth Server / API）から下へ伸びるライフライン（縦線）と、それらを結ぶメッセージの矢印で構成される。時間は上から下へ流れ、矢印の向きが呼び出し方向を表す。実線＝要求（呼び出し）、破線の戻り矢印＝応答、というのが一般的な表記。
• API連携の図を読む勘所は順序と依存：例えば「Client→Auth: トークン要求／Auth→Client: トークン（応答）／Client→API: GET（Bearerトークン付き）／API→Client: 200＋データ」なら、認証が先・データ取得が後という依存が読める。途中にAPI→Client: 429が現れればレート超過→待って再試行という制御の必要性が図から分かる。