🙏

コードレビューを受ける時に意識している4つのこと

2022/12/28に公開

今年は大規模なチームでのアプリの開発に携わらせていただき、その中で自分がレビューを受ける時に意識していたことを書いていきます。
レビューを受ける時に一番意識しなければいけないと自分が思っていることは、「レビュワーにレビューで無駄な時間を使わせないこと」です。
自分だけでなく、レビュワーも忙しい中で自分のPRをレビューしていただくことになるので、まず第一に考えるべきことはレビュワーの時間です。
これから、個人ではなくチーム開発にjoinする方などは少しだけ参考になるかもしれません。

セルフレビュー

PRを出してレビュワーをアサインする前に、もう一度自分自身でセルフレビューを行なっていました。
セルフレビューを行う理由は、レビュワーの負担を少しでも減らすためです。
チームで開発をする中で、自分だけじゃなくて他の人もそれぞれタスクを持っていて、みんな忙しいのでしょうもない自分のミスをセルフレビューを通して改善することで、レビュワーがもっと本質的な部分についてだけ気を配ってレビューをする事ができるようになります。
また、ちゃんとセルフレビューをやってみると意外と「ここはこっちの書き方の方がいいな」とか「仕様通りになっていない」とか色々発見する事ができるので、一度PRを出してレビュワーをアサインする前に、セルフレビューを行うことは必ず行なっていました。

自分は、いつもタスクに取り掛かる前に、Notionにセルフレビューする項目を並べていって実装が完了してPRを出す前に、そのNotionの項目一つ一つにチェックをつけていって、確認するようにしていました。
例えば「テストケース」を全部並べて、そのケースをちゃんと全部網羅しているかどうかの確認をしたり、仕様書を自分の中でまとめて、それをもう一度見直してみてちゃんと、意図した実装になっているのかの確認をしたりしていました。

その実装をちゃんと理解しているかの確認

自分が一番最初にやってしまいがち(今でも気を抜くとそうなってしまう)だったのが、参考となる既存の実装をコピペしてしまうことです。
既存の実装を参考に新しく実装を付け加えることは、別に悪いことではないと思っています。
ただ、既存の実装を参考にする時に、「どういう意図でこの実装がされたのか」をちゃんと理解して自分の中で落とし込まないと、なんとなく動くものを作ってしまうことになります。
この状態でレビューを受けると、「なぜこの実装をしたのか?」という問いに対して、自分でうまく説明できず「なんとなく書きました」という答えになってしまいます。
この状態は、自分の中は最悪の状態だと思っていて、なので既存の実装を参考にするのであれば「どういう意図でこの実装がされたのか」を理解して実装することで、レビューを受ける時に良い議論ができるようになると思います。

自分は、レビューを出す時に参考にした実装を該当箇所にコメントで必ず載せるようにして、「この部分はこうだからこの実装を参考にした」ということを示すようにしています。
また、変更が大きいファイルには「なぜこの実装をしたのか」をコメントで加えるようにして、自分が実装した根拠を示すようにしています。

PRの内容をしっかり書く

PRを出す時に、対応した内容だけでなく関連するリンクや対応した背景などをできるだけ詳しく書くようにしていました。
これは、先輩エンジニアのPRを見た時に自分もやらなければいけないと強く思って始めました。
具体的には、自分は以下の6つをPRのコメントで示すようにしています。

  • 概要
  • 具体的な対応内容
  • 実装背景
  • 関連リンク
  • 補足
  • (UIの部分の変更であればスクショ)

まずは、「概要」このPRについてざっくり書きます。
次の「具体的な対応内容」で、具体的にどの部分を変更してその結果どういう変化が起こったのかを書くようにしています。
「実装背景」では、そもそもなぜこの対応をしたのかを説明するようにしています。ここでは、例えば「デザインの変更」であれば、その変更に至った経緯を書いたりその議論がなされていたSlackのリンクを貼ったりして、実装に至った経緯を書いています。
「関連リンク」では、参考にした実装やFigmaのリンクなどを載せるようにしています。
「補足」では、今回の変更の中で特に注意して見てほしい部分について書いたり、機能の実装の途中であれば「次のPRで変更する予定」の部分についての説明を書いたりしています。
最後の「スクショ」の部分はUIの変更があった場合だけ、before afterでUIを載せるようにしていました。

これらの事を意識してPRのコメントを書くと、レビュワーがコメントを見ただけで「どういう変更をしたのか」についてや、「そもそもなぜこの変更をしたのか」が伝わり、レビュワーのレビュー時間短縮にも繋がると思うので、自分はできるだけ詳しくPRのコメントを書くようにしています。

絵文字を使う🫰

これは、やってもやらなくてもどちらでもいいのですが、コメントをする時などに自分は絵文字をよく使うようにしています。
絵文字があった方が、テキストだけよりもなんとなく明るい雰囲気がして自分は、そっちの方がいいのでよく使うようにしています。

質問があった時などは🤔とか👀を使うようにしたり、PRでapproveされたら💚を絵文字で付け加えるなどして、あんまりうざくないくらいに使っています。

最後に

今回は、自分がレビューを受ける時に意識していることについて書いてみました。
自分のことだけじゃなくて、レビュワーの時間を考えて、PRを出すことをこれからも意識して開発していきたいと思います。

Discussion