【コードレビューで意識していることX選】いしとさんが地味に大切にしていることをご紹介します。

某たすくくん「いしとさんがコードレビューしても指摘ないんすもん笑」
いしとさん「はい、そしたら今回は指摘20個。」
指摘するときとしないときには理由があったりなかったり / いしとさん

1.最速でマージするために1～3日以内で終わる指摘をする
2.コーダーのモチベーションを下げない伝え方をする
3.レビュー指摘の内容を今回ではなく次回に回すこともある
関連記事

1.最速でマージするために1～3日以内で終わる指摘をする

「ドメインは日々変わるため、できるだけ鮮度を保った状態でマージさせたい」という理由です。

お客様のWebサイトと連携する、かつ、頻繁にそのサイトが更新されるような要件のスクレイピングをするようなPRについては、できる限り早くマージさせたいため、指摘をしてもすぐに対応できるようなレベルのものだけにします。そうすることでお客様に価値を提供しつつ、後々お時間を決めてリファクタリングをするようにします。

2.コーダーのモチベーションを下げない伝え方をする

「モチベーションが下がる伝え方をすると、苦手意識をもってしまうから」という理由です。

あなたはレビュー指摘で「この嫌な伝え方をするなぁ、モチベーションが下がるなぁ、この人と一緒におしごとしたくないなぁ」と思った経験はありますでしょうか？私は何度か経験したことがあります。

機能追加と、その機能に関わるリファクタリングを同時にしたときに「ここだけリファクタリングしても意味がないです、このままだと汚いのでこっちも修正してください」と言われました。その時の私は「こっちも修正してくださいという指摘については、今回のチケットの責務の範囲外のため、別チケットで対応します」と言っても「今直さないと汚いです」と意見を曲げないタイプのレビュアーだったので大変でした。※意見を曲げないそのレビュアーはのちのちワンマンプレーが目立ったり他の方がみてもわからないドキュメントを生産する傾向が強くチームプレーが苦手な人だということが判明しました。

実はけっこうリファクタリングは好きなのに汚いと言われるのは酷く傷つきましたし、私がその会社に入社するまえはリファクタリングの概念すらないところだったので、リファクタリングのやり方だったり、責務についてあんまりな人だったのでしょう。のちのち開発やリファクタリング経験のある別の部署の方々からは「いしとさんの意見は至極真っ当ですし、私もそうすると思います」と言われて救われました。

こういう経験があるので、「会社を辞めたくなる……」というレベルではありませんでしたが中にはレビュー指摘の内容にマウントが多くて「あの人と一緒にお仕事したくない、会社辞めたい」とつぶやいている人も散見されます。もうそういう時は、AIにコードレビューさせたほうがいいんじゃないかなとも思いました。

3.レビュー指摘の内容を今回ではなく次回に回すこともある

「先にお客様に価値を提供することを優先することもある」という理由です。

だいたいレビューの観点は以下になるかと思いますが「1～3」をクリアすればたぶんお客様に価値を提供できる状態ではあると思います。

要件に合っているか
期待値が出るか
アーキテクトに沿った作りか
読みやすいか

4の読みやすいかはリファクタリングの部分につながるわけなんですが、ここでは「指摘内容とサンプルコードを書きましたが、今回のPRで直しても別のPRで直してもどっちでも大丈夫です🙇」という形でコーダーにゆだねることも多いです。こうするとこで「次回でもいいんだ」と同時に「こういう書き方もあるんだ」と安心感と知識を増やすことができるためです。

おしごとに関する関連記事はこちら。