セルフレビューの観点と意識していること

Thoughts

最近聞かれることがあったので、自分がセルフレビュー時に意識していること・観点を言語化しておこうと思いました🙋‍♀️
※以下、「Pull Request」を「PR」、「Merge Request」を「MR」と記載します。

セルフレビューとは

他の人にレビューを依頼する前に、自分でレビューを行うことです。
自分でレビューを行い、気づいた点はレビュー依頼前に対応することで、PR/MRの精度を高めることができます。
精度が高いと指摘箇所が減るので、結果的にレビュアーや自分の負担を減らせたり、マージまでの時間が短くなったりします👍

セルフレビューのやり方

使用するツールは人それぞれかと思いますが、変更の差分を確認できるものをおすすめします。
私の場合は、GitHubやGitLab上でPR/MRを作成する時、まずはDraft状態にして、そこでセルフレビューを行なっています。

セルフレビューする時に意識すること

PRを自分のものとは思わないこと🙅‍♀️ です。
他の人のPRをレビューするつもりで確認します。

主観的だとどうしても見落としが発生したり、視野が狭くなります。
客観的に自分のコードを確認することが大切です。

あと、焦りも抜け漏れを生むので、「早くPR出したい!」という気持ちがもしあったとしても、ぐっと抑えて落ち着いてやりましょう。

セルフレビューする時の観点

超基本的なこと

  • 不要なファイルはコミットされてないか
  • 不要なログはないか
  • タイポ(綴り間違い等)はないか

バグがないか

  • 既存処理に影響はないか(特に共有コードに変更を加えた場合など)
  • テストは通るか
  • エラー発生時の処理もカバーできているか
  • イレギュラーな動きをする場合がある値(文字列なら空文字"", 数字なら0など)への対応も適切か

コードの質

  • わかりやすいコードか(何のための何をするコードか、他者が見てもわかるか)
  • 変数・関数などの命名は適切か
  • 共通化できる/した方が良い部分はあるか
  • 分離した方が良い部分はあるか
  • もっと良いやり方はないか(ベストと思えるコードか)
  • 変更や追加した箇所のテストを追加したか

コーディング規約に沿っているか(プロジェクトでコーディング規約がある場合)

  • アーキテクチャ・構成的に、各コードが適切なディレクトリ・ファイルに配置されているか
  • 命名規則や文法は適切か

実際に動かしてみる

コードを確認するだけではなく、セルフレビュー時に動作確認も行うことをおすすめします🙋‍♀️

  • 動作は問題ないか
  • イレギュラーだけど起こりうる値が来たり、操作が行われた場合どうなるか

レビュアーへの配慮

レビュアーが気になりそうなことはコメントしておく

なぜ必要なのか、なぜこれを使ったのか等、レビュアーが気になりそうなことは、PRにコメントしておくのがおすすめです。
やり取りの削減に繋がりますし、もし後からそのPRを見直した時にもわかりやすいです。
※コード内に残した方がいいコメントはコード内に残しましょう。

悩んでいることや質問があればコメントしておく

自分はこのコードに行き着いたけど、本当にこれでいいか悩む時は「他に良いやり方あったら教えてください」と、PRの該当箇所にコメントするといいです。お互いの知識共有やより良いコードに繋がります。

最後に

セルフレビュー時の観点をお伝えしましたが、結局通常のレビューをする時と同じですね😂
レビュー観点が身につくと、それを想定したコードが書けるようになるので、コードの質も上がっていきます。レビュー観点は、自分がレビューを受ける時にも吸収していきたいですね!

タイトルとURLをコピーしました