はじめに

ソースコードレビューについて、新卒4年目の僕が最近考えていることを書いていきます。
どうしても説教くさくなったり、ポエムっぽくなったりしてしまうので、苦手な方はブラウザバック推奨です。

どんな粒度でレビューをすればいいのか

ソフトウェアのソースコードは基本的に後から書き換えられるという性質上、名言されていない場合、
レビューが提出されるタイミングで、以下のうちどれなのか（あるいは他の場合もあるかもしれません）わからないということが起こると思います。

• ・ただ動くことだけ確認して書き殴ったもの
• ・レビュイー視点では丁寧に書き、もうほぼ完成と思っているもの
• ・レビュイー視点では重要でないと判断されるものは適当で重要なものは丁寧に書いているもの

この状態で細かく見すぎるとレビュアー、レビュイー双方の時間が無駄になってしまったり、
逆に大雑把すぎると見落としが発生してしまったりしてしまうと思います。

名言されていなくてもチームの開発フロー的に大体どれか推測することはできることもあると思います。
なので、そういう場合は例外的な場合だけその旨伝えるのが良さそうですね。
例えば、基本的にレビュイー視点では丁寧に書き、もうほぼ完成と思っているものに関してのみレビュー依頼を出し、
レビューやテストが通るとそのままリリースするといった開発フローなら、
大雑把に書いたソースコードのレビュー依頼をしたい場合、その旨書かないと細かく見すぎてしまう問題が発生してしまいます。

ただこの場合は隔離されたブランチで行わないと、他のチームメンバーがその大雑把に書いたソースコードを参考にして書いてしまい、
そこでもレビューにまつわる無駄が発生してしまうことがあると思います。
例えば、何か書く時にdevブランチからブランチを切って作業して、問題なければマージするというフローなら、
大雑把に書いたものがレビューに通ったからといってdevブランチに入れると問題が起きるかもしれないということです。

この辺りはチームの開発フローやブランチ戦略、それにレビュー対象物がどの粒度かによるところが大きいと思います。

これって本当に好みの問題？

ソースコードレビューする時に、重要な観点として以下があると思います。
他にもあるかもしれませんが、パッと思いつくものを挙げてみました。

• ・実行速度が十分速いか
• ・可読性が高いか
• ・保守性が高いか
• ・バグがないか
• ・セキュリティ上問題ないか
• ・要件を満たしているか
• ・指摘事項の対応をして期日に間に合うか

レビュアーとレビュイーの間でこれらパラメータの重要度や理解が大まかにでも合っていないと、
一方的な主張になってしまい、一方のフラストレーションが溜まってしまうことがあると思います。
これの難しいところは主に以下二点だと思っています。

• ・場合によって重要度が変動すること
• ・人によって認識が異なること

上に挙げたパラメータの重要度の認識やそれぞれの項目に対する理解は以上二点の理由から基本的に完全に一致させることは難しいと思います。
うまくやっていくには、重要度の認識やそれぞれの項目に対する理解に関して、
何度かにわたるレビューの中でチームに合わせていく、もしくはチームを変えていく必要があると思っています。
これをうまくできるかは本人の性格やセンスによるところが大きいかもしれません。
しかし経験が長くなったり、さまざまなチームで開発した経験があったりするとスムーズにできるようになるとも思います。

上に挙げたパラメータに関する重要度の認識やそれぞれの項目に対する理解を合わせる必要がある時に、
「好みの問題」が出てくるかもしれません。
調べたわけではないのでここに問題提起している人がいるかもわかりませんし、
いたとして、なにか共通理解として定説があるかもわかりません。
「好みの問題」は以下のようなものと考えています。

• ・レビュアー側の好みの問題なので対応有無は任せるという考え
• ・レビュイー側の好みの問題なので対応する必要がないという考え

確かに「好みの問題」というものは存在しているとは思いますが、上に挙げたようなパラメータ（他にもあるかもしれません。）によって
総合的な判断をした結果、そのソースコードにした（したい）ということがあると思っています。
それなら基本的にはそのように書いた理由、そのように指摘した理由を話すべきだと思っています。
言いにくい雰囲気があったりするかもしれません。
これまでのやり取りから相手がどのように考えているかわかっていたりする場合もあると思います。
また、話す時間がないこともあると思います。

色々あると思いますが、好みの問題と言いたくなる時は一度立ち止まって考えています。
好みの問題という言葉で片付けるのは簡単だが、本当に好みの問題なのか？
本当は何か理由があってそうしている（したい）のかもしれません。
発言しなくても一度言葉にして書くだけでも構わないと思っています。
すると、きちんと考えきれていない部分や面倒くさくなってしまっていた部分が浮き彫りになります。

おわりに

他にも色々考えていることはありますが、ここには書いていないこともあります。
僕自身は言葉になっていないふわふわした状態が落ち着かない性格で、
ソースコードレビューは基本的にやり取りするのは一対一なので、
一旦納得できるまではわからないことや疑問に思ったことをできる限り聞くようにしています。
その結果やりにくいなとか面倒臭いなと思われていたりするかもしれませんが、
繰り返すうちに、最終的にはチームとしての方向性が合ってきたり、
レビュアー、レビュイー双方の理解が正しくなったりすると信じています。