■

「なぜコードレビューをするのか」という問いに対する答えは様々だ．コードの品質を上げるため，コードレビュー自体が楽しいから，あるいはコードレビューやってる俺たちって恰好良いじゃん，などなど色々ある．
これらは全部正しいと思う．コードレビューをすればコードの品質が高くなる可能性は強まるだろうし，「コードレビューが楽しい」という感情がコードを書くための原動力になるのであればそれは良いだろうし (なぜならコードレビューをするにはレビュー対象たりえるコードが必要だ)，「コードレビューやってる俺たちって恰好良いじゃん！」というのも結構だ．貴方がたは本当に恰好良いヨ！

さて，コードレビューという話題に必ずついて回る尤もらしい理由の1つである「コードの品質向上」について考えたい．

なぜコードレビューがコードの品質を上げるための手段としてここまで人気なのか．
例えばコードレビューではなく，書籍を読んでそこから得られた知見で品質を上げることは出来ないのか．或いは他のプロジェクトのソースコードを読んで，そこから学び，活かすことは出来ないのか．さてこれらは反語だ．多分可能だと思う．長い時間，極端な例だが1年かければ確実にその対象のコード (例えば1 issue分のコード) の品質を最高にほど近い水準まで持っていけると思う．

しかし期日の無いプロジェクトなど無い．仮に全ての開発メンバーが各々1つのissueに1年もかけてしまってはビジネスは破滅する．我々に要求されているのはスピード感だ．

つまりあけすけに言うと，「コードの品質を向上させるため」っていう大義名分は重要な接頭辞を省略していて，これを省略せずに言い換えると「短期間でコードの品質を向上させるため」になると思う．

我々はコードを書く時に思考する．いつだってこれが最善かどうか悩むし，不安になる．そのまま自問自答を繰り返しても良いが，そうしている間にも納期は陽気にやってくる．
そのように1人悶々とする時期も必要かもしれないが，やはり我々に求められているのはスピード感と最高のグルーヴだ．所属しているプロジェクトのドメインに詳しい仲間に質問して，意見を求めて，相談して，そして実装を始めたり洗練させたりしたほうが早く解決する可能性が高い．

つまり「最短距離で」なおかつ「高品質で」突っ走る為にコードレビューは必要なのだと思う．そしてそれがウケているから人気なのだとも思う．

従って，その最短距離を目指しているはずの「コードレビュー」で奇妙なところを指摘して，迂回させるのはまったく意味が無い．しっかり本質を見極め，そこに力を割かなければならない．コストを下げる為の活動なのに，逆にコストが上がってしまってはならない．

文字だけでコードレビューしてると (例えばGitHubのWeb UI上とかで) こういうことは起きがちで、そもそも文字ベースのコミュニケーションは話題が本筋から逸れた時に元に戻しにくい傾向にあると思う．変な議論が始まるとずっと変な議論を続けがちになるから良くない．そういうのを避けるためにも，毎回とは言わずとも，そこそこの頻度で実際に対面してコードレビューは行なったほうが良いと思う．

さて，最小のコストで高品質を求める皆さんならもうお察しでしょうが，最小のコストで高品質を獲得出来るならコードレビューをしなくても良い．例えば「1+1 = 2」みたいなコードに対してレビュー出来る事は少ないと思うので，こういうところにコードレビューのコストを割くべきではない *1．コードレビューをすることによって生じるコストと，そのコードレビューによって得られる利益とを比較検討しなければならないと思うけど，そこら辺難しいですよねという感じ．相談すべきか，相談せざるべきか，という問題になってしまう．まあ悩むくらいなら誰かに相談すれば良いと思うんですが．

その辺のバランス感覚を養いたいものです．