この文章は一般論としてなぜソースコードレビューをするのか、ではなく、私が個人として、コードレビューをしているモチベーションはなんなのかを整理するために書いた。
最近ずっとソースコードレビューをしているが苦痛になってきた。ので、ソースコードレビューをやめるか、ソースコードレビューを苦痛でなくするか、苦痛なまま続けるか、いずれかを選ぶ必要がある。 やめる案に関しては、一旦考えないことにする。レビューがビジネスに対して与えるメリットが、レビューのコストを上回るかどうかは正直よくわからない。 これがわかるとやめる選択をとれたり、レビューに対する苦痛が少し減ったりする気がするが。 今の所はどうしても、メリットがあるからレビューをする、というよりも開発に対する美意識としてやるべきだと感じているからやる、という感覚でレビューをしている気がする。
どのようなコードのレビューをしているかというと、複数の似たようなサービスを、統一されたインターフェースで呼び出すためのプロキシのようなサービスを開発していて、そのサービスが統合可能なサービスを追加するためのコードをレビューをしている。 「設計から外れたコードが書かれていないか」「何か複雑で特殊なことをする必要があるときに、良い感じの構造になっていそうか」「統合先のサービスの仕様に乗っ取っているか」「いわゆるプログラミングとして、あまりよろしくないコードになっていないか（変数名が変だとか）」「テストが網羅的か」といった観点でのレビューをしている。
なぜレビューをしているか。私の場合は主に「1. 人はミスするので、それを減らしたい」、「2. 視点を増やしたい」、「3. 読んでいて辛い気持ちになるコードを増やしたくない」の3点である。 教育としてのレビューを行なっている感覚はあまりない。以前の環境では教育が8割くらいの気持ちだったので、ここの感覚はコードを書く人の能力に寄ると思っている。 特に1と2が重要だと思っている。1は単純にヒューマンエラーをダブルチェックで減らそうぜ、みたいな話で、2はいろんな視点でコードを見たいという話だ。 いろんな視点で、というのはなんと言えばいいのか、いろんな経験から踏まえて、というのがいいのだろうか。
アプリケーションが正しく動かない原因は色々あるが、単純なミスだけではなく経験からくる知見がないと防げないものがあると思っている。 例えば複数のトランザクションが複数のリソースをロックする場合に、リソースをロックする順序がトランザクションごとに異なるとデッドロックする可能性がある、みたいな話だ。 そういった観点は他にも色々あると思っていて、賢い人なら論理的思考力と想像力で防げるのかもしれないが、私には無理だ。 そして、私は当然全ての知見を持っていないし、他の人も大抵の場合そうだと思っているので、視点を増やすのが重要だと思っている。
バグを完全になくすことはできないが、個人的には時間をかけてでもレビューをすべきだと思えるくらいにはバグを減らせるのではないかと思っている。 計測したことはない。どう計測すれば良いのだろうか。何かデータがあれば見たいが、コードを書く人のレベル感でこのあたりの感覚はかなり変わってくると思っており、計測って可能なんだろうかとも思っている。 やるべきかどうか、についてはアプリケーションの用途にもよると思っていて、バグってたら都度都度直せばいいや、みたいなものであればそれはそれで良いと思っている。 ただし、現在開発しているアプリケーションをそういった類のものだと思っていないので、レビューを続けている。
3については自己満足かもしれない。バグの少ないプログラムを書くためには、コードの綺麗さよりもテストにこだわった方が効率が良いと思っているからだ。 しかし、謎解きのようなコードを読んでいるとすごくモチベーションが落ちて効率が落ちるので、個人的には力を入れている。 ただしあくまで私の感情の話で、読みづらいコードによってモチベーションが落ちるのが一般的でないのであれば、ここに関してはそれほどこだわらなくても良いのではないかとも思っている。
