レビュー、キライ、そして今。「ここだけ見ました」から始めるコードレビュー

多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。Recustomer株式会社の開発エンジニア・前田さんが語った「コードレビューが嫌いだった自分が、少しずつ嫌いではなくなってきた」変化と、その背景にある取り組みをご紹介します。
また、読者のみなさんの声を執筆者にお届けするフォームを試験的に設置しています。記事最後のフォームより、読後のひと言をお寄せいただけると嬉しいです。
^[1]

Recustomer株式会社で開発エンジニアをしている前田です。今回は、私が「レビューが嫌いだ」と感じていた理由と、考え方が変わってきた背景を紹介します。

私はレビューが嫌いです

突然ですが、私はレビューが嫌いです。レビューに必要な前提情報が揃っていないことが多かったからです。実装の背景や設計思想が見えないと、コードの意図を追うことができません。

つらかった思い出もあります。例えば、ファイル変更以外の情報がまったくない、Descriptionが空白のPR。あるいは、目的や期待する結果が分からないPRもありました。

「開発が速い会社」のレビューは雑ではなかった

そんな中で、私が所属するRecustomerは2年連続の受賞[^2]など、開発生産性を評価されているスタートアップです。開発スピードが速いと聞くと、「レビューは雑なのでは」と思われるかもしれません。

しかし、私の体感は逆でした。レビューは丁寧で、むしろレビューが強く意識されていました。レビューされていないPRがSlackで通知され、1日に数回「誰のPRが、誰に見てほしくて、何時間待っているか」が流れてきます。

レビューされないと仕事が進みません。だからこそ、レビューの優先度を実装よりも高く置く、という思想が根付いていました。

レビューを支える取り組み

ここからは、そんな弊社で実践しているレビューの取り組みを紹介します。