コードレビュー

コードレビューの難しさ

コードレビューの難しさは、コミュニケーションの難しさ

本質的に、成果物に対する批評や批判であるため。

• 悪い例:
  • レビュー内容に含まれる指摘が、コードへの批判ではなくレビュイー自体への批判と捉えられる

そのため、コードに対する改善や指摘を、正しくレビュイー/レビュワー同士で伝え合う必要がある。

つまり、レビューにはコミュニケーションに気を使う必要がある

5大ルール

ルール①: 決めつけない

ルール②: 客観的な根拠に基づく

ルール③: お互いの前提知識を揃える

ルール④: チームで仕組みを作る

ルール⑤: 率直さを心がける

レビュイーが気をつけること

• 修正内容に関する情報を過不足なく提示すること
  • PRに書くと良いこと
    • PR自体の説明
      • PRの背景、なぜこれをやるのか
      • 関連資料、issueへのリンクなど
    • このコードによって実現されるべき状態・仕様
    • やったこと
    • やっていないこと
      • 後から見返した際にやっていないことの理由を推測しなくて良いように記述
    • 変更の前後での違い
    • なぜこのような実装にしたのかの設計判断
    • レビューで検討してほしい点
    • 動作確認手順
    • 動作確認観点
      • 変更箇所の動作や互換性など
    • その他
      • 特に確認してほしいところ、迷った点など

レビュワーが気をつけること

指摘する時

• コミュニケーション面
  • 指摘項目について、明確な根拠を示す
  • 質問する際は、「なぜそれを知りたいか」を示す

参考: 伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書