コードレビューを依頼するときに意識している２つのこと

こんにちは！
2023年10月よりクロスマートでバックエンドエンジニアとして参画している石垣です。

クロスマートに入社して早3ヶ月、爆速で過ぎていった毎日・・・
サービス・仕様理解の最中だったため、レビュイーに徹することが多かった私ですが、
今回は、この3ヶ月間、コードレビューを依頼する際に特に意識していたことについてご紹介したいと思います！

1. できるだけ詳細な概要を記載する

私は常々思うのです、コードレビューをしていただきありがとうございます！と。
それと同時に、レビューにかける時間を減らしてレビュアーの開発時間を確保してあげたい！と。
レビュアーが必要な情報を素早くキャッチし、効率的にレビューを行えるようサポートすることが、レビュイーとしての役割だと思います。
そのため、レビュアーが必要な情報を迅速に理解できるよう、詳細かつ明確な概要を提供できるように意識していました。

まず、詳細で分かりやすい概要を記載できるように所属チームのプルリクテンプレート*1を変更しました。

私が所属しているチームのテンプレートは以下になります。

## 概要

## 変更点
-

## テスト内容

## レビュワーに確認してほしいこと

## 関連URL・issue

実際に「注文一覧を取得するAPI」を実装したと仮定して、このテンプレートに沿って概要を記載してみます。

概要
PRの関連性がすぐに理解できるよう、関連するURLを明記します。
これにより、レビュワーはPRの背景や目的を迅速に把握することができます。
クロスマートではJIRAでチケット管理をしているため、いつもはJIRAのURLを貼っています。
変更点
誰が何をするための変更であるのかを明記します。
簡潔に伝えるため、箇条書きで変更点を記載していくのがおすすめです！
APIを作成した場合は、概要がドキュメントの役割を果たすようにエンドポイントやパラメーターを書くとより親切に思います。
変更点を書き出していくと、実装した内容が要件を網羅したものになっていないことに気づくことも。
テスト内容
テストの詳細な手順と内容を記載します。
レビュワーが同じ手順でテストを行えるように記載し、レビュワーが同じ条件の元でテストを行い、一貫性のある結果を得られるようにします。
レビュワーに確認してほしいこと
例えば、アーキテクチャの観点からアドバイスが欲しい、テスト内容は網羅されたものになっているかなどを書くことが多いです。
関連URL・issue
実装する上で参考にしたドキュメントや、関連するPRリンクなどを貼ります。

できるだけ簡潔に、不要な情報は書かない。
これを念頭に置いて記載しています。

2. 開発時に迷ったところはあらかじめ申告

ペアプロをお願いするほどではない軽微なもの（変数名など）
期待した動作をしているがなんか自信がないもの
ドキュメントや参考記事に書いてあったけどもっといい書き方がありそう、など

上記に当てはまる場合、私は無邪気に「自信がないです！」と自己申告しています。

実際に私が申告したものがこちら。

私はDRF歴が3ヶ月であるため、はっきり言って自信があまりありません。
この時はドキュメントを確認したり、ChatGPTに質問を投げてみたりして実装しました。
しかし、周りくどい書き方になっているのに違和感を感じたため例に倣って自己申告。
この書き方でも間違ってないけどこっちの書き方はどう？と実際にアドバイスをいただくことができました。

コードレビューはコードの品質を保つために行うものであると同時に学びのチャンスだとも捉えています。
一緒に働く先輩エンジニアからスキルを盗む絶好のチャンスです。
分からないことがあるのは、それだけ成長できるチャンスがあるということ。
ポジティブマインドでレビューをいつもお願いしています！