理解度チェック：コードレビューの心得

ストーリー

「Step 1 の内容をどれだけ理解できたか確認しよう」

松本先輩がチェックテストを用意してくれた。

「マインドセット、チェックリスト、コメントの書き方、 ツール、レビュー文化......基礎中の基礎だが、 ここがしっかりしていないと実践で躓く。 自信を持って答えてくれ」

クイズの説明

Step 1 で学んだコードレビューの基礎知識を確認します。

• 全5問
• 合格ライン: 80%（4問正解）
• 不合格の場合は、該当セクションを復習してから再挑戦してください

問題

Q1. コードレビューのマインドセットとして最も適切なものはどれですか？

• A) レビュアーはコードの欠陥を全て見つけるべきであり、完璧を求めるべきだ
• B) レビューの対象はコードであり、人を批判するものではない。学ぶ姿勢と良い点を伝えることも重要
• C) レビューは上級者が下級者のコードを指導する場であり、一方向のフィードバックが理想的
• D) レビューのスピードが最も重要であり、細かい指摘は避けるべきだ

正解: B

コードレビューの基本は「コードに向き合い、人を批判しない」ことです。レビュアーも学ぶ姿勢を持ち、問題点だけでなく良い点も積極的に伝えることが、健全なレビュー文化の基盤となります。完璧を求めすぎるとボトルネックになり（A）、一方向のフィードバックでは学びが限定されます（C）。

Q2. レビューコメントのプレフィックスとして、「SQLインジェクションの脆弱性を発見した」場合に使うべきものはどれですか？

• A) [Nit]
• B) [Should Fix]
• C) [Must Fix]
• D) [FYI]

正解: C

SQLインジェクションはセキュリティの脆弱性であり、本番環境でデータ漏洩やデータ破壊につながる重大な問題です。[Must Fix] を使い、マージ前に必ず修正するよう求めるべきです。[Nit] は些細な指摘、[Should Fix] は品質改善の推奨、[FYI] は参考情報です。

Q3. レビューチェックリストの7つの観点のうち、「N+1クエリ問題の検出」はどの観点に該当しますか？

• A) 正確性（Correctness）
• B) 設計（Design）
• C) セキュリティ（Security）
• D) パフォーマンス（Performance）

正解: D

N+1クエリ問題はパフォーマンスの観点に該当します。データ量が増えるとクエリ数が線形に増加し、レスポンスタイムが悪化します。JOINやEager Loadingを使うことで1回のクエリに最適化できます。

Q4. PRのレビュー効率化のために、GitHub上で設定できるファイルの組み合わせとして正しいものはどれですか？

• A) CODEOWNERS と pull_request_template.md
• B) CODEOWNERS と .gitignore
• C) .editorconfig と .prettierrc
• D) package.json と tsconfig.json

正解: A

CODEOWNERS は特定のファイルやディレクトリの変更に対して自動的にレビュアーをアサインする仕組みで、.github/pull_request_template.md はPR作成時のテンプレートです。両方ともレビューの効率化に直接貢献します。B/C/Dはレビュー効率化とは別の目的のファイルです。

Q5. レビュー文化を阻害する要因とその対策の組み合わせとして最も適切なものはどれですか？

• A) 大きすぎるPR → レビュアーの人数を増やす
• B) 心理的安全性の欠如 → コードレビューを廃止する
• C) レビューが後回しになる → スプリント計画にレビュー時間を含める
• D) スキル差がある → 上級者だけがレビューを担当する

正解: C

レビューが後回しになる問題への対策は、スプリント計画にレビュー時間を明示的に含めることです。大きすぎるPRの対策は「分割する」こと（A）、心理的安全性にはフィードバック規約の整備（B）、スキル差には全員参加のルール化（D）が適切です。

結果

4問以上正解の場合

合格です。Step 2 に進みましょう。

松本先輩が頷いた。

「基礎はしっかり身についているな。 次は実践だ。実際にコードを読んでレビューしてみよう」

3問以下の場合

もう少し復習しましょう。

次のステップへ

Step 2 では、実際のコードを使ってレビューを実践します。コードスメルの検出やリファクタリングの提案など、より実践的なスキルを身につけましょう。

推定読了時間: 15分