レビュアーをアサインした後に PullRequest をごちゃごちゃしない

チームで開発を行う場合に、コードレビューのプロセスを挟むことがあるかと思います。
例えば Github を利用しているなら、PullRequest を作成して、レビュアーをアサインします。そしてレビュアーの承認をもって、コードの変更分が本体に合流します。本体とは main や develop と言った恒久的なブランチです。

さて、チーム開発をしていて思うことですが、レビュアーをアサインしたあとに PullRequest をごちゃごちゃする人がいます。
ごちゃごちゃとはつまり、しれっと追加コミットをしたり、時間を置いてレビューコメントを追加したり、ということです。

レビュアーにとっては、アサインされたその瞬間からレビューが始まっているわけです。
Github と Slack を連携している開発者にとっては、アサインされたことが即時通知されるかもしれません。
つまり PullRequest を作成し、アサインを行った数秒後には、彼らはレビューを開始している可能性があるのです。

その状態で追加コミットを行うとどうなるか。
もし追加コミットが大量の変更を含む場合、レビュアーはまたイチからコードを読み直す必要があります。あるいはレビュアーが行った指摘が古くなる可能性もあります。

もしそのような状態が頻発するなら、レビュアーはうんざりするかもしれません。そして今後、レビューが後回しにされるかもしれません。

もちろん、レビューを受けてのコード変更は問題ないと思います。
あるいは、追加コミットを行ってしまった場合でも、「考慮漏れがあったので、この行を変更しました」のような追記コメントをしてあげれば丁寧かなと思います。

かく言う自分も、昔はよくそのようなことをしていました。
PullRequest を作成し、レビュアーをアサインしたあとの変更です。コードを見直して微妙だなと思った箇所を直して、何度も追加コミットをしていました。
あるいは、レビューしやすいようにレビューコメントをたくさんつけていました。それ自体は悪いことではないのですが、Slack連携していた同僚にはそのたびに通知が飛んでいたようです…。
今では、コード修正やレビューコメントの追加を完了してから、レビュアーをアサインするようにしています。

ここに書いたことは、ある意味では些細なことです。
全く気にしない同僚もいると思います。そもそも、レビュー時の決まり事は、会社や開発チームによって様々です。郷に入っては郷に従うのがよいと思います。
が、個人的なマナーとして、自分はこの記事で書いたようなことを意識して働いています。