11
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

bravesoftAdvent Calendar 2024

Day 2

つよつよエンジニアへの道:コードレビューをスムーズにする5つの方法

Last updated at Posted at 2024-12-01

初めまして!
bravesoft株式会社でエンジニアをしている赤松と申します!
私は25卒入社なのでまだインターン生なのですが、早速実務をバリバリやっております💪
その中でいろいろなことを経験し学んだことがあったので、記事にしたためようとおもいます。:black_nib:

コードレビューでの指摘は最低限にする努力をするべし!

背景

bravesoftに入社した後、最初に行った開発での出来事でした...

自分が出したPull Requestに大量のレビュー指摘が届いていました涙
また、修正をしてもレビュー指摘が依然あるような状態でした

レビュー指摘が多いような状態だと

  • レビューイ 
    • 修正に多くの工数がかかり、開発が進まない(またシンプルに心が折れる涙)
  • レビュアー
    • レビュー自体の負荷が大きくなり、他の業務に影響する

になってしまうので、双方にとって良くありません

そのような状態に直面した私がコードレビューでの指摘は最低限に抑えるための工夫をいくつか紹介しようと思います

1. コードを書き始める前にIssue上を立て、その段階でレビューをもらうべし

タスクをもらってすぐコーディングを開始してしまうと、実装方針が大きく外れていた場合に軌道修正が大きくなってしまいます。
特に新人の場合、実装方針が想定と異なることは多いでしょう。(僕もそのうちの一人です笑)
そこでいきなりコーディングをするのではなく、実装方針をissueに書き、その段階でレビューをもらうようにしました。
この工程を経てからコーディングを行うことで、方針が大きく逸れなくなるので、Pull Requestでの指摘が少なくできます!

2. Pull Requestは細かく切るべし

1つのPull Requestで大量に変更差分があると...

  • レビュアー
    • レビュー範囲が広いので、1つのPull Requestのレビューにとても時間がかかる
    • 見落としが発生しやすくなる
  • レビューイ 
    • フィードバックを得るまでの時間が長くなり、迅速な反映が難しくなる
    • マージコンフリクトが発生しやすく、修正作業が複雑化する

という問題が起きます

そのため、1つのPull Requestの変更差分を小さくするためにPull Requestを細かく切るようにしています!
どのくらいの粒度で細かくするかで迷ったら、1の段階でそれも相談するようにしています

3. Pull Requestテンプレートを活用し、必要な情報をレビュアーに提示するべし

せっかく丹精込めて書いたコードをレビューしてもらうので、自分が実装で行った内容はしっかり提示するようにしています。情報を提示することで、自分が行った実装の品質を担保できます。
また、レビュアー側からしても情報が十分にあるとわざわざ手元でビルドして確認するような手間が省けます。

必要な情報の記述漏れがないように、毎回Githubのリポジトリを作成してすぐテンプレートを設定するようにしています!

4. Pull Requestの中にセルフレビュー項目を入れる

テンプレートの話の続きはなるのですが、私はテンプレートの中にセルフレビューの項目を入れるようにしています。

セルフレビューを設定する前はデバッグのためのロガーを消し忘れたり、warningが出たまま状態でレビューを依頼することが頻発しており、そのたびに指摘をいただいていました。

このようなケアレスミスが頻発すると、レビュアーはしょうもない指摘を繰り返すことになり、マージするのに時間がかかってしまいます。

このような問題を解消するべく、テンプレートの中にセルフレビューを入れるようにしました。こうすることでPull Requestを作成したときにセルフレビューする習慣が身につき、ケアレスミスを減らすことができました!

5. 指摘をもらったら、他の箇所でも同じことが起こっていないか確認するべし

1~4の工程を踏んでも指摘がくることはあります。

指摘の中でも同じような内容がコードの中で複数点在している場合があります。

このような場合、すべてのコードの箇所にコメントを入れてくれていることもありますが、レビュアーが見落としていたり「1か所だけコメントすればわかってくれるだろう」と思って他の箇所にはコメントがないこともあります。

これでレビューイが他の箇所を修正できていない場合、再度同じ内容の指摘をもらうこととなり、無駄が発生します。

これを解消するために、指摘をもらったら他の箇所でも同じことが起こっていないか確認するようにしています!

まとめ

今回はインターンを通じて、コードレビューに関して私が学んだことをお話ししました。

  1. コーディング前に実装方針をレビューする: Issueで実装方針を共有し、レビューを受けることで、最初から正しい方向に進むことができます
  2. Pull Requestを細かく切る: 大量の変更を一度に提出するのではなく、小さな変更単位で提出することで、レビュアーの負荷を軽減し、迅速なフィードバックを得ることができます
  3. Pull Requestテンプレートの活用: テンプレートを使って必要な情報を含めることで、レビュアーが効率的にレビューできる環境を整えます
  4. セルフレビュー項目を追加する: 自分自身でレビューをする習慣をつけることで、ケアレスミスを減らし、レビューの質を向上させます
  5. 指摘事項を他の箇所にも適用する: 1つの指摘事項を他の類似箇所にも適用することで、同じ指摘が繰り返されることを防ぎます

これらのポイントを意識することで、コードレビューの効率が向上し、双方にとって有益なフィードバックのやり取りができるようになります。特に新人エンジニアにとっては有用な取り組みだと思いますので、是非参考にしてみてください!

11
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?