コードレビューについて

こうしたらうまくいった、という話じゃなくて、こうしたらうまくいかなかったからこうした方が良いような気がする、というポエム的な内容。

僕が今のチームに参加したのは4年くらい前で、その頃はチームのいろいろが整っていない状態だった。
その時のリーダーが奮闘して、そこから1年くらい掛けて開発フローとかの整備をした。
その一つとして、コードレビューを開発のフローに組み込んでマージするコードは必ずメンバーのレビューを通ったものになるようにした。

レビューの導入当初はすこしゴタゴタした気もするけれど、みんなレビューするのもされるのも割とすんなり受け入れていたように思う。僕から見てみんなレビューの文化を気に入っているように見えた。少なくとも僕はとても気に入っていた。レビューするのもされるのもとても勉強になった。

それから2年か3年くらい、少しのメンバーの増減はあったもののメインの4人のメンバーでコードレビューをしながら開発を続け、その中でレビューの精度は上がっていったと思う。精度が上がったと言ってしまって良いかわからないけど、レビューする/されるを繰り返すうちに指摘されそうなことは予め直しておくようになったし、最初の頃は気づかなかった/気にしていなかった点もこうした方がいいとか言えるようになった。

そんな中、少し前にちょっと大きめのチームの改変があって元々のチームだった4人の内1人は別チームへ、1人はマネージャー的ポジションへ移動し、新しいメンバーが3人入ってきた。

ここで問題が発生した。

新しく入ってきたメンバーのプルリクエストに対して、レビュアーからのコメントが山盛りになってしまった。
内容は誤字脱字や、変数のスコープが無駄に広い、意味のないコメントがある、のような単純なものからライブラリの使い方や設計に関するものまで様々ではあったが、端から見ると新しく入ってきたメンバーを既存メンバーがフルボッコにしている感じになってしまった。

コードレビューを、"製品のコードのクオリティを高めるためのもの"と考えればこのような状況になってしまうのも仕方ない気もしている。よりよくできるところがあるなら可能な限り直しておきたいし。けれど、現実問題としてこの状況はあまり好ましくないように思う。

レビュアーはもちろん責めている訳ではないけれど、レビュイーは多分嫌な気持ちになると思う(これは言い方とかを気にすればいくらかはマシになるかもしれないけれど、どちらかというとそういうのが得意じゃない人が多かった)。
あと、既存メンバーの観点だけが必ずしも正しいわけじゃないはずだけど、既存vs新入メンバー的になると多数決的にも(既存システムについてよく知っているとかの理由で)パワーバランス的にも既存メンバーが強くなってしまいがちだと思う。
あと、チームのメンバーがPRのやりとりのなかで習得した、直したほうが良い点とかの知識が暗黙知になってしまっていて、それを伝える方法がPRでフルボッコにするしかなかったというのもかなり大きな問題だと思う。

コードレビューは、"メンバー間の相互教育のためのもの"と考えた方がいいのかもしれない。

うまく言えないけど、全PRに対して可能な限りのクオリティを求めるのではなく、ある程度時間を掛けてでもレビューしてもらいたい点とか気をつけてほしい点とかをPRを通して徐々に伝えていく方が良さそうな気が今はしている。
新しく入ってきた人も最初は"チームが培ってきた文化からすれば"適切でない点があるコードになってしまうかもしれないけれど、ボコボコにされて嫌になってやめてしまうよりも、チームの文化に慣れてもらって後からでもそういうコードを書く・そういうコードに書き直すようになってくれた方が健全なように思う。

あと、予め文章で伝えられる内容はまとめておいてその文章をメンテしていくのが良さそうに思う。