💻

新人エンジニアが先輩のコードをレビューする時に意識していること

2 min read

この記事では新人エンジニアの私が経験年数何倍もの先輩が作ったPull Requestに対してレビューするときに意識していることを書いていきます。

お前is誰

まず、前提として私のエンジニアとしての立ち位置を軽くご紹介させてください。

  • 大学4年生、22卒
  • 実務のアルバイトを4ヶ月ほど
  • 領域はWebの開発(frontend, backend)

駆け出しに少し成功したエンジニアです。

なおこの記事では都合上、

  • レビューする人(私)
  • レビューを受ける人(先輩)
    という記述になるところがあります。

(ちなみに会社の人たちはめちゃめちゃ優しいです。語尾に「!」をつけてくれます。)

職場のCI/CD環境

  • 開発はdevelopブランチからブランチを新たに切って行う
  • 基本的にエンジニアのうちの一人がApproveを出せばdevelopブランチにマージする
  • GitHub ActionsでCI/CD

一人がApproveすればマージ可能なので責任重大です。。

コードレビューの経緯について

入社当初、私は先輩にレビューをいただく形で、他のエンジニアが出したPRには目を通す程度でコメントとかもしていませんでした。
私にはメンターがついてくれているのですが、入社から4ヶ月くらいが経ったタイミングの1on1で「一つレベルアップするためにもコードレビューをしてみないか?」と言われました。

すぐさま「はい!やります!」と言ったは良いものの、何年もの経験を積んだ先輩のコードにケチをつけるわけですからどうしようかという状態でした。

不安があることを先輩に伝えると、
「最初のうちは僕もよくわからないけど動いてるからOKみたいな感じだったよ笑 本番デプロイ前にはみんなで動作確認するから気軽にやると良いよ」
と言ってもらえました。

私がコードレビューでやっていること

本題です。
先輩のコードをレビューするに当たって私が意識していることについて挙げてます。

  • 質問をするという意識でやる
  • 自分の環境に落としてきて動作確認をしてみる

一つずつみていきます。

質問をするという意識でやる

いきなり「ここはこう書く方が良いかもです!」みたいなクリティカルな指摘はできませんし、ちょっと緊張します。
なので最初は「コードについてわからない部分があるので教えてください」という感じでコメントをするようにしました。

ここで気をつける点としては「自分としてはこういう理解なのだが、あっているか」という形式でコメントすることです。
これだと先輩としては「あっている」or「違うから説明する」という二択になり、コミュニケーションコストを減らすことができます。

「これは何をやっているのですか?」みたいな感じだと1から説明しなくてはいけないので大変です。

わからない部分は自分なりの考えを持った上で質問をするという意識でいるとレビューをしやすくなります。
またここまではわかって、ここからわからないというのが自分の中で整理されるので、レビューをするだけでわからない部分を解消できるというメリットにもなります。
とても良い!!

自分の環境に落としてきて動作確認をしてみる

フロント側のPRでUIが変わる系のタスクをレビューする場合、先輩もPRにbefore/afterで画像やgifを載せてくれるのですが、一応自分の環境に落としてきて試してみることも多いです。

基本的に一人で実装していると思わぬバグが混入することがあるので、大事だと思っています。

流れは下記のようになります。

  1. GitHub上で自分がレビューする対象PRのブランチ名を見つける
  2. git fetch -p コマンドでローカルにリモートの最新を持ってくる
  3. git checkout <対象ブランチ名> で対象PRにcheckoutする
  4. localで立ち上げ動きを確認する

この流れで自分のPC上に先輩が作ったブランチを持ってきます。
タスクの仕様を確認して、影響がありそうな画面にいき、動きを確認します。
ここで意図していなさそうな動きがあることもあるのでレビューとしてコメントしてあげます。

これだけでもレビューできるポイントが見つかると思います。

意外と指摘できるポイント

様々なコードをみてきて「あ、このパターン意外と指摘しているな」というものがあったので、まとめておきます。
これは私にも言えることなので。

  • 重複コード
  • 条件チェック

重複コード

これは結構見つかります。
他の箇所でも同じような記述をしていたり、すでにコンポーネントとして持っていたりする場合は指摘してあげると良いでしょう。
新機能などがバンバン立ち上がると、先輩も全てのコードをみれているわけではない可能性があります。
新たに作ったコンポーネントの存在などを教えてあげるという意味でも重要だと思います。

条件チェック

プログラムの上の方で早期リターンをしている場合などに該当処理が走らないという場合もあります。
プログラムの発火条件を全部絞り切れていないと起こることが多いです。
バグの原因にもなるので指摘できると良いかもしれません。

さいごに

コードを読むことはとても勉強になります。ましてやコードをレビューするという立場になるとより真剣に読むようになるので尚更です。
気づくことがあったら追記していこうと思います!!

「これも気をつけた方が良いよ!!」などのコメントなど大歓迎しているので、ぜひコメントしてください!

https://twitter.com/graaandBlue

Discussion

ログインするとコメントできます