#はじめに
コードレビュー時にレビュワー(レビューする側)とレビュイー(レビュー受ける側)の間のコミュニケーションが大事になる。
お互い誤解され無いことや相手に対して自分が言いたいこと明確にするため、うまくコミニュケーションする必要がる。
##レビューコメントにラベルを付ける
レビュー指摘の意味を簡単に小文字で伝わるため、以下の用にコメントの前にラベルを使用しましょう。
| ラベル | 意味 |
|---|---|
| [MUST] | 必ず対応してほしい！ |
| [IMO] | 自分の意見や提案・好み。 自分ならこう書くけどどうかな？「In My Opinion」の略です |
| [IMHO] | 私なんかがごめんね、私個人の意見なんですけど「In My Humble Opinion」の略です |
| [nits] | 些細な指摘。 ほんの小さな指摘だけど出来れば直してほしい。インデントやタイポ |
| [ASK] / [Q] | 質問,確認。 コードの意味や背景が分からないから教えて！こういう理解でOK? |
| [FYI] | 「参考までに」って感じで参考リンクなどをつける場合によく見かけます「For Your Information」の略です |
| [typo] | これはタイプミス(スペルミス)ですね |
| [WFM] | 私のところでは動いている「Works For Me」の略です |
| [NP] | 全然大丈夫だから気にしないで「No Problem」の略です |
| [AFAIK] | 私が知る限りでは「As Far As I Know」の略です |
##レビューコメントを相手心を傷つけないように書く
人間関係の衝突をHRTを考慮することで避けることが可能になる
HRTとは
HRTとは謙虚（Humility）、尊敬（Respect）、信頼（Trust）のそれぞれの頭文字三文字をとった言葉だ。読み方は「ハート(heart)」というらしい。それぞれの用語を解説する。
謙虚（Humility）
**世界の中心は君ではない。**君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善しよう。
尊敬（Respect）
**一緒に働く人のことを心から思いやろう。**相手を一人の人間として扱い、その能力や功績を高く評価しよう。
信頼（Trust）
**自分以外の人は有能であり、正しいことをすると信じよう。**そうすれば仕事を自分以外の誰かに任せることができる（ただし無能な人には任せるのは難しい）。
コードレビューとHRT
GitHubなどで文章によるコードレビューは容易に人の心を傷つける。具体的にはコードに対する批判を人に対する批判（人格否定）だと受け取ったり、文章だと感情が伝わりづらく何気ないレビューコメントが「怒ってそう」「高圧的で怖い」などと受け取られたりことがあり得る。それにGitHubなどプロジェクトに関わっている全員に公開されるのでレビュイーが恥ずかしくなる場合もある。
そこで、コードレビュー時には上述したようなすれ違いが起きないように、なるべく気をつけてHRTな振る舞いをするようにした方が良いと思う。
-
説明するのが難しい、または長くなる場合、コードスニペット使用する
- 言葉で説明することが難しい複雑のこと説明したり、その説明に長く文章を書くことになる場合は、出来るだけ簡単コードスニペッを書いた方が、言葉より意見を通知やすいと思うます。
- レビューワーが話している内容の未経験者のエンジニアに対してはそれを教えて上げる方法にもなる
-
レビューワーに対して感謝の気持ちを伝える
- レビューワーが自分の期間を使用して、レビュイーがどの方にコードをどの理由で書いているかを想像しながら、レビューしているので、自分のコードをレビューして上げることに関して感謝の気もしを伝えた方が良いでしょう。
-
レビューワーの重要なコメント・指摘対して反応しましょう
- レビューがコメントしていることをレビュイー見ていることをレビューワーに対して伝えるため、絵文字や返事コメントで答えたら、レビューワーも自分の指摘がちゃんと見ていることに安心されると思う。
-
絵文字を使う😃
- 絵文字を駆使して感情を伝える。フレンドリーさを演出する
- その結果感情の誤読は減り、コミュニケーションはより活発になる
-
断定口調は使わない
- 「〜のほうが良い」「〜はダメ」という断定は自分が間違っている可能性を否定しているので 謙虚さ に欠ける
- 「〜のほうが良いと思っているのですがどうでしょうか」などと相手の反論の余地を残してやるべき
- なにか断定したいのであれば少なくともレビュイーが納得できるに足る理由を上げるべき
-
命令ではなく提案
-「〜に変更してください」という命令は相手のコードを 尊敬 していないし 信頼 していないように聞こえる- 命令でなく「〜と書いてみるのはいかがでしょう？」という提案に形式を変えてみるとよい
- 断定同様にきちんと理由も述べる
-
強い言葉を使わない（弱くみえるぞ？）
- 「クソコード」などの強い言葉は使わない。相手への 尊敬 が全くないのでNG
- 強い言葉を使いたくなるような場面だとコードレビューでのすれ違いが起きる可能性が高いので口頭でカバーするのが吉
##PR（Pull Request）をApproveの時に面白いイメージを使用する
PRをApprove時に普通に**LGTM（Looks Good To Me)**と記載することが多いですが、指摘数が多いや繰り返し修正してレビュイーの心を落ちている場合や疲れている場合が良くありと思う。そこで相手の心を楽しくするような面白いGIFイメージ等を使用することで疲れを消すことが出来ると思うので、面白いGIFを使って見よう。
https://lgtm.fun/#gsc.tab=0
https://lgtmoon.herokuapp.com/
https://giphy.com/
##まとめ
コードレビュー時に上記のポイントを考慮しながら、コメント記載することで、良いコミュニケーションが取れて、お互い人間関係が良くなって、誤解や心を傷つけることを減り効率を上げることが可能と思う。
##参考リンク
『Team Geek』読んだ ~HRT(謙虚/尊敬/信頼)の精神を知り会社でサバイブしていく方法~
コードレビューを効率化するちょっとした工夫
アンチパターンから学ぶHRTなコードレビュー
GitHubなどで見かける、LGTM/WIP/IMHOみたいな英語の略語集