コードレビューでコメントする際に意識している5つのこと

いつもコードレビューするとき、以下の点を意識しながらコメントしている。

特に、コードに対する指摘は、人格否定と捉えかねないので、なるだけ「実装者が否定的に捉えない」「納得感を持って受け止めてくれる」コメントを意識している。

主観で決めつけない

誰しも、「自分の考えが正しい」と思いがちなので、自分が理解できないコードや指摘点を見つけると即座に指摘したくなる。

「これだとエラーになります」

「この書き方は可読性が悪いです」

のように。

ただ、実装者は全力でこのコードを実装してくれたのだ。

今見ているコードのように作られた裏には、何かしら実装者が考えたこと、背景があるはず。

それを無視して一方的に自分の考えだけを押し付けても、指摘を受けた側は納得できないと思う。納得できないまま、ただ言われたから、言われた通りに修正しただけでは、同じことがまた繰り返される。

従って、実装者がなぜこのように実装したのか理由が分からないときは、「○○のようにした方が良いと思うのですが、こうした背景とかあったでしょうか？」のように、まずは背景を聞くようにしている。

「○○のようにした方が良いと思います」❌

「○○のようにした方が良いと思うのですが、こうした背景とかあったでしょうか？」⭕

修正を依頼する場合は、その理由を添える

あくまでも、指摘を受けてそれをコードに反映する主導権は実装者側にある。

なぜ、指摘を受けたように修正した方がいいのか、理由が分からなければ、実装者は納得できないし、その修正を受け入れるべきか判断がつかない。

例えば、

window.location.reload();copy

こちらのコードに対して、

「リロードする必要はないので、こちらのコードは削除してください」❌

「画面全体再読み込みするよりも、最小限の描画で、リロードは無い方がパフォーマンス&ユーザー体験的にも良いと思うので、ここ無くても良いと思いますがどうでしょう？」⭕

のようにコメントしてみると、実装者側の納得感も違ってくるのではないかと思う。

Goodな点をコメントする

• ナイステストコードです！
• 早期リターンいいですね！
• コメントアウトで補足してくれて助かります！

のように、良いと思った点は、どんどんコメントしていくようにしている。

修正を依頼される、「マイナス」のコメントだけではなく、良いコードは称賛する「プラス」のコメントも少しは入れるべきだと思う。

実装者も、「このやり方で合ってるんだ⭕」と、自信にも繋がるので。

「提案レベル」をmust, should, betterに分ける

実装者に対して、「これは致命的なバグを引き起こすので必ず修正してほしい」「これは余裕があれば取り入れてほしい」という意図が伝わりやすくするため、また、可視性も上げるために、ラベルを付けてコメントするようにしている。

• [must] 対応必須。対応するまでApproveしない
• [should] 余裕があるなら対応してほしい
• [better] 対応しなくても良いが、長期目線では対応した方が好ましい
• [imo] In My Opinion. 個人の意見なので対応するかは実装者に任せる

LGTM画像を添付する

最後は個人的に行っていること。

日々大変な開発業務の中で、少しでも気持ちがフッと緩むような、嬉しい気持ちになってもらえるよう、LGTM(Looks Good To Me)画像を貼るようにしている。

私がよく使っているLGTM画像サイトはこちら。

LGTMoon - 最もシンプルなLGTM画像ジェネレーターLGTMoonは、世界で最もシンプルなLGTM画像ジェネレーターです。GitHubでプルリクエストをレビューしたとき、Lolgtmoon.herokuapp.com