自分なりのレビューの考え方と進め方
リモートで直接相手の顔が見えない環境で働くことが多くなっていて、それでもできるだけコミュニケーションを円滑にするための自分なりの考え方と進め方。
なにかすごいことをする訳ではなく、小さなことをあたりまえにできるように意識していきたい。
前提にある思想
- 会社のプロダクトの場合、全て自分が思う通りのコードにすることが正しい訳ではない。
- レビューは間違い探してはなく、仕様や知識の共有のためにやっている。
- レビューをリアルタイムで気付けるように、 Pull Reminders: Pull request reminders for Slack & GitHub などで通知を受けられるようにしておく。人間が意識する必要がある物事は減らしたい。
レビューを出すとき
- テンプレがない場合はテンプレを用意する。
- レビュー依頼前にGitHub上でざっと全体をセルフレビューする。
- レビュワーが読みやすいように、特別な仕様がある場合は
Single Comment
で補足する。 - レビュー期限は必ず書く。いつでもいい時は「お手すき」ではなく余裕を持った期限を書く。
レビュー依頼が来たとき
- 手が離せない作業をしていない限りは、まずはざっと5分ぐらいでPRの内容を見る。
- レビューを依頼した側は、また別の開発に入るため、できるだけコンテキストを忘れないうちにやり取りした方が早い。
- 方向性が違ってるなと思ったら、全体を詳細に見る前に、そのすり合わせをする。
- 問題がなさそうな差分ファイルは、ガンガン非表示にして、重視して見るべきファイルを絞る。GitHubのViewdフラグ使いやすい。
- 時間がかかりそうで後回しにしたものは、作業のキリの良いタイミングを作るか、翌日最初のタスクとしてレビューする。
- すぐ見切れないもの=差分の大きいものとなる可能性が高いので、遅くとも締め切りの3日前にはレビューを初める。初められるようにしたい。
レビューにコメントをするとき
- 良いと思ったこと
- 褒めてもらえると嬉しいので「勉強になった」とか「LGTM」とかGitHubのリアクションとか何かしらのアクションをする。
- もっといい方法があると思ったこと
- 「〇〇だと嬉しいです。」「〇〇だとありがたいです。」は曖昧になってしまうため、使わない。
- お願いがあるときは率直に「〇〇をお願いします。」と書く。
- 疑問に思ったこと
- 「〇〇だと思うんですが、どうですか?」と、認識のすり合わせを意識する。
- 間違っていると思ったこと
- 否定をしない。お互いに認識できていない何かがあるのかもしれない。
- 疑問に思ったこと、と同じ方法を取る。
- もしくは、具体的なイメージが自分の中にあればコードのイメージも伝える。コピペしたら動くコードではなく
// ここでxxxを呼び出す
みたいなのでも良いと思う。
- GitHubの場合、レビューとしてコメントを付け、完了したらPRのステータスは
Comment, Approve, Request Changes
のどれかに変更する。- ステータスを変えることで、レビュイーが再度変更したときに
Re-Request
しやすい。 Single Comment
は会話しなくていいものにしか使わない。
- ステータスを変えることで、レビュイーが再度変更したときに
1日レビューをしているだけで終わることがあるなと思ったとき
- レビューも立派な仕事の1つということを忘れない。
- 自分の持っているタスクの優先度やレビュー依頼の締め切りを見つめ直す。
- 自分のタスクの優先度が高いときは、予めレビュー依頼が来たときに、「遅くなるかもしれない」と伝える。
備考
SHIROBAKO 瀬川さんの
- 「クリエイターには関わった話数一本一本が名刺代わりってこと。流して描く作品なんて無いってこと。」
- 「きっともう少ししたら安原さんも普通にできるようになることなんだよ。自分の後の工程のことを考えて描くなんてことは。でも今はまだわからない。わからないからできない。ちょっとの違いなんだけどね。」
というセリフ、大好きです。このセリフを聞いてから、圧倒的に考えの幅が広がった気がする。