aibot88 Java Code Review
ゴール
Javaコードを以下の観点からレビューする。
- 正しさ: 仕様どおりに動作し、例外やバグを生まないか
- 安全性: セキュリティ上の問題がないか
- 保守性: 読みやすく変更しやすい構造になっているか
- パフォーマンス: 明らかなボトルネックや無駄な処理がないか
- 一貫性: プロジェクトのコーディング規約や設計方針に沿っているか
このスキルは、Javaファイル単体のレビューと、PR全体のレビューの両方で使う。
レビュー手順（全体の流れ）
- 変更の概要を把握する
- 何のための変更か（バグ修正／機能追加／リファクタリングなど）
- 公開APIに影響があるか（インターフェース・DTO・REST API など）
- 影響範囲を把握する
- 呼び出し元／呼び出し先クラス
- データベースや外部サービスとの連携箇所
- 主要な観点でコードを確認する（以下のチェックリストに沿う）
- 気づいた点を優先度付きでコメントする
- [Critical]: バグ・セキュリティ・設計上の重大な問題
- [Major]: 保守性・性能などの重要な改善点
- [Minor]: 命名・スタイル・微細なリファクタリング提案
- 最後にまとめコメントを書く
- 変更の良い点
- 必ず修正してほしい点
- 任意で検討してほしい改善案
共通チェックリスト
正しさ・堅牢性
- 入力値検証（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] 箇所と理由、修正案
### 補足・提案（任意）
- 将来的なリファクタリング案や設計上の提案があれば記載
このテンプレートに沿って、過不足なく・優先度付きでコメントをまとめること。