コードレビュー観点まとめ
コードレビュー
誰かが作成したソースコードを他者がレビューすることで、問題のある記法やバグがないかを確認する作業
観点（設計・機能・複雑さ・テスト・命名・コメント）
- そのコードは設計が良く、システムに適しているか？
- コードは作者が意図した通りに動作しているか？
- 他の開発者が将来このコードに出会ったとき、簡単に理解して使用することができるか？
- コードに適切なユニットテストが存在するか？
- 適切な命名がなされているか？
- 会社独自の注意事項を守っているか？
コミュニケーション
- 変更がある場合は、変更理由と代替案を提示する
- 意図が不明瞭な時は理由を聞く
- 依頼が来たらすぐにレビューを行う（24時間以内に終わらない場合はいつまでに終わるか連絡する）
- 実装してくれたことに感謝する
- コメント
- Must：対応必須
- Want：できれば
- Nit：改善可能な点だが改善するか否かは作者に委ねる
- Imo：私の意見では
- FLY：参考までに
- 人を辱めない（最善を尽くしている前提）
- ネガティブな言葉は使わない（人をうらまず、コードを恨む）
- どちらでもいいことについて決着をつけようとしない
ツール
- GitHubのSuggested Changeを利用する
レビューイ
PRは小さく作る
- より早く、より完全にレビューされる
- レビュアのブロッキングを短くできる
- リジェクトされた場合でも、作業の無駄が少なくて済む
- より簡単によい設計が行える
リファクタリングやフォーマットは分割する
- 新機能開発や改修のPRの中に紛れているとレビューが大変になる
デバッグ用のロギングや不要コメントは削除する
- 本番コードに含める必要のないものは削除する
