心が穏やかな時にやる
1日の終わり際にレビューするのはしんどいので次の日の朝にやる
レビューはストレスフルなので無理しない
レビューリクエストを受けたらできる限りすぐにレビューする
自分の作業への割り込みになってもすぐにやる
理由
レビュイーの作業をブロックしないため
お互いの記憶が薄れる前に議論するため
他のブランチとの差分が広がる前にマージするため
指摘の理由を言う
こうして下さい、だけではなく、これだとこういう問題があるのでこうして下さい
次のアクションを明確にする
これだとこの部分がこういう(悪い)状態になってます、だけじゃなくて、こういう状態だからこうしましょうという
指示の内容も具体的にする
コードが頭に浮かんでいるならそれを書く
手抜きして曖昧な指示をしない。自分の意思は思っているよりも伝わらない
曖昧性を除去する
代名詞をなるべく使わない
普通の文章として変でも明確であることを重視する
論文を書くときと同じ
プロダクトやコード品質の改善につながることだけを指摘する
Bike shedding しない
for 文じゃなくて map を使いましょうみたいなどうでもいいことは指摘しない
もちろん、より良い書き方があると情報提供するのは良いが、直す直さないの議論に持っていかない
個人によって価値観が違うものは議論するだけ時間の無駄なのでやらない
どうしても白黒つけたいならコーディングガイドライン 、Linter や Formatter のルールで決める。レビューでやらない
直接話す手間を惜しまない
そもそも想定していた実装の方向性が違うときなどはテキストで言っても伝わらないのでちゃんと話す
レビュイーに対して要求があるなら言う
もっと細かく分割して欲しいなど