はじめに
エンジニアとしての経験がある程度増えてくると、コードレビューを担当することも増えてくると思います。
コードレビュー時にするべきことはたくさんあると思うので、あえて今回はコードレビュー時に "しないこと" をシンプルに３つまとめます。
これを知ることで、コードレビューを効率よく的確に行えると思います。
コードレビュー時に "しないこと" ３選
- ローカルで動作確認しない
- 「動いているからいいか」をしない
- 代わりに実装しない
慣れている人にとっては当然意識していることかもしれませんが、
詳細がとても大切ですので、できているかぜひチェックしてみてください。
1. ローカルで動作確認しない
これをやってしまうと起こる問題は...
- 非効率
とにかくこれです。
動作確認はあくまでプルリク作成者に行ってもらいましょう。
プルリク作成時のルールとして「デザインの変更はスクショ必須」「ユーザーの動作を伴う変更はスクリーンレコーディング必須」と取り決めておくと良いでしょう。
2. 「動いているからいいか」をしない
これをやってしまうと起こる問題は...
- パフォーマンス低下の原因になり得る
- 今後の開発負債となり得る
- 相手の学習機会を奪ってしまう
といったことです。
後でしようと思っていることは、することはないと思っておくと良いでしょう。
ほんの少しパフォーマンスに影響があれば、それが繰り返されボトルネックになっていく可能性もあります。
関数の命名が適切でなかったり、もっとシンプルにかけるロジックを放置しておけば、その後の開発に無駄な工数が増える危険性も含んでいます。
今取り組むことが最善だと思いましょう。
また、プルリク作成者は「今がベスト」だと思っている可能性もあるため、学習や知るきっかけを奪うことにつながります。
もっと良い書き方があるのにレビューしないことは、レビュワーの最大の罪です。
どうしても急がないといけない場合は「必ずその場で」期限を明確にしてissue化・タスク化しましょう！
3. 代わりに実装しない
これをやってしまうと起こる問題は...
- 今後のレビュー負荷が減らない
- 相手の学習機会を奪ってしまう
といったことです。
レビューされることによって、プルリク作成者たちはちょっとずつ成長していきます。
それに伴って、レビュワーのレビュー負荷は減っていくものです。
しかし、
「自分でやった方が早いな...」
「伝えるのが難しいな...」
などによりレビュワーが代わりにやってしまう場合も多いと思います。
これはレビュワー・プルリク作成者たち両方にとって大きなデメリットです。
レビュワーの負荷は減りませんし、プルリク作成者たちの学習機会を奪います。
何より、２でも記載した通り、もっと良い書き方があるのにレビューしないことはレビュワーの最大の罪です。
こちらもどうしても急がないといけない場合は、代わりに行った上で
「どうしてこの変更をしたか」
などの意図を必ず丁寧に伝え、別途プルリク作成者なりに修正してもらいましょう。
終わりに
レビューをすることは、レビュワー・プルリク作成者たちの双方にとってたくさんのメリットがあります。
今回の３つを意識して "しない" ことでそのメリットを最大限に活かしましょう！