レビュー疲れをなくそう
みんなレビューイーであり、みんなレビューワーでもあります。
互いに負担をかけ合って「レビュー疲れるんだけど...」みたいなことにならないように、レビューイーの行動で変えられるポイントをまとめてみました。(もっとあるかな？とりあえず思いついたものを10選)
※Githubでのプルリクレビューを基本としていますが、違うツールややり方でも応用できる話だと思います。
1. 伝えよう: そもそもどんな業務？
レビューワーは(そのコードで実現する)業務に詳しいとは限らないので、軽くでも概要があると良いでしょう。
自分がレビューワーのとき「業務わかんないからレビューできない/しづらい」って思ったことないですか？(^^
2. 伝えよう: 何がきっかけで実装した？
そもそもなんでこの実装/修正をしたのか？きっかけの説明があると「だからこう実装してるのか」ってのが理解しやすいものです。
特に既存プログラムの修正プルリクとかだと、そのきっかけによって「どのぐらいの仕上がりが適切か？」などのアクセルの踏み具合も変わり、レビュー指摘の判断も変わってくるんですね。
例えば、緊急バグ修正だったらレビューも全然変わりますよね(^^。
3. 伝えよう: レビューポイントは？
(どのチェックをして欲しい？)
A. 業務を満たしているか？ (業務チェック)
B. 正常に動作しそうかどうか？ (動作チェック)
C. コードの書き方的に適切かどうか？ (コードチェック)
D. パフォーマンス問題ないかどうか？ (パフォーマンスチェック)
(どのファイルを見て欲しい？)
S. すべてのファイル？
T. 一部のファイル？
4. 伝えよう: いつまでにレビュー？
明日にでもマージしないといけないものなのか？
1,2週間くらいじっくりレビューで良いのか？
レビューワーの隙間時間の調整に関わるので、ここはできるだけ明確だとやりやすいですね。みんな自分の実装仕事を持ってますから。
5. プルリクがデカすぎないように
100枚の書類をボンっと机に置いて
「これ見ておいてください！」
にならないように笑
難しいですけどね、関連してるものがどうしても多いとかもあるし。その場合は、概要欄で修正ファイルの全体像を説明するとか、そういった工夫も。(あとコミット単位による工夫も？)
また、プルリクレビューの前に予測できてる課題に関しては、レビュー前レビューで意識合わせしておくとかも大切だと思います。
// 別に、プルリクレビューの前にレビューしてもらっていいんだからね
https://jflute.hatenadiary.jp/entry/20170630/reviewbefore
6. コミット単位とコミットコメントしっかり
レビューワーがコードを追うのに、コミット単位で見ることもあります。
コミットコメントで複数のコミットから探すこともあります。
特に指摘後の修正確認のために修正コミットを探すことが多いでしょう。
レビューワーが迷子にならないようにケアしましょう。
※余談ですが、「修正しました」のコメントと一緒にコミットリンクを貼る現場もあるようですね。少しレビューイーの面倒さはありますが、レビューワーとしては助かります。
(このへんGithubでもうちょい自動化できないだろうか？^^)
7. やり取りマネジメントしっかり
特に複数人レビューワーがいると、コメントなどがガチャガチャしがちです。だんだんプルリク見づらくなってきますし、どのスレッドがどういう状態にあるのか？などなど把握が難しくなってきます。
レビューワーは、プルリク全体のことを把握できませんから、それを抜けなく適切に対処できるのはレビューイーだけです。Githubだと、Resolve Conversationなどうまく使ったりして、プルリク内の小課題の管理をしっかりやりましょう。
レビューワーの指摘コメントに気づかず無視してしまうとかないように気をつけましょう。
8. コードに背景コメントを
コードの中の話です。最初からわかりやすいコードになっていれば世話ないですが...
なかなかそうならないから、みんなでコードレビューをするわけです。
なので、わかりにくいコードは仕方ない。でもせめて背景コメントがあれば、レビューワーがそれを見て判断がしやすくなります。
そもそも背景がわからないと「コードがわかりにくいかどうかもわからない」ものだったりします。背景コメントがあることで、「もっとこう書いたら良いんじゃないか？」ってのが言いやすくなるのです。
また、背景コメントを書く段階で自分で気づけるかもしれません。それに越したことはないですよね。
// オートマティックおうむ返しコメントより背景や理由を
https://jflute.hatenadiary.jp/entry/20180625/repeatablecomment
気の利いたレビューワーだと背景を質問して背景を探ってから指摘してくれたりしますが、それはそもそも将来コード読む人も知りたいことかもしれませんので。
// プルリクであれこれ説明するならコードにコメントに書こう
https://jflute.hatenadiary.jp/entry/20181016/pulcomment
9. レビューワーに感謝の気持ちを
まず、見てもらってることに感謝。気持ちの表明の仕方はみなさんそれぞれ。
せめて気持ちを忘れないだけでも、どこかににじみ出るものです。
そして、(レビュー内容が厳しくても)指摘してもらったことに感謝。
良かれと思って指摘してもらっていますから、イヤがらず感謝...
いやいや、イヤがってもいいので感謝の気持ちは忘れずに笑
例えば、指摘もらったけど「今回は直さない」とか「ちょっと的外れな指摘だった」という判断したとしても、指摘してもらったこと自体にはしっかり感謝を。
自分がレビューワーになったときのことを考えれば、自然とそういう気持ちになるかと思いますので。
10. 自己レビューしてからレビュー依頼を
「書いた、たぶん動く、(見直さず)レビューお願いしまーす」
って感じだと、低レベルな指摘ばかりだとレビューワーも疲れてしまいます。
レビューワーはコンパイラーではありません。
レビューの仕組みがあるからといって、自己レビューを飛ばして良いわけではありません。作り手の矜持としては、レビューの仕組みがあろうがなかろうが、自己レビューをして自分の中で最高のものとして仕上げましょう。
レビュー文化の維持のために
レビューし合ってリリースをするというのが、身の回りではだいぶ当たり前になってきました。とても良いことだと感じています。
一方で、現場でヒアリングすると...
o レビューワーつらい (自分の仕事が...)
o レビュー依頼が置き去りにされやすい
などなど、精一杯感のある話もちょくちょく耳にします。
jflute自身もレビューイーにもなればレビューワーにもなります。
レビューワーの時に大変だなって思ったのは、今回述べたようなポイントなのですね。一方で、自分がレビューイーになったら気をつけなきゃって思うのです。(はぁ、ブログ書いちゃったからには気をつけないとって自分プレッシャー＞＜)
ある程度、レビューワーとの距離感や関係性で程度は変わると思いますが、レビューイーするときのポイントとして参考になればと。
楽しくレビューで助け合いができると良いですね(^^
...
【追記】現場からフィードバック頂きました。
共感できること一杯という声に加えて...
o コメントは1日以上空けずに反応するチーム意識がある
→ なるほど、素晴らしい
o 気の知れたメンバーなら伝えること省略することもある
→ 十分わかり合ってる人同士ならそれでいいですよね
o レビュー期限を書くルールにしてる
→ ルールにしちゃうのが一番世話ないでしょう
o 指摘に対応しないにしてもコメントあると嬉しい
→ 反応なしでマージされちゃうとやっぱり悲しいとのこと。
「これこれこういう理由で対応せずに進めます。指摘はありがとうです！」
みたいな一言あるとないとで全然違いますね。
...
逆もきっとありますよね。
「レビューイーに好かれるレビューワーとは？」
気が向いたら書くかも？(^^
