コードレビューを行う時に意識したいこと を読んで、僕らのチームでコードレビューするときにしている工夫と、それをやって良かったことを書きました。

コメントにラベルを付ける

GitHubでテキストベースでのコードレビューするにあたって私達のチームでは以下のようにレビュー指摘コメントにラベルをつける事にしています。

• [MUST] 必ず直すべき良くないコードに。

• [IMO] 私はこう思います。こうした方が良いのでは？ 意見や緩やかな指摘。

• [nits]ほんの小さな指摘。インデントミスなど細かいところに。

例:

[MUST] publicではなくprotectedの方が良いな。
[MUST] ここでエラーになったらどうなるの？

[IMO] ここはメソッドに分けた方が良いですね。
[IMO] array_mergeより+=が良さそう。

[nits] インデントがズレてるよ！！

まず、上記のようなありがち?なコメントにラベルをつけて見ました。
このラベルをつける事によって以下のような良い事がありました。

レビュイー(レビュー受ける側)

• レビュワーの温度感を文章から汲み取る必要がない
• コメント対応の優先度をつけることが出来る
• 納期が迫っている場合、まずは[MUST]だけ対応してリリースを行う等の判断材料になる

レビュワー(レビューする側)

• 相手に誤解されないような文章を考える手間が減る
• 相手を傷付けないように気を使う手間が減る
• 相手にどのように直して欲しいのかを具体的にまた理由を添えて書く意識を持てる

何かとコミュニケーションコストについて課題の多いコードレビューですが、この小さな工夫だけで、時間的、精神的にも負担が減ったと感じています。

例にはあえて曖昧なコメントを載せました。

もし、ラベルがなかったら、「〜が良いかな」という表現は優先度が低そう、「！！」が付いているからここは直さないと等、レビュワーの意図とは違うニュアンスで伝わってしまう可能性があります。

コメントする側も[MUST]というラベルを付けることによって、

[MUST] publicではなくprotectedの方が良いな。

　⬇

[MUST] このプロパティはprotectedにすべきです。なぜなら◯◯だから。

のような書き方に変わっていき、ここを絶対に直して欲しいのか、あるいは別のより良い方法を共有したいのか、ただのボヤキなのか等を意識し易くなります。そのように責任を持ってコメントすることにより、先程書いたとおりレビュイーの負担も大きく減ると考えています。

注意

• ラベルの数はあまり増やさないほうが良い
  チームに最適なラベルを設定するべきですが、あまり増やしすぎるとラベルの境界線の定義が曖昧になるので、これどのラベルかな、と無駄な思考が働いてしまうし覚えられない
• ルールではない
  これは工夫であってルールではありません。 質問のときはどのラベル？とかも面倒なので明らかに質問と分かればあえて専用のラベルを作る必要は無いと考えています。伝われば良いんです。

ちなみにこの投稿で書いた事は [IMO] です。

参考

こちらのスライドは他にもプルリクエストについて面白い事が書いてあるのでリンクさせていただきます。
pull request を利用した開発ワークフロー by Yuichi Tateno