プルリクエストのレビューは業務で日常的に行っているのだが、時々レビューがとても難しいと感じる場面に出くわすことがある。そんなときどうするか。

何が難しいのか

僕がレビューすることになるプルリクエストの概ねは、同じチームで働いている人々が出してくるプルリクエストである。普段から同じドメイン領域で仕事をしているチームなので、出されるプルリクエストが「全然意味分からん」みたいなことは割と少ない。

少ないんだけど、しかし、時々普段のドメイン領域をはみ出すようなプルリクエストが提出されることがある。そうなると急に土地勘がないというような感覚になる。全然意味分からん。まともなレビューができる気がしない。とはいえこういったものも限られた時間の中でレビューせねばならない。どうする。

こういう難しいレビューが課せられたとき、どういう手が取れるか、あるいは取ってきたか、というのを考えてみた。

パターン 1. 斜めに読んで LGTM

良くないと思いつつやっちゃうことがある。それなりに読みこんでいけばなんとなく分かるときもあるが、それにしたってもう少し効率いいやり方、特にちゃんと品質に寄与しようと思ったら良いやり方があるよね、って思うところ。他にもレビュアーがいるときなんかに起こりがち。甘え。戒めとして言語化しておく。

パターン 2. 書き手に解説を依頼する

だいたいの場合、プルリクエストについて一番詳しいのは書いた本人である。書いている本人はプルリクエストを提出するために様々な調査を重ね、コードベースを熟読し、既存機能を壊さないよう気をつけながら編集している。そりゃー詳しい。なので書いた本人に解説してもらう (文書ではなく口頭のほうが良かろう) というのがこれ。同期的なコミュニケーションになる場合もあり、場合によっては資料の準備なんかも必要になり、あとは複数人数が一緒に解説を聞くとするとスケジュールの調整も必要になり、ということでややコストは高い。あと解説をしてもらっても、プルリクを書いた本人ほどの理解を得るのは難しいという一面もある気がする。
だけど、後々そのコードベースを自分やチームメンバーがメンテナンスしていくことを考えたら、ちょっとでも理解度を上げておくというのはコスパ良いということになるかもねーと思わないでもない。ただ、手間を考えるとやや気後れする案のようにも感じている。

パターン 3. 動かす

コードレビューじゃないじゃん、って言われたらそうなんだけども。読んで分からないのであればとりあえず動かす。
実際にプルリクエストのコードを手元にもってきて動かしてみて、期待通り (仕様通り) に動いているか確認をするというのもある意味ではレビューであると思う。動かしてみて実際の振る舞いの確認した後にふたたびコードレビューに戻ると理解が進む、みたいな場合もある。ドメイン知識が不足している部分であるという前提にたつと、そもそも UI 上のどこに反映される変更なのか、ということすら理解があってないこともある。期待動作についてプルリクエスト上で認識合わせをするのも良い。確認した期待動作についてプルリクエスト上に記載しておけば、将来的に期待動作が不明になったりしたときに、もしかしたら考古学としての役目を果たす可能性もある。

とはいえやっぱり難しいものは難しいので諦めも重要

とはいえ分からないものをきっちりレビューするのは難しいことに変わりない。やや無責任かもしれないけれど、時には諦めて先に進もう、やむなし、というくらいのメンタリティでいないとツラくなってしまうような気もする。