Pull Request レビューの限界
いくつか念頭にある過去の他の方の記事や発言があるのだが、パッと見つけられないのでゼロベースで書く。
Pull Request のレビューという文化がほぼ完全に定着してからかなり経った。5年前くらいはまだ「Pull Request のレビューを開発フローに入れています」みたいなことを採用ページの文言に入れている会社が結構あったが、今時もはや当たり前になりすぎて誰も言わなくなった。
それくらい Pull Request を出してそれをチームの人がレビューするというフローは当たり前になっているが、僕はそれにずっと疑問を感じている。はっきりいってしまえば、僕は多分平均的な人の30%程度にしか Pull Request レビューに対して意義を感じていない。チームとしてコードの品質を担保したり、コードを複数人で所有するといった目的において、 Pull Request レビューが果たすことができる割合は、そんなに大きくないと僕は思っている。
Pull Request レビューの難しいところを書いていく。
・前回までのコードとの差分という形で表示される形式には限界がある。この形式はどうしても、モジュール設計など大域的な問題を軽視させ、行ごとの書き方のような細かい話題に注視させやすい構造をもたらしてしまうと思う。
・コードの書き手とレビューする側との知識や思考の差を埋めるのは Pull Request のレビューでは難しい。したがって、レビュワーがかなり時間を使わないと薄っぺらい指摘しかできない。
・出した Pull Request がなかなか取り込まれない、という状況が起きると、様々な意味でストレスフルである。
以上のような理由から、僕は Pull Request レビューの工程で「より良いコードにしていく」ことはかなり負荷が高いことだと考えている。むしろ、根底に関わるような重要な設計相談はそれ以前に会話なりモブプログラミングなりですべきだし、あるいは、別に merge した後に他の人がコードを触るときに修正したって良いのだ。Pull Request のレビュー、つまり「完成したものをメインストリームに取り込む直前」にやるべきことは多くない。(なお、上の弱点を減らすためには、PRのレビューを対面あるいはオンラインで同期的に行うのが良い考えだと思う)
とはいえ、健全なチームであれば git push origin master するよりは Pull Request を通したほうが良いという考えになってきた (最近の経験) 。Pull Request レビューに過度な期待をしなければ、有害にはならず、基本的にメリットを産むものにできる。
僕が Pull Request のレビュワーのとき、ほとんど全てのコメントは単に自分の考えとして表明し、変更を要求しない。Request Changes にするのはバグがあるときだけである。それから、書き手と自分の間の理解の差分を埋めるのが難しいことを認め、どうしても必要なら質問するし、そうでなければ、「こういうケースが考えられそうだけど大丈夫? 大丈夫なら問題ないよ」みたいなレビューの書き方をする。
これはもしかしたら怠慢かもしれないし、というか実際僕は Pull Request のレビューに関してはかなり怠けている自覚があるが、多分 Pull Request のレビュー以外の方法で同じ目的に貢献できてる気はする (その前の設計レビュー、モブプログラミング、ガイドラインの作成、一度取り込んだ後の修正提案としての Pull Request、など) ので、それでもいいんじゃないかなって思う。
Pull Request のレビューがうまくワークしてない人がいたら、それ以外の方法でも目的を達成できるよ、っていうのを考えてみてもいいんじゃないかな。たぶん。
追記: 公開時より2年以上前の記事で、僕が言いたかったことをより言語化してくれていた。今更ですが見つけたので紹介。
noteの通貨流通量を増やしていきたい!!