コードレビューを初めて行う人必見！やり方を1から解説！

コードレビューのやり方

まずはコードレビューの基本的なやり方を解説します。どういう手順で行うべきか、1から説明します。初めてコードレビューを行う方は、まずはこちらをお読みください。

コードを読む前に、まず「システムの仕様を把握すること」が重要です。どのような機能をもつシステムなのか仕様を把握しないと、コードのどこを指摘したらいいのか分からず、仕様通りに書かれていない箇所の指摘もできません。

また、コードレビューに慣れていない場合、仕様を頭に入れていないとコードが読み解けないことも多いです。新人のコードレビューをする場合は、新人が関わっている箇所の仕様書を読み込み、何を作ろうとしているのか全体像を確認しましょう。

仕様書を一通り理解したら、コードを一通り読んでいきます。書き方が良くなかったり、非効率な処理をしていたりする部分などがあればメモしておきましょう。

また、コードを自分の開発環境でも実行し、エラーが出ないかもチェックします。開発環境が変われば、エラーが発生するケースも多いためです。こういった地道が作業が、コードレビューでは必要です。

メモした内容を基に、問題点を口頭・Github・チャットツールなどで指摘します。また問題点を指摘する上で、参考にした資料などがあれば提示・添付すると良いでしょう。新人が問題点に関する質問をしてきたら、きちんと答えられるようにしておくことも重要です。レビューをする際は同じミスを繰り返さないよう、相手に分かりやすく伝えることを意識しましょう。

コードレビューで見るべきポイント

ここでは、コードレビューで見るべき具体的なポイントを紹介します。特にコード量が多い場合、最初から最後まで熟読するのは大変です。見るべきポイントを抑えて、そこを重点的に確認すれば、コードレビューの時間を短縮できるでしょう。1つ1つのポイントを詳しく解説していきます。

まずは、自社のコードルールにしっかり則って書かれているコードか確認しましょう。インデントやコメントの書き方など、それぞれの会社でルールが設けられているはずです。

他の会社でエンジニア経験がある方の場合、自社のコードの書き方ではなく、前職での書き方をそのまま使っているケースも多いです。そういった場合は、自社のコードルールに則っていない旨を指摘しなければなりません。レビュー時はコードが自社のルール通りなのか、確認してください。

コメントが分かりやすく書かれていないと、仕様変更を行う際や他の人に担当部分を引き継ぐ場合に苦労します。エンジニアによっては、コメントを全く書かない人や、逆にコメントが多すぎる人もいます。ソースだけでなく、コメントが上手く挿入されているか確認するのが良いでしょう。

コードレビューを行う主な目的は、「バグを潰す」であることがほとんどです。プログラマーを数年続けていると、どの部分がバグを生み出しやすいか感覚が掴めていると思います。その感覚を頼りに、バグが出そうな部分を重点的にチェックしましょう。

たとえば、if文がネストされている部分や無限ループが使われている部分、変数名が分かりにくい部分などはバグが出やすいです。また、なるべぐバグを生み出しにくいコードを書くように指示することも大切です。

コードレビューの際は、今後の仕様変更のことも考えて行いましょう。仕様変更が発生すると予想される箇所のコードは、修正部分が少なくなるよう記述するのが重要です。たとえば、同じような処理を関数にまとめるなどが該当します。後に修正箇所が多くなりそうな部分も、コメントしてあげることが大切です。

例外処理が入っていない場合が割と多いため、そこも重点的に確認しましょう。ユーザーが想定外の動作を行った場合に、プログラムがエラー文を出さないかチェックします。例外処理が入っていない場合は、例外処理を書く必要があることの旨と、書き方の例をコメントしておきましょう。

コードレビューを効率化させる方法

コードレビューは、あまり時間をかけすぎるのも良くありません。時間をかけすぎて自分の業務に影響が出てしまうことがあります。そこで、コードレビューを効率化させる方法を解説します。レビューすべきコード量が多い場合などは、これらを意識してみてください。

レビューの目的を明確にすることは重要です。たとえば「バグをなくす」「効率的なコードの書き方を教育する」など、目的はそれぞれ異なります。レビューの目的が決まれば、その部分のみに絞って効率的にチェックできるでしょう。

