はじめに
こんな○○はしないでシリーズ第２弾です！
第１弾はこちら 
こんなテスト仕様書は書かないで
最近レビューをする機会が増えたので、こんなコードレビュー依頼はやめてほしいことと、自分がレビュー依頼するときに意識していることをまとめます
その１ 対応内容が記載されていない
題名だけで、どんな対応をしたのかが書かれていないケースがあります。
こちらから情報を取りに行く必要があり、レビューがスムーズに進みません。
-
タスクを振る側も作業の全てを把握しているわけではない
全員の作業内容を詳細に覚えていないため、情報を記載しておいてほしいです -
仕様漏れ確認には設計書、バグ確認には動作結果があると判断しやすい
これらの情報が揃っているとレビューをスムーズにできます -
過去の修正を遡るときにも情報があると助かる
不具合調査等のため、履歴が整理されていると非常に便利です
Point
対応内容の概要、設計書、動作確認結果を添えてレビュー依頼をする
その２ 修正箇所以外の差分があるのにコメントが無い
修正以外の対応があるのに理由が書かれていないと、
「なぜ修正したのか？」を確認するために無駄なやり取りが発生します。
-
修正箇所以外を直すと影響範囲が広がる
追加修正が他の機能に影響する可能性があるため、今修正した理由を明記してほしいです -
今修正すべきか判断が必要
緊急度や優先度を判断するために理由が必要です
Point
修正箇所以外を直す場合は、事前に確認しておく
その３ レビュー時に質問をする
レビュー依頼のタイミングで質問されると、質問に対して回答するためレビューが止まります。
回答後に再度動作確認 → 再レビューとなり、作業時間が長くなります。
-
レビューは「確認作業」なので質問対応の場ではない
疑問点は事前に解消しておくことで、レビューがスムーズになります。
Point
気になることはレビュー前に解決しておく
その４ コードの確認漏れが多い
コメントアウトの残りや誤字などのケアレスミスが多いと、
レビューの本質（仕様漏れや可読性改善）に集中できません。
-
ケアレスミスはレビューの本質ではない
レビューは品質向上のための場です。誤字や残コードは事前に排除しましょう -
「一発でレビューをクリアするぞ！」という気持ちが大事
この意識があるだけで、確認精度が大きく変わると考えています。私は「これでOKだ」と思った後、さらにもう一度見直すようにしています。レビューのやり取りが増えると双方の時間が取られたり、コメントが多いとテンションも下がります。だからこそ、1回でマージされる状態を目指す努力が重要です
！！
Point
レビュー依頼時には「一発OK」をもらう気持ちで挑む
さいごに
上記のポイントを意識してレビュー依頼すれば、
レビューがスムーズになり、双方の負担も減るのではと考えています
上記参考になれば幸いです