前回の記事を書いていて、最近コードレビューが億劫になっている原因の一つがここに隠されているんじゃないかなと思った。
ちょっとここで言語化してみる。

前回の記事：コードコメントには Why も書いてほしい | JichouP Blog

負荷が高いコードレビューは億劫になる

まず、自分には億劫になるタイプのコードレビューと、ならないタイプのコードレビューがある。
それらを比べてみると、どうやら自分は消費カロリーの大きいコードレビューが億劫になるようだ。
例えば、自分がそのコードの詳細を理解しておく必要があるものは、手をつけるのが遅くなりがちだ。
逆に、アーキテクチャやお作法だけ見てほしいという依頼など、自分がそのコードの詳細を理解する必要がないものは、手をつけやすい。

コードレビューの負荷を下げる方法

ただ、詳細を見る必要があるコードレビューでも、負荷を下げる工夫があれば、億劫にならないことがある。
コードレビューをするときに、やってもらえて嬉しかったことをいくつか紹介する。

1. Why や Why not のコメントがある

前回の記事で書いたように、Why や Why not のコメントがあると、そのコードの意図がわかりやすくなる。
1行でもいいので、そのコードを書いた理由を書いてもらえると、レビュワーはそのコードの意図を理解しやすくなる。
レビュワーが疑問に思うことを先読みして、その疑問に答えるようなコメントを書いておくと、レビューしやすい。

自分が過去に書いたコードがわからないという現象は、プログラマーあるあるとして広く認知されている気がする。
そういう経験の中で、未来の自分がわかりやすいコメントを書くように意識して練習するといいかもしれない。

2. プルリクエストは400行程度の変更に収める

たまに、2000行とか3000行とかのプルリクエストが来ると、どこから手をつけていいかわからなくなる。
大抵は、複数の機能を一気に実装したり、リファクタリングも一緒に行ったりしていることが多い。
最近、そういうものは、プルリクエストを分割してもらうようにしている。
（分割する手間は増えるが、開発者から話を聞く限りだと、お互いに Win-Win になっていることが多い。）

余談だが、このプラクティスは、クローズドな開発組織よりも、オープンな開発コミュニティの方が浸透している気がする。

3. レビュワーに確認してほしいスコープを明示する

コードレビューを依頼するときに、どの部分を見てほしいかを明確に伝えてもらえると、見るべきスコープが絞られて、レビューしやすい。
プルリクエストごとに明示するというよりは、コードレビューの役割を依頼するときに、どの部分を見てほしいかを伝えておくといい。
そうでないと、レビューする側も、どこを見ていいかわからなくなり、全部見ようとしてレビューの負荷が増えたり、適当に流してレビューの質が落ちたりする。

4. プルリクエストに、画像やGifを添付する

特に、UIの変更がある場合は、画像やGifを添付して、どのような変更があったかをわかりやすく伝えてもらえると、レビューしやすい。
文章でがんばって全てを説明するよりも、画像やGifを使って説明したほうが、組織のトータルで見たときに誤解が減ってプルリクが早く片付くし、レビューの負荷も下がる。

コードレビューに割く時間はどのくらいがベスト？

本来ならば、開発者がそのコードを書くのに書けた時間を1とすると、コードレビューに割く時間は0.3くらいがいいのかなと思っている。
そのくらいかけないと、詳細をちゃんと確認できないからである。
でも、実際にこれだけの時間を書けるのは不可能だ。
コードレビュー以外にもこなすべきタスクは山積みだからだ。
だから、どうしてもコードレビューに割く時間は多くて0.1くらいになってしまう。
開発者が詳細がちゃんと実装していると信じて、自分はどんなインターフェース（界面）になっているか、どんなテストを書いているかといった部分にフォーカスして、詳細はブラックボックスとして扱っている。

コードレビューに割く時間が少なくなると、プロダクトに対する熱量が下がる

ここで問題になるのは、いざというときに自分が実装できないということだ。
コードの詳細を理解していないので、キャッチアップするのにどうしても時間がかかる。
また、コードの詳細を理解してないと、どこか他人事のように感じてしまい、プロダクトに対する熱量が下がってしまう。

コードレビューにかける時間のバランスを取る

そもそも 0.1 の熱量でプロダクトに関わろうとしているのが間違いなのかもしれない。
本当にそのプロダクトが好きなら、自分が持っているどうでもいいタスク（緊急度は高いけど重要度の低いタスク）は後回しにしてでも、もっとコードレビュー（緊急度は低いけど、重要度の高いタスク）にかける時間を増やすべき。
その方が、自分も仕事にやりがいを感じられるようになるし、組織全体で見たときのアウトプットも大きくなるはずだ。