「自動コードレビューサービス」というものもあります。コードを入力すると、ツールがコードを自動解析してくれ、問題点をコメントしてくれます。たとえば、「Sider」は日本初の自動コードレビューサービスとして有名です。また、解析ルールをカスタマイズし、自社仕様にすることもできます。

もちろん、こういったサービスに頼り切るのは良くありませんが、要所で活用することでレビュー時間を短縮できるでしょう。「Sider」以外にも「Codacy」や「Hound」などいくつか種類はあるので、試しに使ってみてください。

レビューする箇所が多すぎる場合は、役割分担を行うことも検討しましょう。たとえば「コードが仕様書通りか確認する人」と「コードの書き方が規約に則っているか確認する人」に分けるなどです。

役割分担することでピンポイントで確認でき、レビューの質も上がるでしょう。役割分担に関しては、上司に相談してみるのが良いです。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

コードレビューの注意点

コードレビューする際の注意点も解説していきます。これらの注意点も意識しないと、新人との関係を悪くしたり、レビューの質低下に繋がったりします。ある程度コードレビューを行ってきた人も、注意点を守れていないことが多いです。どういった点に気をつけるべきか、1つ1つ解説していきます。

コードの悪いところを否定しても、その人自身は否定してはいけません。「なぜこんなこともできないのか」と、高圧的な態度を取るのも止めましょう。新人との関係を悪くしたり、相手がコードレビューを嫌いになることに繋がったりします。

悪い箇所を指摘する際は、淡々と事実のみを話し、自分の感情を介入させないようにしてください。また、絵文字などを使って柔らかい雰囲気を出すのもコツです。柔軟な対応を見せることで、レビュイーが新人でも萎縮することなく疑問点を質問してくれるようになるでしょう。あくまで「レビューするのは相手に対してではなく、コードであること」を意識するのが重要です。

悪い部分を指摘する際はなぜこのような書き方をすべきか、根拠を話すことも重要です。たとえば「コード規約に書かれているから」という説明では、相手は納得できません。

コード規約に則るとどんなメリットがあるか、分かりやすく話すことが重要です。そうすることで初めて相手は納得し、改善もしやすくなります。

また、レビューする際に参考にした本などがある場合は、それを見せるのも効果的です。「なぜそうなのか」をきちんと説明することは、コードレビューをやる側の理解度アップにも繋がります。

コードレビューをする際は、具体的な修正案も示してあげましょう。その方が相手がどのように変更すべきか分かりやすくなります。また、言葉ではなかなか伝わりにくい部分も理解させることが可能です。もちろん、具体的な修正案を示すのは時間もかかるため、できる範囲で行いましょう。

悪い部分を指摘するだけでなく、良い部分があれば褒めるようにしましょう。コードレビューを行う上で大切なのは、やる側とやってもらう側の信頼関係です。悪い部分ばかり指摘するのは、信頼関係を築く上で好ましいことではありません。

また、良い部分を褒めることで、エンジニアとしての自信がつき、レビュイーの成長速度を早めることにも繋がります。良い部分や「なるほど」と思う部分も必ずあると思うので、コメントしてあげるようにしましょう。

書き手の意図が分からない部分は、「なぜこういう書き方をしているのか」直接本人に質問しましょう。質問することで、レビュアーの読解力が不足しているのか、コードの書き方に問題があるのかが分かります。

また、レビュイーの説明力や理解力をアップさせることにも繋がるでしょう。ただし、問い詰めるような言い方はせず、穏やかな雰囲気を意識して対応することが重要です。

コードレビューはやる側もエンジニアとしての成長に繋がる

本記事では、コードレビューのやり方について解説しました。どういった手順でコードレビューを行うべきか、お分かり頂けたかと思います。

コードレビューはやってもらう側だけでなく、やる側もエンジニアとしての成長に繋がります。コードレビューを行うことで、読みやすいコードはどういった物なのか分かってくるため、自分のコードを確認する上でも役立つでしょう。

ただし、時間をかけすぎると自分の業務に支障が出るため、効率的にレビューを行うことも重要です。コードレビューを頼まれた場合は、本記事で解説したことを意識して行ってみてください。

リモートで働くエンジニアの実態やメリット、デメリットについて紹介