java-code-review

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コードをレビューするときは、次の形式で出力する。

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

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

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

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

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