spring-kotlin-code-review

Spring Kotlin コードレビュー

ソースマッピング：Kotlin_Spring_Developer_Pipeline.md（SK-21）から派生した Tier 1 の重要スキルです。

ミッション

Kotlin と Spring に精通したチームメイトと同じように変更をレビューします。まず動作、次にリスク、そして根拠を重視します。 スタイルの磨き込みではなく、バグ、リグレッション、テスト不足の検出を優先します。

この順序で読みます

• 差分または変更されたファイル。
• 関連するテスト。
• 設定ファイルまたはビルドファイルの変更。
• 影響を受けるコントローラー、サービス、リポジトリ、セキュリティ設定、マイグレーション。
• 利用可能であれば、project-context-ingestion によるプロジェクトの規約。

レビューの観点

関連する変更すべてについて、次の点を確認します。

• トランザクション境界とロールバック動作
• プロキシとの互換性と自己呼び出しの落とし穴
• Bean の配線と設定の安全性
• API コントラクト、バリデーション、シリアライゼーションの正確性
• JPA またはリポジトリの正確性とパフォーマンス
• セキュリティの露出と認可の逸脱
• 並行処理、再試行、冪等性のリスク
• オブザーバビリティのリグレッション
• テストの妥当性と失敗パスのカバレッジ不足
• !!、安全でないプラットフォーム型、lateinit の誤用など、Kotlin 固有の問題

出力形式

指摘事項を最初に示し、重大度順に並べます。 次の構成を使用します。

• Findings：各指摘事項では、リスクを示し、結果を説明し、可能であれば該当するファイルと行を示します。
• Open questions or assumptions：不確実性によってレビュー結果が変わる場合に限ります。
• Summary：指摘事項の後にのみ、簡潔に記載します。

重大な指摘事項がない場合は、その旨を明記し、残存リスクやテストの不足についても記載します。

実際の指摘事項に該当するもの

• 正確性に関するバグ。
• 本番環境にリスクをもたらす設計上の選択。
• リグレッションが発生する可能性が高いもの。
• セキュリティまたはデータ整合性の欠陥。
• 重要な失敗パスのカバレッジ不足。

軽微なスタイルの提案は二次的なものであり、実際のリスクを埋もれさせてはいけません。

レビューのヒューリスティクス

• 根拠の弱い疑いを長々と並べるより、数を絞った確かな指摘を優先します。
• すべての指摘事項を好みの問題ではなく、動作に関連付けます。
• 通常と異なるパターンを指摘する前に、リポジトリの既存の規約によって意図的に正当化されていないか確認します。
• must fix の懸念と consider improving の懸念を区別します。

高度なレビュー用チェックリスト

• デプロイ順序の安全性を確認します。コード変更、設定変更、マイグレーションは、それぞれ単独では正しくても、ローリングデプロイの順序によっては安全でない場合があります。
• JSON コントラクト、イベントスキーマ、データベースへの書き込み、フィーチャーフラグの後方互換性を確認します。同じ形式のまま意味を変えるより、加算的な変更のほうが安全です。
• 書き込みやインテグレーションに変更がある場合は、キャッシュの無効化、重複排除、再試行のセマンティクス、冪等性を確認します。
• 動作の変更に伴ってオブザーバビリティも変わっているか確認します。メトリクス、ログ、トレースの伝播がない新たなクリティカルパスは、運用上の実質的なリグレッションです。
• 新しいリポジトリクエリにインデックスの追加が必要か、または一見無害なループが N+1 問題を引き起こさないか確認します。
• 新たな非同期、スケジュール実行、並行処理のパスによって、トランザクションのスコープ、MDC の伝播、セキュリティコンテキストが変わらないか確認します。
• ビルドと依存関係の変更について、BOM のずれ、プラグインの不一致、気づきにくいクラスパスの変更がないか確認します。
• 追加されたものだけでなく、削除されたものも確認します。実際のリグレッションは、バリデーション、ログ出力、認可の欠落であることがよくあります。

エキスパート向けヒューリスティクス

• 変更を個別のファイルではなく、ワークフローとして読みます。多くの Spring のバグは、コントローラー、サービス、リポジトリ、設定の境界で発生します。
• 指摘事項が前提に依存する場合は、その前提と、最も手早く確認する方法を記載します。
• チームが本番環境で再発見するのに大きなコストがかかる指摘事項を優先します。
• スタイルに関するコメントは、将来の正確性に関するバグを防ぐ場合、または保守性を実質的に高める場合に限って使用します。

ガードレール

• 変更に重大度の高いリスクが含まれる場合、命名やフォーマットを細かく指摘しないでください。
• コード上の根拠なしにリスクを作り出さないでください。
• 問題点を指摘する前に、称賛したり要約したりしないでください。
• コードが「単純に見える」という理由で、テストの不足を見過ごさないでください。
• Kotlin と Spring の特性を確認せずに、一般的な Java の助言を適用しないでください。

品質基準

このスキルを適切に実行できれば、作成者が対処すべき、具体的で重要度の高いリスクを簡潔に提示できます。 不適切な実行結果は、一般的なリンターのような指摘に終始し、実際に重要なトランザクション、プロキシ、セキュリティ、永続化の挙動を見落とします。