コードレビューの難しさ

いつもコードレビューをやるときに、難しいな、と感じていることがある。

それは、特に自分の専門領域であり、かつ、実装方針もほぼ完全に見えていて、かつ、思っていたのとかなり違うコードが出てきたときにどうするか、というもの。

この条件をすべて満たす場合にのみ発生するものなので、例えば先にチーム内で実装方針をすり合わせすれば、この問題は起きない。だが、ここは僕のポリシーとしてあまり口を出さないようにしている。相談されたらサポートはするが、基本的には実装者に考えて欲しいので、どれだけ時間がかかろうとやってもらうようにしている（スプリントゴール意識して使えるもんは全部使えよとは思うが、それはまた別の話）。

さて本題に戻る。

僕はこういうときどうしているかというと、コードサンプルを提示してしまう。こうしたほうがいいですよ、と。もちろん思っていたのと違う、が、めちゃくちゃいい実装だったら 👍 してLGTMするのだけど、こういうケースの場合はそうではないことのほうが圧倒的に多い。なので、指摘をする。

こういうコードが出てきてしまう場合、具体的な実装を示さないコメントをしてしまうと、経験則的にコメントと修正のラリーが続いてしまうことを知っているので、正直に言えば僕は逃げの一手を打っていることになる。だってめんどくさいし、お互いストレスになるから。しかもラリーが返ってくるまでに1日以上とかザラにある。

で、難しいな、と言っているのは、この行為の是非。

僕の中では答えは出ていて、コードサンプルを提示するのは間違っている。コードスニペット程度なら全然アリだが、それほぼ再実装じゃんみたいなものを出すのは良くない、というかダメ。時間がかかることには目をつぶって、指摘箇所すべてを伝わるように言語化してコメントをつけるのが理想。

でも現実問題、この程度の実装はさっさと終わらせたいし、他にUser Storyもあるわけで、Stream alignedなポジションにいるのでより早くプロダクトを前に進めないといけない、と言い訳しながら、コードサンプルを提示している。これがEnablingなどの立場でレビューする側だったら、迷わずじっくり時間をかけれる、、のだろうか。僕の性格上、そうはならないかもしれない。

これはもうずっと、前職、下手したら前前職くらいから感じていることなので、僕は何も成長していないのだろう。少なくとも、マネージャーには不向きだと思う。