まとめ
コードレビューが早ければ早いほどチームのスループットは最大化する 
コードレビュー依頼されたときのフローチャート
現時点の私のマインドです。※今後、みなさんのフィードバックを得て更新することもあります。
心がけているいること
A. リアクションする
レビュー依頼されたらすぐにリアクションをします。
これは依頼者に「あ、レビュー依頼伝わってる」と安心してもらうためです。
これがないと、「気づいてるかな？」とモヤモヤさせてしまい、依頼者が集中できる環境を作ることができません。
また、複数人のレビュワーがいた場合、自分が見ることを分かるようにする意図もあります。
これをすることで、他のレビュワーが忙しいときは「あ、◯◯さんが見てくれてるから滞ってない」と安心してもらえます。
B. レビューの難易度を判断する
私がレビューを受け取ってからすぐにするのは下記の2点です。
- issueの内容と振られているweightを確認する
- diffのファイル数を確認する
- diffが多くてもcommitが綺麗に分割されてるか確認する（diff多くてcommit分割されてなかったら難易度高め）
C. 分からないことを宣言する
正直、自分が分からないレビューを依頼されることもあります。
そのとき 「レビュワーは自分。自分がボールを持っている」というマインドは大事です。
そのままレビューを放置すると、それだけユーザーに価値を届ける時間が長くなるだけです。
いっそのこと、これを学習の機会だー！と割り切ってしまいます。
例えば
- コメントに「これ、分からないので教えてください」と書く
- 時間あったら説明してもらう（そのとき、他にも分からない人を誘えば属人化の解消にもなる！ラッキー）
とか。楽観的にいきましょう！！ 
コードレビューを放置したとき、レビュイーに与える影響は良くない
- レビュイーはコードを書いた後、時間がたつほど記憶が薄れてしまいます。そのため、指摘された内容の修正に時間がかかりやすくなります（スイッチングコスト高い）
- 仕掛り1個、レビュー中 10個 とか地獄じゃない？（ 9個ならいいって？そんなバカな）
- コンフリクトの確率が高まる
- merge/rebaseなどできればしたくない
- ｳｷﾞｬｰってなることありますよね？それを自分が招きたくないなぁ
おまけ
レビュー早いとチームの雰囲気が良くなります
帰る時に「今日もいい仕事した〜！おわったぁ〜！」という気持ちが高まるからかな？