java-code-review

Java コードレビュー

Java コードを対象に、範囲を絞った根拠に基づくレビューを実施し、ユーザーが別の場所を指定しない限り、リポジトリのルートにある review.md に指摘事項を記載します。 このスキルはコードをレビューするものであり、ユーザーが修正を明示的に依頼しない限り、本番コードを変更しないでください。

レビュー範囲の確定

1. ユーザーがファイル、クラス、パッケージ、コミット、または差分を明示的に指定している場合は、その範囲を使用し、暗黙のうちに対象を広げないでください。
2. それ以外の場合は、git ワークツリーを調べ、変更、追加、または名前変更されたファイルをレビューします。git status --short と、該当する git diff（ステージ済みの変更がある場合はそれも含む）を使用してください。名前が変更されたファイルについては、変更後のファイルと意味のある差分をレビューします。
3. レビュー対象の Java コードの動作に影響する場合に限り、関連する Java および Java 周辺ファイル（例：テスト、SQL マイグレーション、設定、API スキーマ）を含めます。レポートには選定した範囲を記載してください。
4. 各指摘を検証するため、周辺のコード、呼び出し元、テスト、設定、インターフェースを十分に確認してください。名前や一般的なベストプラクティスだけを根拠に懸念を指摘しないでください。

レビュー対象

• 潜在的なバグ： 条件の誤り、null／空の値の処理、状態やトランザクションのエラー、例外処理、リソースリーク、並行処理の問題、セキュリティや認可の不備、API／シリアライズの不整合、永続化の誤り、境界条件。
• 重複コード： 繰り返されるロジック、コピー＆ペーストされた分岐、重複したマッピング／検証、意味のある差異の拡大を抑えられる抽象化。
• 改善が必要な点： 不明瞭または脆弱な設計、過度な結合、誤解を招く名前、回避可能な複雑さ、テスト不足、パフォーマンス上の懸念、プロジェクトで確立された規約への違反。

スタイルよりも正しさと影響を優先してください。具体的な保守性、信頼性、セキュリティ、またはパフォーマンス上の問題につながらない限り、書式や好みに基づく代替案を指摘しないでください。確認済みの問題とリスクまたは疑問を区別し、憶測に基づく指摘は避けてください。

指摘事項の検証

指摘ごとに、関連する制御フローとデータフローを追跡してください。近くにあるテストを確認し、可能であれば、最小限で有効なテスト、コンパイル、静的解析、または再現コマンドを実行してください。検証を通すためにファイルを変更しないでください。検証を実行できない場合は、その理由を記載してください。疑われる問題が、呼び出し元、フレームワークの契約、アノテーション、または設定によってすでに対処されていないか確認してください。

review.md の作成

作成する前に、指定された出力ファイルがすでに存在するか確認してください。

• 存在する場合は、上書きするか新しいファイル名を使うかをユーザーに尋ねてください。ユーザーが選択する前に上書きしてはいけません。
• ユーザーが新しいファイル名を選んだ場合は、そのファイル名を（リポジトリ内、または指定された出力先で）そのまま使用してください。
• レポートが存在しない場合は、review.md を作成してください。

レポートは単独で内容が理解できるものとし、次を含めてください。

# Java Code Review

## Scope


## Summary


## Findings

### [SEVERITY] Short title
- **Location:** `path/to/File.java:line`
- **Category:** Bug | Duplicate code | Improvement
- **Confidence:** High | Medium | Low

**Problem**
Explain the concrete behavior and why it matters, citing the relevant code.

**Suggested fix**
Give a specific implementation approach, including edge cases and tests to
add or update. Do not merely say “refactor” or “add validation.”

## Positive observations


## Validation

重要度は一貫して使ってください。Blocker（安全でない、または明らかに壊れている）、High（本番環境での障害、または重大なセキュリティ／データ上の問題が起こる可能性が高い）、Medium（意味のあるバグ、または保守性上のリスク）、Low（軽微だが対応可能）。指摘事項は重要度の高い順、次にファイルと行の順に並べてください。個別の問題ごとに指摘を1件とし、重複を避け、レビュー対象のバージョンで意味が通じる正確な行番号を示してください。指摘がない場合は、その旨を明確に記載し、範囲、検証内容、肯定的な所見も含めてください。

最終回答

レポートを作成したことをユーザーに伝え、生成したファイルへのリンクを記載してください。指摘件数を示し、Blocker または High の指摘がある場合は簡潔に説明してください。既存ファイルについて選択が必要なためレポートを作成できない場合は、上書きするか新しいファイル名を使うか尋ね、書き込みを行わずに終了してください。