5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

前書き

PRのレビューコメントをもらった時、こんなこと思ったことありませんか?

  • 確かにこれ改めて読んでみたらちょっとわかりにくいね
  • あーこれ消そうと思って消し忘れたコードだわ
  • あれなんで俺これ書いたっけ…
  • などなど

このようなハプニングは、レビュアーの負担になるだけでなく、レビュアーとのやり取りの時間がかかり、マージまでのリードタイムが伸びてしまい、さらにコンフリクトが発生する確率も時間と共に上がり、そのコンフリクト解消でデグレや新たなバグが発生してしまうリスクもあるので、減らしていきたいですね!

そんな時にぜひ実践していただきたいのは、PR提出の前に、一度レビュアー視点でセルフセビューを行うことです!

なぜこのようなハプニングが発生するのか

まず、普段我々の開発では、多くの場合は頭で一度考えたらそのままコード書いて提出、というシンプルな流れにはなかなかできず、たくさんの試行錯誤を行いながらコードをコミットしていくわけです。その時、都度都度のコミットでは明文化されていない試行錯誤の途中段階で積み上げたコンテキストが、無意識で脳内にインプットされた状態でコーディングしています。しかしレビュアーは当然コミッターと一緒に試行錯誤してきたわけではないので、そのようなコンテキストが脳内にない状態でレビューをします。脳内に入っているコンテキストが違うから、当然コミッターが当たり前だと思って書いたコードも、レビュアーからしてみたらそうとは限らないですね。

また、その暗黙なコンテキストの他に、試行錯誤してる途中では当然我々は動作確認用にいろんな実装をします。「この実装は使えない」「この実装は使えるけど雑だから整理が必要」「この実装は使えるはずなのになぜか動かない」など、さまざまな過程を経て最終的なコミットまで辿り着きます。一度に完璧なコードを書いたのではなく、何回も書き換えてできたコードだから、気づかないうちに余計な処理や改行などが入ってしまうのも無理はありません。

セルフレビューの意義

セルフレビューはまさにこのようなハプニングを抑えるために行うものです。基本的に我々は最終動作確認が終わったら、これまでの試行錯誤で積み上げてきたコンテキストを多少忘れてしまうので、レビュアーとある程度同じような目線で自分の差分を客観的に見ることができます。また最終差分なので、都度のコミット差分では気づきにくい試行錯誤中のコードの添削でできてしまった無駄な改行やコメントアウトも気づきやすいです。

試行錯誤中に都度コミットしてる場合は、さらにPR作成前に、一度コミットを整理することもおすすめします。特に比較的に粒度が大きいPRの場合、コミッターがどのように考えて実装しているのかを理解するために、コミットごとの差分を確認する場合もあるので、整理されているコミット履歴だとレビュアーにとって非常に助かります。

コミットの整理の仕方は人それぞれです、Interactive Rebaseでコミットを分割/合体/順番入れ替えする人もいれば、筆者みたいに一度Mixed Resetにしてコミットを作り直す人もいると思います。自分の好みで行なっていくといいと思います。

セルフレビューのやり方

セルフレビューの手順は非常に簡単です。ここはGitHubを例として挙げますが、他のホスティングサービスでも似たようなことができると思います。

まずは通常通り、PRを作成します。

スクリーンショット 2025-12-08 17.05.21.png

ただし次のPR内容編集画面では、TitleやDescriptionの編集が終わったら、即Create pull requestを押すのではなく、このまま画面を下にスクロールしていきます。そうすると、このPRで適用されるコミットと全体の差分が表示されます。

スクリーンショット-2025-12-08-17.06.14.png

この差分は最後のレビュアーが確認する差分と一緒なので、これをセルフレビューするといいでしょう。セルフレビューするときは、なるべく意図的に頭をまっさらな状態でセルフレビューすると、よりレビュアーの目線に近づけられて効果的だと思います。

ちなみに、GitHubの場合は、このPR作成ページをそのままリロードしても、今まで書いてきたTitleやDescriptionは失われないので、「あ、ここ直した方がいいかも」的な箇所を発見したら、そのままローカルで修正してPushすれば、ページをリロードしたらその差分を反映できるからおすすめです。セルフレビューが一通り終わったら、最後Create pull requestをクリックしてPR提出しましょう。

最後に

セルフレビューをして、マージまでのタイムリードを減らしていきましょう!

最後の最後に

ちょっとした宣伝ですが、本記事に使ったスクショは、AndroidのSnackbar風のUIを、SwiftUIで使えるライブラリー「Tardiness」のPRです。SwiftUIでEvent-Drivenな感覚で簡単にトーストを出せるので、よろしければぜひ試してみてください!

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?