93
41

More than 1 year has passed since last update.

コードレビュー依頼された時に心がけていること

Last updated at Posted at 2022-07-15

まとめ

コードレビューが早ければ早いほどチームのスループットは最大化する :rocket:

コードレビュー依頼されたときのフローチャート

現時点の私のマインドです。※今後、みなさんのフィードバックを得て更新することもあります。

心がけているいること

A. リアクションする

レビュー依頼されたらすぐにリアクションをします。
これは依頼者に「あ、レビュー依頼伝わってる」と安心してもらうためです。
これがないと、「気づいてるかな?」とモヤモヤさせてしまい、依頼者が集中できる環境を作ることができません。

また、複数人のレビュワーがいた場合、自分が見ることを分かるようにする意図もあります。
これをすることで、他のレビュワーが忙しいときは「あ、◯◯さんが見てくれてるから滞ってない」と安心してもらえます。

B. レビューの難易度を判断する

私がレビューを受け取ってからすぐにするのは下記の2点です。

  • issueの内容と振られているweightを確認する
  • diffのファイル数を確認する
    • diffが多くてもcommitが綺麗に分割されてるか確認する(diff多くてcommit分割されてなかったら難易度高め)

C. 分からないことを宣言する

正直、自分が分からないレビューを依頼されることもあります。
そのとき 「レビュワーは自分。自分がボールを持っている」というマインドは大事です。
そのままレビューを放置すると、それだけユーザーに価値を届ける時間が長くなるだけです。

いっそのこと、これを学習の機会だー!と割り切ってしまいます。
例えば

  • コメントに「これ、分からないので教えてください」と書く
  • 時間あったら説明してもらう(そのとき、他にも分からない人を誘えば属人化の解消にもなる!ラッキー)

とか。楽観的にいきましょう!! :relaxed:

コードレビューを放置したとき、レビュイーに与える影響は良くない

  • レビュイーはコードを書いた後、時間がたつほど記憶が薄れてしまいます。そのため、指摘された内容の修正に時間がかかりやすくなります(スイッチングコスト高い)
    • 仕掛り1個、レビュー中 10個 とか地獄じゃない?( 9個ならいいって?そんなバカな)
  • コンフリクトの確率が高まる
    • merge/rebaseなどできればしたくない
    • ウギャーってなることありますよね?それを自分が招きたくないなぁ

おまけ

レビュー早いとチームの雰囲気が良くなります
帰る時に「今日もいい仕事した〜!おわったぁ〜!」という気持ちが高まるからかな?

93
41
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
93
41