コードレビューがちょっと楽になる（かもしれない）話

こんにちは

こんにちは！KINTO ONE開発Gの中川原です。
参加しているプロジェクトではフロントエンドエンジニアとしてNext.jsとTypeScriptを用いて開発を行なっています。

今回はチームで開発を進める上で欠かせない、コードレビューについてのお話です。
私がコードレビューをする際に気を付けていることをレビュイー、レビュワーそれぞれの場合に分けてご紹介したいと思います。

レビュイーとしてコードレビューを依頼するとき

早速本題に入っていきます。
まず自分がプルリクエスト（以後「PR」と記載）を作成してコードレビューをしてもらう際に気を付けていることを2点ご紹介します。

1. コミットのコメントを分かりやすく記載する

分かりやすく簡潔に書こうと意識することで自然と適切な粒度のコミットになると考えます。
必要があれば2行目以降に補足説明や参考リンクを記載します。
また、コミットメッセージに絵文字のprefixを付けています。視覚的にどんなコミットなのか分かりやすくなるのと、絵文字に意味を持たせているので必然的に一つのコミットに修正を詰め込みすぎるのを防ぐというメリットがあります🌈

以下は実際にFEチームで使用しているコミットテンプレートです。

# ==== Format ====
# :emoji: PBI_id Subject
#
# Commit body...

# ==== Emojis ====
# 🐛  :bug: バグ修正
# 👍  :+1: 機能改善
# ✨  :sparkles: 部分的な機能追加
# 🎉  :tada: 盛大に祝うべき大きな機能追加
# 🎨  :art: 見た目の追加・修正
# 🔧  :wrench: 機能の修正
# ♻   :recycle: リファクタリング
# 🚿  :shower: 不要な機能・使われなくなった機能の削除
# 📝  :pencil: ドキュメントやコメントの追加・修正
# 🚚  :truck: ファイルの移動
# 👕  :shirt: Lintエラーの修正やコードスタイルの修正
# 🤖  :robot: テストの追加・修正
# 🚀  :rocket: パフォーマンス改善
# 🆙  :up: 依存パッケージなどのアップデート
# 👮  :cop: セキュリティ関連の改善、Warningの解消

テンプレート作成にあたり、以下記事を参考にしました。

• atom
• Emojiで楽しく綺麗なコミットを手に入れる

そして実際のコミットがこちら👇

そのコミットを単体で見た時に何をしているか分かるように意識しています。

2. テンプレートを利用してPRを充実させる

FEチームではPRのテンプレートが用意されています。
レビュワーがレビューをする際にどのような観点でチェックすれば良いのかが明らかになるため、レビュー効率の向上が期待できます。

以下は実際に使用しているテンプレートです。
JIRAを使用してタスクをチケット管理しているためそのチケットへのリンク、このPRで対応すること・しないこと、それによって何ができるようになるのかなどを記載します。

## チケットへのリンク

* https://example.com

## やったこと

* このプルリクで何をしたのか？

## やらないこと

* このプルリクでやらないことは何か？（あれば。無いなら「無し」でOK）（やらない場合は、いつやるのかを明記する。）

## できるようになること

* 何ができるようになるのか？（あれば。無いなら「無し」でOK）

## できなくなること

* 何ができなくなるのか？（あれば。無いなら「無し」でOK）

## その他

* レビュワーへの参考情報（実装上の懸念点や注意点などあれば記載）

テンプレート作成にあたり、以下記事を参考にしました。

• Pull Requestのテンプレートを作って効率よくレビューしよう！

上記に加え、必要に応じて情報を付け加えるよう意識しています。
例えばバグ対応のPRの場合は原因も合わせて記載したり、UIの変更がある場合は修正前後のスクリーンショットや動画を添付したりします。
それによりPRの意図やコードの理解がスムーズに進むと考えるためです。

レビュワーとしてコードレビューをするとき

続いては、反対にチームメンバーのPRを見る際に気を付けていること3点についてです。

1. PRの概要を理解する

前段でテンプレートを使用してPRを丁寧に書くとお話しました。
なのでまずちゃんと概要を読みます。
背景や意図、ここではやらないことを理解した上でコードを見た方がレビュー効率も良く、的外れな指摘をしないで済むと思っています。

2. ローカルで確認する

PRの変更ファイルからもコードは確認できるのですが、以下の理由から挙動に関わる修正の場合はローカル環境にブランチを落として確認するようにしています。

• 挙動・見た目の確認をするため
• コード全体を見るため

挙動・見た目の確認をするため

実際に自分で動かすことで期待する挙動・見た目となっているかを確認するほか、変更の目的や意図を理解することができます。
コードだけ見てもなぜその変更に至ったかが理解できていないと適切なレビューができなかったり、今後自分がその箇所に手を入れる際にデグレしてしまう可能性があります。
なのでできるだけ自分の目で処理を追いコードを理解するようにしています。
また、シンプルに対応漏れの場合や、その修正により別の箇所に影響が出てしまった場合に事前に気づくことができるので思わぬバグの発生防止にも繋がります🐛

コード全体を見るため

処理を理解するのはもちろん、「同じような処理をしているからこことここはまとめられそう」など、最適化ができそうな箇所に気づくことができるかもしれません。

3. レビューコメントにラベルを記載する

コメントの先頭に[imo]や[nits]などのラベルを記載することで温度感が分かるようにしています。（まだ結構書き忘れるので徹底したい）

おしまい

長々と書きましたが、まとめると自分がレビュワーの場合に何が書いてあるとレビューしやすいか、レビュイーの場合にどのようにレビューしてもらえると助かるかを意識しています。
今後の課題としては丁寧さだけでなくレビューの速度も意識していくことと、自分なりの観点表を作成しレビュー品質のムラをなくしていくことだと考えます。
そのレビュー観点についてチームで認識共有をしてみるのも面白そうだなと思いました。

この記事が少しでもコードレビューのヒントになれば幸いです。
最後まで読んでいただきありがとうございました！