この記事の目次
Step7: セルフチェック
コードレビューを依頼する前に、自分でチェックできることは自分でチェックします。これにより、レビュアーの負担を減らし、指摘される回数を減らせます。
なぜセルフチェックが重要なのか
初心者あるある: 「とりあえずレビュー出したら、たくさん指摘された...」
セルフチェックを怠ると：
- レビュアーの時間を奪う: 簡単なミスの指摘に時間を取られる
- 信頼を失う: 「この人はチェックしないで出してくる」と思われる
- やり取りが増える: 指摘→修正→再レビューの往復が増える
セルフチェックをすると:
- レビュアーが本質的な指摘に集中できる
- 「ちゃんと確認してから出している」と信頼される
- レビューの往復が減り、早くマージできる
セルフチェックの観点
観点1: 仕様との整合性
チェック内容: 仕様通りに実装できているか
チェックリスト:
□ 要求された機能がすべて実装されているか
□ 画面の表示内容は仕様通りか
□ エラーメッセージは仕様通りか
□ 計算結果は正しいか
□ 仕様にない機能を勝手に追加していないか
やり方:
1. 設計書・仕様書を開く
2. 仕様の各項目を1つずつ確認
3. 「この仕様は、このコードで実現している」と対応づける
観点2: コードの品質
チェック内容: 読みやすく、保守しやすいコードか
チェックリスト:
□ 変数名・メソッド名は意味が分かるか
□ マジックナンバーは定数化されているか
□ 1つのメソッドが長すぎないか（30行目安）
□ ネストが深すぎないか（3階層目安）
□ 重複コードはないか
□ コメントは適切か（必要な箇所にあるか、不要なものはないか）
観点3: 既存コードとの整合性
チェック内容: プロジェクトのルールに従っているか
チェックリスト:
□ 命名規則に従っているか
□ インデント・フォーマットは統一されているか
□ ログ出力の形式は合っているか
□ エラーハンドリングの方法は合っているか
□ 既存の類似処理と同じ書き方をしているか
観点4: エラー処理
チェック内容: 異常系が適切に処理されているか
チェックリスト:
□ nullチェックは適切か
□ 入力値の検証は十分か
□ 例外処理は適切か（握りつぶしていないか）
□ エラー時のログ出力は十分か
□ トランザクションのロールバックは正しいか
観点5: セキュリティ
チェック内容: セキュリティ上の問題がないか
チェックリスト:
□ SQLインジェクション対策（パラメータバインド）
□ クロスサイトスクリプティング対策（エスケープ）
□ 機密情報をログに出力していないか
□ パスワードをハードコードしていないか
□ 不要な情報をレスポンスに含めていないか
観点6: パフォーマンス
チェック内容: 明らかなパフォーマンス問題がないか
チェックリスト:
□ ループ内でDBアクセスしていないか（N+1問題）
□ 不要なデータを取得していないか
□ 大量データを一度にメモリに読み込んでいないか
セルフチェックの実践方法
方法1: 差分を見直す
# コミット前に差分を確認
git diff
# ステージング済みの差分を確認
git diff --staged
ポイント:
- 追加・変更した行を1行ずつ確認
- 「なぜこの変更が必要か」を説明できるか
方法2: 時間を置いてから見直す
書いた直後 → 休憩 → 見直す
理由:
- 書いた直後は「正しいはず」というバイアスがかかる
- 時間を置くと客観的に見られる
- 別の視点で見返せる
方法3: 音読する
コードを声に出して読む
効果:
- 変数名の意味が分かるか確認できる
- 処理の流れを追いやすい
- 違和感に気づきやすい
方法4: チェックリストを使う
毎回同じチェックリストを使う
効果:
- 確認漏れを防げる
- チェック品質が安定する
- 慣れてくると自然にできるようになる
セルフチェックリスト（テンプレート）
レビュー依頼前に、以下を確認しましょう：
基本
- [ ] コンパイルエラー・構文エラーがない
- [ ] 動作確認を完了している
- [ ] 不要なデバッグコードを削除した
- [ ] コメントアウトしたコードを削除した
仕様
- [ ] 仕様書の要件をすべて満たしている
- [ ] 仕様にない機能を追加していない
- [ ] 画面表示・メッセージが仕様通り
コード品質
- [ ] 命名が分かりやすい
- [ ] マジックナンバーがない
- [ ] メソッドが長すぎない（30行目安）
- [ ] ネストが深すぎない（3階層目安）
- [ ] 重複コードがない
既存コードとの整合性
- [ ] 命名規則に従っている
- [ ] フォーマットが統一されている
- [ ] 既存の類似処理と同じ書き方
エラー処理
- [ ] nullチェックが適切
- [ ] 入力値の検証が十分
- [ ] 例外処理が適切
- [ ] エラーログが出力されている
セキュリティ
- [ ] SQLインジェクション対策済み
- [ ] XSS対策済み
- [ ] 機密情報をログに出力していない
テスト
- [ ] 単体テストを追加/更新した（必要な場合）
- [ ] 既存のテストがパスする
よくある指摘とその防ぎ方
指摘1: 「デバッグコードが残っている」
// ❌ レビューで指摘される
System.out.println("debug: " + value); // 消し忘れ
logger.debug("TODO: あとで消す"); // 消し忘れ
// ✅ セルフチェックで削除
// → 「System.out」「TODO」「FIXME」で検索
指摘2: 「コメントアウトが残っている」
// ❌ レビューで指摘される
// int oldValue = calculate(); // 旧実装
int newValue = calculateNew();
// ✅ セルフチェックで削除
// → 不要なコメントアウトは削除
// → 必要ならコミット履歴で追える
指摘3: 「命名が分かりにくい」
// ❌ レビューで指摘される
int d = 30;
String s = getData();
// ✅ セルフチェックで改善
int expirationDays = 30;
String customerName = getData();
指摘4: 「フォーマットが統一されていない」
// ❌ レビューで指摘される
if(condition){ // 既存: if (condition) {
doSomething(); // インデントなし
}
// ✅ セルフチェックで修正
// → IDEの自動フォーマットを使う
// → 既存コードと比較する
指摘5: 「nullチェックがない」
// ❌ レビューで指摘される
order.getItems().size(); // orderやitemsがnullの可能性
// ✅ セルフチェックで追加
if (order != null && order.getItems() != null) {
order.getItems().size();
}
セルフチェックにかける時間の目安
実装時間に対する目安:
- 実装 1時間 → セルフチェック 10-15分
- 実装 1日 → セルフチェック 30分-1時間
ポイント:
- 時間をかけすぎない（完璧を目指さない）
- 基本的なチェックは必ず行う
- 慣れてくると短時間で済む
次のステップ
セルフチェックが完了したら、コードレビューを依頼します。