はじめに
コードレビューは、チーム開発をしていると避けて通れないプロセスです。
レビューしてもらう立場は「コードの意図が伝わるだろうか」とか「厳しいコメント返ってきたらどうしよう」といった不安があると思いますが、レビュアーの立場では、「コメントの意図が伝わるだろうか」とか「コメント読んで凹まれたらどうしよう」といった不安があります。
チームに軋轢を生むことなく、コメントをポジティブに受け止めてもらえるように心がけていることを紹介します。
よい書き方の根拠を示す
コメントにはその根拠を添えると理解、納得をしてもらいやすいです。
「IDEがコードインスペクションで別の書き方を提案している」「書籍の〇〇ページにこう書かれている」といった情報はコメントの妥当性を補完してくれますし、角が立ちにくくなります。
できるだけポジティブな言い回しを使う
改善の余地があるときは、「ダメ」「違う」などのストレートなネガティブワードは避けながら伝えます。
(例)
- 「無駄な処理」→「処理コストを下げられる」
- 「この条件の考慮が足りない」→「この条件も考慮するとよりよくなる」
口頭で補足する
文字だけだと厳しい伝わり方になりそうであれば、コメント画面を一緒に見ながら指摘事項について説明します。大抵の場合空中戦を回避できます。
好き嫌いのコメントは相手に選択の余地を残す
書き方の良し悪しではなく、好き嫌いを伝えたくなるときもあるでしょう。
レビュアーが自身の好みを反映させようとしているコードは、書いた人が好ましいと思って書かれたものかもしれません。
「自分はこういう書き方のほうがいいと思うが、あなたはどう思いますか？」という伝え方をすれば、「自分はこのままがいいと思う」とレビュアーの意見を却下するハードルも下がりますし、レビュアーは却下されても精神的ダメージが少なくて済みます。
よいところは伝える
よいと思ったところは、どんな点がよかったかを伝えると、同じような書き方を続けてもらえます。
コメントの指摘を受けてよくなったところは、よくなったと伝えると、同じような指摘が減ります。
おわりに
コードは後からでも修正できますが、一度悪くなったチームの雰囲気を修復するのは容易ではありません。
チームのパフォーマンスにも影響しますので、レビューコメントの書き方に少しだけコストをかけるのも一つの手段ではないでしょうか。
他者のアウトプットには敬意を払い、意見を述べるときは謙虚にいきたいものです(自戒)。