Code Review Java

---
name: java-code-review
description: Javaコードの品質・安全性・保守性・パフォーマンスをレビューするスキル。JavaファイルやJava関連のPRレビュー、ユーザーがJavaコードレビューを求めたときに使用する。
---

# Java Code Review

## ゴール

Javaコードを以下の観点からレビューする。

- **正しさ**: 仕様どおりに動作し、例外やバグを生まないか
- **安全性**: セキュリティ上の問題がないか
- **保守性**: 読みやすく変更しやすい構造になっているか
- **パフォーマンス**: 明らかなボトルネックや無駄な処理がないか
- **一貫性**: プロジェクトのコーディング規約や設計方針に沿っているか

このスキルは、**Javaファイル単体のレビュー**と、**PR全体のレビュー**の両方で使う。

## レビュー手順（全体の流れ）

1. 変更の概要を把握する
   - 何のための変更か（バグ修正／機能追加／リファクタリングなど）
   - 公開APIに影響があるか（インターフェース・DTO・REST API など）
2. 影響範囲を把握する
   - 呼び出し元／呼び出し先クラス
   - データベースや外部サービスとの連携箇所
3. 主要な観点でコードを確認する（以下のチェックリストに沿う）
4. 気づいた点を**優先度付き**でコメントする
   - **[Critical]**: バグ・セキュリティ・設計上の重大な問題
   - **[Major]**: 保守性・性能などの重要な改善点
   - **[Minor]**: 命名・スタイル・微細なリファクタリング提案
5. 最後に**まとめコメント**を書く
   - 変更の良い点
   - 必ず修正してほしい点
   - 任意で検討してほしい改善案

## 共通チェックリスト

### 正しさ・堅牢性

- [ ] 入力値検証（null／空文字／範囲外など）が適切か
- [ ] nullチェックが必要な箇所で抜けていないか
- [ ] `Optional` の使い方が適切か（無理に `get()` していないか）
- [ ] コレクションの空チェックができているか（`isEmpty()` など）
- [ ] 境界条件・例外ケースを考慮したロジックになっているか
- [ ] 例外処理で握りつぶし（空catchやログのみ）が行われていないか
- [ ] ログ出力のレベル（INFO/WARN/ERROR）が適切か

### 設計・保守性

- [ ] クラス／メソッドの責務が単一か（God Class / Long Method になっていないか）
- [ ] メソッドの長さが適切か（複雑な処理は分割されているか）
- [ ] 条件分岐がネストしすぎていないか（早期returnなどで整理できないか）
- [ ] 命名が「役割」や「ドメイン」を反映しているか
- [ ] インターフェース／抽象クラスの境界が妥当か
- [ ] DI（依存性注入）が適切に使われているか（newで直接生成しすぎていないか）
- [ ] 定数・マジックナンバーが適切に切り出されているか

### パフォーマンス・リソース管理

- [ ] 不必要なオブジェクト生成や`new`がループ内で多発していないか
- [ ] ストリームAPIの利用が過剰／過度にネストしていないか
- [ ] コレクション操作で大きなデータに対して非効率なアルゴリズムを使っていないか
- [ ] I/O・DBアクセス・外部APIコールが最小限に抑えられているか
- [ ] `try-with-resources` でリソースクローズが自動化されているか

### セキュリティ

- [ ] SQLクエリでプレースホルダを使っているか（SQLインジェクション対策）
- [ ] 外部入力値をログに出す際に機密情報（パスワード、トークン等）が含まれていないか
- [ ] シリアライズ／デシリアライズにおける型安全性が保たれているか
- [ ] コマンド実行やファイルパス操作で危険な入力を許していないか

### テスト

- [ ] 変更に対するテスト（ユニットテスト／統合テスト）が存在するか
- [ ] 正常系・異常系・境界値をカバーするテストがあるか
- [ ] モックの使い方が妥当か（過度なモック／実データ依存がないか）
- [ ] 新しいパブリックメソッド・ビジネスロジックにテストが追加されているか

## Spring / Webアプリでの追加観点（該当する場合）

- [ ] RESTコントローラでHTTPステータスコードが適切に返却されているか
- [ ] バリデーションアノテーション（`@NotNull`, `@Size` など）が適切か
- [ ] トランザクション境界（`@Transactional`）が妥当な単位で設定されているか
- [ ] エラー応答の形式がAPI仕様（エラーレスポンスフォーマット）と一致しているか
- [ ] N+1クエリなどORM特有の問題が発生していないか

## コメントの書き方ガイド

レビューコメントは、**具体的で提案を含む**形で記述する。

- **Bad**: 「この命名は微妙です」
- **Good**: 「このメソッドはバリデーションのみを行っているので、`validateUserInput` のような名前にすると役割が明確になりそうです」

推奨フォーマット:

- **[Critical] 内容**: バグ・セキュリティ・仕様不整合など
- **[Major] 内容**: 構造・パフォーマンス・分かりにくさなど
- **[Minor] 内容**: 命名・コメント・スタイルなど

## 出力フォーマット（テンプレート）

Javaコードをレビューするときは、次の形式で出力する。

```markdown
### 概要
- 変更の目的と全体的な印象を1〜3行でまとめる。

### 良い点
- 良い点1
- 良い点2

### 指摘事項
- [Critical] 箇所と理由、修正案
- [Major] 箇所と理由、修正案
- [Minor] 箇所と理由、修正案

### 補足・提案（任意）
- 将来的なリファクタリング案や設計上の提案があれば記載
```

このテンプレートに沿って、**過不足なく・優先度付きで**コメントをまとめること。