私はキャリアの中でシステム会社やゲーム会社、AIの会社などを経験してきましたが、開発を行うほとんどのチームではコードレビューを行っていました。振り返ってみると私自身は致命的な指摘を受けたことはなくてレビューが怖いという印象を持っていません。ゲーム会社時代のCTOのコードの書き方にかなり影響を受けているので、比較的まともなコードが書けているのか、もしくは私が怖いから言いにくいのかもしれません…。

ただ、人のレビューを見ていると、かなりきつい言葉でコメントを書いていて人格攻撃に見えてしまうものや、逆にレビューを受ける側の人がスキルの高い人だと不安なコードでもノーレビューでApproveされてしまうものなど、コミュニケーションが邪魔になって正しいレビューになっていない場面を見かけます。これではレビューが怖いという人の意見もうなずけます。いずれにしろ、人が人に対して行うものなので指摘する場合も表現に思いやりが必要です。でなければレビューに出すことが精神的な負担になってしまい、隠れてコミットするという状況を招きかねません。正論だけが正解ではないのです。

そこで、私が３年前、今の会社に入社したときに書いたコードレビューの草案をここに載せておきます。↓

コードレビューの目的

まずコードレビューの目的を全員が理解する。これはプロダクトだけではなく個人にとっても有益。

• プロダクトの品質担保
• 自分の担当以外のコードの理解
• チーム全体のスキルアップ
  • レビューを繰り返すことで注意すべき点などが共通認識としてチーム内に蓄積されていく
• 個人のスキルアップ
  • レビューする側・される側ともに別の人の書き方や考え方を知ることは重要

レビューする人とされる人との関係

• レビュワーは偉くない
  • コードを書いた人（=実際に行動をした人）に敬意を払う
• コードを書いた人は、レビュワーが自分よりもそのコードを理解していないと意識しておく
  • コードを書いた人は見てほしいポイントなどを簡潔に説明できるようにしておく

円滑にレビューをするために

• レビューを出す際の精神的ハードルがなるべく低くなるような空気をみんなで作る
  • 人格攻撃と受け取られるような表現は避ける
  • 杓子定規になりすぎない
• ツールで余計な手間のかかるレビューが減らせるなら依頼の前に導入
  • コードの自動整形
  • typoチェック
• 自分よりスキルが上だと思う人が書いたコードでも指摘箇所があれば躊躇しない
  • 指摘した結果、それが間違っていても良い
    • 指摘された人はそれを攻撃しない、議論する
• 指摘箇所=修正箇所ではない
  • 指摘が間違っている場合もある
  • 議論が重要
  • レビューがプロダクト進行のボトルネックにならないように重要でない指摘は ”場合によっては” 対応しない

やらないこと

• コードフォーマットの個人的な好き嫌い
  • チームがとりきめたコードスタイルから外れている場合は除く
  • パフォーマンスなどの観点を含んでいる場合は除く
  • 参考程度にアドバイスするのは良い
  • やるなら自動フォーマットのライブラリとか入れてCIで弾く

さいごに

ぜひこの草案をレビューして、こうしたほうが良いというのがあったらコメントください！

元の記事へ