「コードレビュー、どうコメントすればいいか分からない」と悩んでいませんか？
現役WEBエンジニアとして、日々コードレビューを行っています。
この記事では、コードレビューのコツを解説します。
目次
コードレビューの目的
なぜ必要か
| 目的 | 効果 |
|---|---|
| バグ発見 | 本番障害防止 |
| 品質向上 | 保守性の高いコード |
| 知識共有 | チームのスキルアップ |
| 一貫性 | コードスタイル統一 |
レビューする側のコツ
良いコメントの例
// NG: 何を直せばいいか分からない
これはダメです
// OK: 具体的で建設的
ここは `map` を使うと読みやすくなりそうです
例: items.map(item => item.name)
// 質問形式も有効
この処理の意図を教えてもらえますか？
チェックポイント
| 項目 | 確認内容 |
|---|---|
| 動作 | 仕様通り動くか |
| 可読性 | 読みやすいか |
| 保守性 | 変更しやすいか |
| パフォーマンス | 効率的か |
| セキュリティ | 脆弱性はないか |
心がけ
- 人ではなくコードを見る
- 良い点も指摘する
- 質問形式で柔らかく
- nit（些細）と明示する
// 些細な指摘
nit: 変数名 `data` より `userData` の方が分かりやすいかも
レビューされる側のコツ
PRの書き方
## 概要
ユーザー登録機能を実装
## 変更点
- ユーザーモデルの追加
- 登録APIの実装
- バリデーション追加
## テスト
- 単体テスト追加済み
- 手動テスト済み
## 確認してほしいこと
- バリデーションの条件が適切か
心がけ
- 小さいPRにする
- 説明を丁寧に書く
- 自分でも見直してから出す
- 指摘は素直に受け止める
指摘への返答
// NG
分かりました。（修正せず）
// OK
ご指摘ありがとうございます。
mapに変更しました。確認お願いします。
レビューの流れ
効率的なフロー
- 自動チェック（Lint、テスト）
- 概要を把握（PRの説明を読む）
- 差分を確認
- コメント
- 修正→再レビュー
- Approve
時間の目安
| PRサイズ | 目安時間 |
|---|---|
| 〜100行 | 15分 |
| 100-300行 | 30分 |
| 300行〜 | 分割を検討 |
よくある問題
対処法
| 問題 | 対処 |
|---|---|
| 指摘が多すぎる | 優先度をつける |
| 感情的になる | 人ではなくコードの話 |
| 時間がかかる | 自動化、小さいPR |
| 形骸化 | 目的を再確認 |
まとめ
コードレビューのポイント:
- 具体的で建設的なコメント
- 小さいPRで出す
- 人ではなくコードを見る
- 良い点も指摘する
