現業務でコードレビュアーとして認定されて多分４年近く経ちました。
様々なプロジェクトでいろんなコードをレビューしていく中で学んだことと気づいたことをまとめます。
これはコードレビューに限らず、社会人として誰かに指示をしなければいけない状況では共通する物があると思います。
（「嫌われないコードレビュー」としていますが、私が嫌われていないことと、これを実践した人が嫌われないことは保証していません）
1. どんな気持ちでコードレビューを投げてきているか想像してみる
意外と大事です。
例えば、
- 新卒入社して現場入って初めてレビュー出してる人
- CTOからのレビュー依頼
の２つでは意味が全然違うのはわかるかと思います。
前者であればなにかヘマをしていないか、変なミスしてたら怒られるんじゃないかみたいな気持ちになっていてもおかしくはありません。
あなたの会社がまともなのであれば、この場合は指導、育成の意味も込めてレビューをしてあげる必要があります。
CTOからのレビューはサラっと且つ丁寧に返しましょう。(笑)
2. 曖昧な指示をしない
コードレビューだとやってしまいがちですが、「結局どうすればいいのかわからない」指示はNGです。
NG）規約違反です。
OK）メソッドの引数のカンマの後には半角スペースが一つ必要です。（コード規約）
GitHubやAzure DevOpsではSuggestion機能もあるので、併せて使うと良いです。
3. 根拠のない”指示”はなるべくしない（提案はOK）
その修正をするに足る理由がない修正は指示しないほうがいいでしょう。
レビュアーは基本複数人いるので、レビュアーによるバラつきが多くなってしまいます。（ある程度は仕方ないですが）
NG）これはアンチパターンなのでXXをYYに修正してください。
OK）公式ドキュメントによればこれはアンチパターンなのでドキュメントを参考に修正してください。（URL）
ただし、「なんか微妙だな～」と思うシーンは、プログラマであればあると思います。
この違和感は経験に基づいたもので、無視するにはもったいないので、「私はXXXXだと思うのですがどうですか？」といった形で、議論を展開し、レビュイーとの間でコミュニケーションを取るのがいいです。
4. キツい言い方にならないように気をつける
上２つのOK例は実はあんまりOKではなくて、結構言い方がキツいです。
CTO相手等であればまあ別にいいんですが、1.で述べたように相手が新人等であればコードレビューを出すのがメンタル的に嫌になってしまうかもしれません。
コードレビューは中長期的に生産性を上げるための活動なので活発に行われるべきです。
なので、レビュアーもレビューイも気持ちよく完了できるように、なるべく物腰やわらかに書くのがいいです。
「コードを否定しない、提案する」が一番いいやり方だと思います。
NG）
ネストが深いので読みづらい。早期returnするといいです。
OK）
このメソッドですが、早期returnすることで可読性を上げられるかと思います。
ガード節と言ったりもするので調べてみてください。