多くのweb業界では、新人、ベテラン関係なく他人のレビューをする機会があると思います。
僕も最近は少し慣れてきたものの、最初のころはどのようにレビューをすればいいのか本当にわかりませんでした。
また、レビューを依頼するときもちょっとしたミスで先輩の時間をよく奪ってしまったものでした。
ですので、数ヶ月前の自分と比較して今意識していることや今後もっと力を入れていきたいレビューのポイントについてお話します。
コードレビューを依頼するときの確認項目
まず、コードレビューをしたことがない人にとっては、ベテランの人から見ると「そんな確認不足するの？」と思うくらい簡単な見落としをしてしまいます。（というか自分がしていました）
コードレビューを依頼するだけなのに、ミスなんてあるの？と思われるかもしれませんが、最初はレビューを依頼するだけでも思わぬミスをすることも少なくありませんでした。
そんな数ヶ月前の自分から意識したことを書いていきたいと思います。
コミットログをキレイにする
まず、ありがちなのがコミットのコメントを適当にしてしまうため、後で見直したときにどのような動作をしているのかわからないという点です。
個人で開発をしていたらいいかもしれませんが、誰がどのような処理を加えたのか明確にしたいチーム開発においてはコミットログをキレイにすることは大前提と言えます。
コミットログをキレイにしていれば、バグが発生したときにもどの変更によって、そのバグが発生したのか見当がつきやすくなります。
他にも、顧客の要望による急な仕様変更、他のブランチに一部の機能を持ってくる、gitワークフローの運用がしやすくなるなどといったメリットも考えられます。
最初はどのようなまとまりでコミットをすればいいのかわかりませんが、徐々に試していく中で最適なコミットの単位を見つけられるようになります。まず、最初に意識したいポイントと言えるかもしれません。
余計なコードを混じらせない
必ず自分のPull Requestを確認した上で余計なコードが混じっていないかどうかを確認するようにしましょう。
不要な改行やエディタのコードフォーマッターの設定によってコミットに余計なコードが混じってしまうことがあります。
基本的にはコミットには自分が追加した機能以外のコードを入れてはいけません。余計なコードが混じっていれば、それだけ汚いコミットを許してしまうことにもなりかねません。
自分のPull Requestを見て、自分が想像したコードのみが反映されているかどうかを確認していきたいものです。
Pull Requestのマージ先を確認する
こちらは正直僕だけかもしれません笑
gitワークフローでは、基本的に各種作業をしたfeatureブランチはdevelopブランチにマージすることになります。
しかし、githubのデフォルト設定ではmasterにマージ先が向いてしまいます。(ターミナルなどからpull-requestを作れば別ですが)
そのままレビュー依頼を出してしまうと…当然ですがマージ先を修正するようにコメントが返ってくるわけです。
しかし、これくらいは自分でも確認できる項目なので、できれば指摘を受ける前に修正しておきたいですね。
最新のmaster(develop)でrebaseされているか確認する
こちらもチーム開発であれば、いつの間にか新たにブランチがマージされていたというケースもありえます。
github上でコンフリクトが起きているかどうかを確認することはPull Requestのページから見れますが、最新のmasterでrebaseされているかを見ることはできません。
したがって、自分が書いたコードは最新のmasterにrebaseしたような環境でも正しく動作するのか？をきちんと確認することが、バグの少ないコードを書くための一つの方法と言えるでしょう。
こちらもレビューの依頼を投げる前にぜひとも確認しておきたいものです。
コードレビューをするときの心がけ
特に駆け出しのエンジニアだとコードレビューなんてできない！と思いがちです。
やはり、自分よりもスキルが高い人のコードをレビューするとなると気持ち的にも「自分に指摘できるだろうか」という疑問があるのは当然とも言えるでしょう。
しかし、どれだけ自分よりも高いスキルを持ったエンジニアでもミスは起こりますし、むしろコードを読む力が弱いからこそ「わかりにくい」「わかりやすい」コードを認識することもできます。
ですので、ぜひ自分の指摘が的外れかどうかを意識することなくレビューしていきましょう！
コードから動作を理解する
多くの場合、新人がレビューすることの目的の一つとして書かれたコードと動作を1セットで理解することも含まれます。
「この動作をするのはこういうコードが書かれているからだ」という積み重ねがあると自分がプログラムを書く際の引き出しが増えることにも繋がります。
また、きちんと理解していれば自然と書き方を盗むことができるので、プロジェクトにおいても規約にあったコードを記述することができます。
そもそもコードを理解することが難しいという意見もありますが、それは”自分の理解不足”か”本当に読みづらいコード”のいずれかです。
理解不足であれば、Pull Requestの説明をしっかり読んだ上でコードを書いた人に聞いてみるといいでしょう。
ただ、書いてあるコードが読みづらいコードである可能性もあり、その場合にはどこで理解が止まっているのかをきちんと見極めることが大事です。
理解しにくかった箇所を指摘するだけでも、意味があるので、とにかく理解できるまで聞くという姿勢が重要かと思います。
質問する
上記でも少し触れていますが、わからないことを放置しないことが大事です。
わからないからといって放置してオッケーとしてしまえばレビューする意味もないですよね。
何回もレビューを繰り返しているうちにプロジェクト全体のコードが把握できるようになります。そしてそのためには、1つ1つのレビューでしっかりコードを理解することが大切なのです。
違うかもしれないけど、思い切って質問するのもレビューにおいては重要な心構えと言えるでしょう。
設計通りに作られているか
これは徐々にプロジェクトに慣れてからの話になりますが、どのような開発でもコーディング規約や採用した設計があります。
わからないなりにもコードを読み、設計方針とにらめっこをしていると設計方針を確認しながら実際のコードを見る習慣が身につきます。
設計に合ったコードを見ていると自分がコードを書く際にも設計を意識したコーディングを徐々にすることができるようになるでしょう。
自分が設計に沿ったコードを書けるようになるにつれ、レビューを依頼されるときも「こっちのほうが設計方針に合っているのでは…？」というシーンが出てきます。
コードを読むことはときにコードを書くこと以上に効果があるものです。
どのような設計方針でどのようなコードが書かれているのか見て自分のスキルアップにつなげていきたいものですね。
まとめ
今回は、新人がコードレビューをするにあたって考えたいことについてお話していきました。
コードレビューは特にエンジニア初期において自分のスキルアップに不可欠な要素と言えるでしょう。
自分の数ヶ月前と比較して意識しているポイントについてお話ししましたが、自分なりのコードレビューで意識することを考えていくことも一つ重要なのかなと思います。
