こんにちは、 @yuki0920 です。
エンジニア歴が1年を超えたあたりから、プルリクエスト(以下、PR)をレビューしてもらうだけでなく、レビューをする機会が多くなりました。
本記事では、PRのレビュワーとして、業務で気をつけている点について記します。
前提
私がエンジニア1年目の時はPRを出すと、100や200以上の指摘をもらうことが多々ありました。 自分のレビューを受ける側としての経験から、「対応しやすかった」というレビューのポイントを抽出し、自身がレビュワーをする際に活かすことで、効率的なPRのレビューを行えるのではないかと考え実践しています。
ポイント1. 現時点の問題点の理由を伝える
「~の実装のほうが良いのではないでしょうか?」という指摘は、対応しづらいことが多いです。 なぜ現状のコードが良くないのか?がわからないためです。
そのため、現状のコードが抱える課題とその理由をできるだけ具体的に記すようにしています。
ポイント2. 提案内容をコードで示す
提案内容をコードで示すのは、レビュワーからすると自分の頭の中で描いていることをコードに落とし込むだけなので、そんなに時間をかけずにできる場合が多いはずです。 一方で、レビューを受ける側からすると、具体的なコードがないと対応方針がわからない場合でも、レビュワーから具体的なコードの提案があれば、対応方針を立てやすくなります。
私は GitHubのSuggestionを積極的に活用し、自分がより良いと思うコードを書いて、議論の足がかりとなるようにしています。
ポイント3. 断定するのではなく提案する
いくら合理的な指摘をしたとしても、断定口調で言葉使いが良くないと、指摘を受けた側は積極的に対応しづらい気持ちになります。
あくまでも、PRの提出者を尊重して、「~と対応するのはいかがでしょうか?」など、提案する風に、かつ柔らかく伝えられるように気をつけています。
まとめ
私がPRのレビュワーとして普段から気をつけている点を紹介しました。 みなさんの気をつけている点もぜひ教えていただけると幸いです。
