メンバー対談「レビュワーとしてレビューするときってどんな感じ？」yokota × suzuki 編（後編）

yokotaチェックに何周かするよね、まずは機能見て、見た目が再現されてるか見て、コード上妥当性があるものになってるか見て、みたいな。

suzukiそう。わりといろいろそういう感じで見るよね。

yokota自分もプルリク出す側になるときは、できるだけ「ここを見てね」と「ここは見ないでいいです」っていうのはちゃんと書くようにしてるよね。

suzuki見なくていいところもね、確かにね。

yokotaここはこのプルリクでは再現されてないけど、こういう理由で今はやっていません、みたいなことをちゃんと書いて、できるだけ最小のレビューでApproveされたいなって。

suzukiそうだね、うん。あとマージ先によって粗さは変えてるかな。

yokotaああ〜、どうだね、それはあるね。

suzukiもう次はデプロイっていうブランチだったらすごいしっかり見るし、まだマージしても開発用だからリリースまでは遠い、ってなれば、いざとなったら後で直すからってことで、マージ速度を優先する。

yokotaうんうんうん、そうだね、レビューが玉突きで溜まることでコンフリクトが増えたりしちゃうもんね。

suzukiそう、それが重たくなるから。

yokotaコンフリクトするとやることが重くなるもんね。特に開発初期はそうだよね。確かにどんどんマージしていきたい。

suzukiうん。

yokotaでもなんか、レビューをずっとやってると、いろんな人のコードの癖とか命名の癖とかが見れるから、すごい学びがある。

suzuki確かに。

yokotaあの人がこういう実装をするときにはこういうふうに書くな、っていうのが記憶に残ってて、いざ自分が実装するときにそれを見に行けたりするから、レビューし合うのっていいよね。レビューって弊社の基礎というか、ベーシックな文化だと思うけど。

suzukiそうね、そうだね。

yokotaあとあれか、ローカルで立ち上げたときはウェブツールでコンソールは見るかな。結構キーがないよとかはよくあって。マップ回してるところの。

suzukiわかる、実装してるときには気付かないところ出てくるよね。

yokota社内の中でプルリクするときと、お客さんに見せるプルリクでは、ちょっと違うよね。

suzukiうん。そうかも。

yokotaお客さんに見てもらうプルリクは、よりていねいに出す。

suzukiそうだね、いつマージしてもらってもいいように出すかな。

yokotaあとコンテキストをしっかり書くかな。暗黙知に頼らない状態で出す。

suzukiうんうん。あとはどうかなぁ、仕様通りかってところかなぁ。仕様のドキュメントがちゃんと用意されているときは、それ通りになってるかどうかみたいなところを見るかな。

yokotaそうだね、それは重要だね。仕様を実装者が理解していることはもちろんなんだけど、レビュワーが理解してないとレビューできないもんね。

suzukiそうなの。だから意外に見るところあるかなぁ。

yokotaざっと見る箇所を挙げただけでもこんなに出てくるもんね。でもひとつのプルリクで何周かすることもあるから、小さければ小さいほどいいよね。

suzukiあとは正直、見る相手＝作業者によって粗さも変わるかな。

yokotaあるある。

suzukiまぁ全部見るってなると、今挙げたことぐらいは見るかなぁ。

yokotaなんかこう、プロジェクトの初期と中盤で乗ってきたあたりでも全然見方が違うよね。

suzukiうん、そうだね。

yokotaだからこう、メンバーでも観点が変わるけど、フェーズでもちょっと観点が変わるよね。初期はていねいに見るけど、中盤ひたすらに実装するってパターンもあるし。優先して見るところが変わるよね。

suzukiそう。でもさ、やっぱものによるよね！

yokotaそう、ものによる (笑)！

suzukiそのコンポーネントの影響範囲がどのくらいなのかによってもだいぶ違うし。

yokotaあー、それはそうよね。

suzukiかなり重要な機能だってなったら、気にするところが変わったりするから。ものによるって言っちゃったらアレだけど、でもものによる (笑)。

yokota本当そうだね。今日の話の結論は…(笑)。

suzuki(笑)。でもちゃんとほどいていけば、あるからね、こういうときはこれを見る、みたいなのが。

yokotaあるね。

suzukiあるね。じゃあいつかブログにするってことで (笑)。