QUIZ 30分

チェックポイント:レビューを受ける心構えを知ろう

クイズの説明

Step 4で学んだ内容の理解度をチェックします。

  • 全10問
  • 合格ライン: 80%(8問正解)
  • 不合格の場合は復習してから再挑戦してください

問題

Q1. コードレビューの主な目的として正しくないものはどれですか?

  • A) バグの早期発見
  • B) コードの品質向上
  • C) 開発者の能力を評価すること
  • D) 知識の共有
<details> <summary>答えを見る</summary>

正解: C

コードレビューの目的はバグ発見、品質向上、知識共有、一貫性維持です。 開発者の能力評価が目的ではなく、あくまで品質を高めるための協力作業です。

</details>

Q2. レビューコメントを受けたときの最初のステップとして適切なものは?

  • A) すぐに修正を始める
  • B) 感謝を伝える
  • C) 反論する
  • D) 上司に相談する
<details> <summary>答えを見る</summary>

正解: B

レビューへの対応5ステップの最初は「感謝する」です。 レビュアーの時間を使って品質を高めてくれる行為に対し、まず感謝を伝えましょう。

</details>

Q3. 「Nit」コメントの意味として正しいものは?

  • A) 絶対に修正しなければならない致命的な指摘
  • B) 些細な指摘(可能なら対応する程度のもの)
  • C) セキュリティに関する重要な指摘
  • D) テストを追加すべきという指摘
<details> <summary>答えを見る</summary>

正解: B

「Nit」は "nitpick"(些細なこと)の略で、軽微な指摘を意味します。 命名規則のずれやインデントの微調整など、修正が望ましいが必須ではない指摘です。

</details>

Q4. セルフレビューの目的として最も適切なものは?

  • A) レビュアーを不要にすること
  • B) 自分で見つけられる問題は自分で直してからPRを出すこと
  • C) コードを完璧にすること
  • D) テストの代わりにすること
<details> <summary>答えを見る</summary>

正解: B

セルフレビューは「レビュアーの時間を大切にする」ための準備です。 デバッグコードの削除や不要な変更の除去など、自分で気づけることは自分で対応してからPRを出します。

</details>

Q5. PR説明文に含めるべき情報として最も重要でないものは?

  • A) 何を変更したか
  • B) なぜ変更したか
  • C) コードを書くのにかかった時間
  • D) テスト結果
<details> <summary>答えを見る</summary>

正解: C

PR説明文には概要、変更内容、変更理由、テスト結果、関連チケットを含めます。 コーディングにかかった時間はレビューに必要な情報ではありません。

</details>

Q6. レビューで指摘された内容が理解できない場合、どうすべきですか?

  • A) わからないまま適当に修正する
  • B) 指摘を無視する
  • C) 自分の理解を示しながら質問する
  • D) 別の人に代わりに修正してもらう
<details> <summary>答えを見る</summary>

正解: C

わからないときは遠慮なく質問しましょう。 「○○ということですか?」のように自分の理解を示しながら質問すると、 レビュアーも的確な回答ができます。

</details>

Q7. レビューの提案に対して別のアプローチを取りたい場合、適切な対応は?

  • A) 無言で自分のアプローチのまま進める
  • B) 理由を説明して議論する
  • C) レビュアーの言う通りに全て従う
  • D) PRを閉じて新しく作り直す
<details> <summary>答えを見る</summary>

正解: B

提案に対して別の考えがある場合、理由を丁寧に説明して議論します。 無言で放置したり、何も考えずに従うのではなく、建設的な対話が大切です。

</details>

Q8. 適切なPRのサイズの目安は?

  • A) 10行以下
  • B) 50行以下
  • C) 200〜400行以下
  • D) 制限なし
<details> <summary>答えを見る</summary>

正解: C

PRは200〜400行程度が適切なサイズです。 大きすぎるPRはレビューの質が下がり、小さすぎると文脈がわからなくなります。 400行を超える場合は分割を検討しましょう。

</details>

Q9. レビューで同じ指摘を繰り返し受けないためにすべきことは?

  • A) レビュアーを変更する
  • B) レビューの学びを記録し、チェックリストに反映する
  • C) レビューを受けないようにする
  • D) 完璧になるまでPRを出さない
<details> <summary>答えを見る</summary>

正解: B

レビューで受けた指摘を記録し、自分のチェックリストに追加することで、 同じミスを繰り返さなくなります。これが成長の証です。

</details>

Q10. コードレビューに対する正しい認識はどれですか?

  • A) レビューは試験であり、評価される場
  • B) 指摘が多い人はダメな開発者
  • C) レビューは品質を高めるための協力作業
  • D) レビューは上司が部下を管理するためのもの
<details> <summary>答えを見る</summary>

正解: C

コードレビューは品質を高めるための協力作業です。 指摘が多いことは「学びが多い」ことであり、成長のチャンスです。 試験や評価の場ではありません。

</details>

結果

8問以上正解の場合

合格です!おめでとうございます!

Step 4「レビューを受ける心構えを知ろう」を完了しました。 次はStep 5「指摘を活かして修正しよう」に進みましょう。

7問以下の場合

もう少し復習しましょう

間違えた問題の内容を、該当するセクションで復習してください:

問題復習セクション
Q1, Q10step4_1 コードレビューとは
Q4-Q5, Q8step4_2 レビューを受ける準備
Q2-Q3, Q6-Q7, Q9step4_3 レビューコメントへの対応

Step 4 完了!

お疲れさまでした!

学んだこと

  • コードレビューの目的と本質
  • レビューを受ける前の準備(セルフレビュー、PR説明文)
  • レビューコメントへの対応方法(感謝、理解、質問、修正、記録)

次のステップ

Step 5: 指摘を活かして修正しよう(4時間)

レビューの指摘から学び、同じミスを繰り返さない方法を学びます。


推定所要時間: 30分