コードレビュー

コードレビューとは

コードレビューは、書いたコードを他のメンバーが読んで確認するプロセスです。バグや設計の問題を早い段階で見つけるだけでなく、チーム内で知識を共有し、コードの品質と一貫性を保つことが目的です。

現代の開発では、[[Git]] のホスティングサービス(GitHub など)のプルリクエスト(変更の取り込み依頼)上でレビューするのが主流です。変更内容の差分にコメントを付け、承認されたらマージする、という流れで進みます。

レビューで見るポイント

細かい書式の指摘は [[静的解析とリンター]] のようなツールに任せ、人間は設計や仕様の妥当性に集中するのが効率的です。

レビューする側・される側の心得

• コードを批評し、人を批評しない — 「このコードは」と主語をコードにする
• 指摘には理由を添える — 「なぜそうすべきか」が伝わると学びになる
• 変更は小さく出す — 差分が大きいほどレビューの質は下がります
• 指摘は提案として受け取る — レビューは攻撃ではなく品質向上の協力です
• 良い点にも言及する — 良いパターンの共有もレビューの価値です

初学者向けポイント

• レビューは「先輩が新人を採点する場」ではなく、経験に関係なくお互いに行うのが健全なチームです。新人の素朴な疑問が設計の問題をあぶり出すこともあります
• 指摘をたくさんもらうのは普通のことです。指摘ゼロを目指すより、同じ指摘を繰り返されないことを目指しましょう
• レビューを依頼するときは、変更の目的や確認してほしい点を説明文に書くと、レビューの質が上がります
• リアルタイムに相談しながら書く [[ペアプログラミングとモブプログラミング]] は、レビューを「書きながら行う」形とも言えます

関連技術とのつながり

• [[Git]] — プルリクエストによるレビューの土台となるバージョン管理
• [[ブランチ戦略]] — レビューを挟むタイミングはブランチ運用とセットで決まる
• [[クリーンコード]] — レビューの観点「読みやすさ」の具体的な指針
• [[ペアプログラミングとモブプログラミング]] — リアルタイムなレビューとも言える開発スタイル
• [[Webセキュリティ]] — 観点「セキュリティ」で何を確認するかの具体的な脆弱性パターン

Q: コードレビューの主な目的として正しいのはどれ?
- [x] バグや設計の問題を早期に見つけ、知識を共有する
- [ ] 書いたコードの行数を評価して人事査定に使う
- [ ] リリース後にバグの犯人を特定する
解説: レビューは品質向上と知識共有のための仕組みであり、人の採点や犯人探しの場ではありません。

Q: レビューの効率を上げる工夫として本文で挙げられているのはどれ?
- [ ] 差分をできるだけ大きくまとめて一度に出す
- [x] 書式の指摘はツールに任せ、人間は設計や仕様に集中する
- [ ] コメントには理由を書かず結論だけ伝える
解説: リンターやフォーマッターで済む指摘は自動化し、人間は設計・仕様の妥当性など機械が判断できない部分に集中します。

Q: レビューコメントの望ましい書き方はどれ?
- [ ] 「あなたの書き方は悪い」と人を主語にする
- [ ] 理由は省略して修正指示だけ書く
- [x] コードを主語にして、指摘の理由を添える
解説: 「コードを批評し、人を批評しない」が原則です。理由を添えることで指摘が学びにつながります。