今回は『駆け出しエンジニアのレビューについて』です。

新卒エンジニアになって、1 ヶ月ほど経ちますが、まだまだコードが読めない…。と痛感する日々が続いています。

新人のコードを GitHub で先輩方にレビューしてもらっています。（レビュー対応だけでもすごい量!!）

一方で、先輩エンジニアが機能改善などをコードも GitHub に上がり、チームメンバーにレビューが飛んできます。

優しい先輩エンジニアたちは新人エンジニアも“一人のチームメンバー”として捉えてくれているようで、レビューを降ってくれる。

多くのチームの場合「レビューメンバーのうち〇人が approve したら merge していい」みたいなルールってありますよね。

果たして、コードを正確に理解できない新人エンジニアはレビュー依頼があれば、どう対処したらいいのでしょうか。

僕もこの 1 ヶ月くらい結構悩みました。

主に 3 択あるかなと思います。

1. 率先してレビューする
2. できないと判断して、レビューしない
3. 一部レビューする

結論、⓷ で落ち着きました。

一部というのは、自分ができる範囲でレビューする。ということで、最低限できることとしては『動作確認』。

⓶ は多くの新人がやってしまいそうです。（僕も最初これでした。）

ただし、先輩のエンジニアのコードは見た方が勉強になるし、せっかくレビュワーとして追加してくれているのだから、レビューしないというのも、申し訳ない。

レビューを怠っていると、自分のサービスやプロジェクトの進捗状況がわかりにくくなってきたりします。

なので、⓷ で最低限「動作確認は OK でした！」みたいなレビューをすると、かわいいかなーと思います。

最初のうちは、雰囲気で approve はやはり良くないので、細かいコードの漏れや影響範囲は先輩エンジニアに任せておいて、自分にできる範囲でレビューした方がいいですよね。

経験を積んでいく過程で、少しづつコメントを通じて、レビューすればいいのかなと。