最近聞かれることがあったので、自分がセルフレビュー時に意識していること・観点を言語化しておこうと思いました🙋♀️
※以下、「Pull Request」を「PR」、「Merge Request」を「MR」と記載します。
セルフレビューとは
他の人にレビューを依頼する前に、自分でレビューを行うことです。
自分でレビューを行い、気づいた点はレビュー依頼前に対応することで、PR/MRの精度を高めることができます。
精度が高いと指摘箇所が減るので、結果的にレビュアーや自分の負担を減らせたり、マージまでの時間が短くなったりします👍
セルフレビューのやり方
使用するツールは人それぞれかと思いますが、変更の差分を確認できるものをおすすめします。
私の場合は、GitHubやGitLab上でPR/MRを作成する時、まずはDraft状態にして、そこでセルフレビューを行なっています。
セルフレビューする時に意識すること
PRを自分のものとは思わないこと🙅♀️ です。
他の人のPRをレビューするつもりで確認します。
主観的だとどうしても見落としが発生したり、視野が狭くなります。
客観的に自分のコードを確認することが大切です。
あと、焦りも抜け漏れを生むので、「早くPR出したい!」という気持ちがもしあったとしても、ぐっと抑えて落ち着いてやりましょう。
セルフレビューする時の観点
超基本的なこと
- 不要なファイルはコミットされてないか
- 不要なログはないか
- タイポ(綴り間違い等)はないか
バグがないか
- 既存処理に影響はないか(特に共有コードに変更を加えた場合など)
- テストは通るか
- エラー発生時の処理もカバーできているか
- イレギュラーな動きをする場合がある値(文字列なら空文字
""
, 数字なら0
など)への対応も適切か
コードの質
- わかりやすいコードか(何のための何をするコードか、他者が見てもわかるか)
- 変数・関数などの命名は適切か
- 共通化できる/した方が良い部分はあるか
- 分離した方が良い部分はあるか
- もっと良いやり方はないか(ベストと思えるコードか)
- 変更や追加した箇所のテストを追加したか
コーディング規約に沿っているか(プロジェクトでコーディング規約がある場合)
- アーキテクチャ・構成的に、各コードが適切なディレクトリ・ファイルに配置されているか
- 命名規則や文法は適切か
実際に動かしてみる
コードを確認するだけではなく、セルフレビュー時に動作確認も行うことをおすすめします🙋♀️
- 動作は問題ないか
- イレギュラーだけど起こりうる値が来たり、操作が行われた場合どうなるか
レビュアーへの配慮
レビュアーが気になりそうなことはコメントしておく
なぜ必要なのか、なぜこれを使ったのか等、レビュアーが気になりそうなことは、PRにコメントしておくのがおすすめです。
やり取りの削減に繋がりますし、もし後からそのPRを見直した時にもわかりやすいです。
※コード内に残した方がいいコメントはコード内に残しましょう。
悩んでいることや質問があればコメントしておく
自分はこのコードに行き着いたけど、本当にこれでいいか悩む時は「他に良いやり方あったら教えてください」と、PRの該当箇所にコメントするといいです。お互いの知識共有やより良いコードに繋がります。
最後に
セルフレビュー時の観点をお伝えしましたが、結局通常のレビューをする時と同じですね😂
レビュー観点が身につくと、それを想定したコードが書けるようになるので、コードの質も上がっていきます。レビュー観点は、自分がレビューを受ける時にも吸収していきたいですね!