4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コードレビューで気をつけていること

Last updated at Posted at 2018-09-30

最近、コードレビューをする機会が増えてきています。
レビュールールではありませんが、回数を重ねるにつれて、自分なりに気をつけていることをまとめておきます。

最近使っているコード管理ツールは、Bitbucketgithub Enterpriseです。
いずれもブラウザ上でコードを確認でき、直接コメントが書けるツールです。

レビューア、レビューイという呼び方をするところもありますが、私は未だにどれがどちらか覚えられないので、分かりやすくレビューする側、実装者と呼ぶことにします。

実装者をリスペクトする

よくあるのが、初心者が書いたコードを経験者がレビューするケースです。
ですので、なんとなく実装者とレビューする側に上下関係が形成されて、ついつい上からの目線でレビューしがちです。

しかし、私はレビューする側とされる側には上下関係が存在しないと思っています。
リスペクトするからといって、別に常に実装者への敬意を意識する必要まではないですが、少なくとも上からの目線はやめるべきです。
実装者を見下ろしたレビューをしてしまうと、少なからずレビュー結果にその気持ちが反映されてしまいます。
そのレビューを読んでいる実装者の気持ちは想像できるはずです。

面白いレビューを心がける

結局レビューは文字を通して行うので、する側にとっては退屈な作業です。
もちろん、レビューを読んでいる実装者にとっても同様です。

ですので、私はちょっとしたユーモアをレビューに取り入れるようにしています。
例えば、

  • 隠しファイルについてコメントする場合は、「隠しておいてもバレましたね」とか
  • 処理の前後順序についてコメントする場合は、「鶏が先か卵が先か」とか

です。
レビューの文章を読んでいて、思わず笑ってしまいそうなユーモアがちょうど良いですね。

適度に絵文字を使う:blush:

レビューに感情表現を入れると、実装者に伝わりやすいのでオススメです。:thumbsup:
ただ、文字で伝えるのもなかなか難しいので、絵文字が良いですね。:love_letter:
コード管理ツールに絵文字機能があれば、ぜひ活用しましょう。:computer:
(↑で使っているのは、Qiitaの絵文字です。:sweat_smile:

レビューコメントにラベルを付ける

ラベルはコメントの意図を実装者にはっきり伝えるためのものです。
このラベルがないと、実装者はレビューコメントの意図を勘違いして、違う修正をしたりするので、無駄なやり取りが増える可能性があります。

もちろん実装者がコメントを返す際にも使えます。
よく見かけるラベルの他に、私自身が実際に使っているラベルも載せておきます。

[imo]

「In My Opinion」の略です。
「俺ならこう書くけど?」と相手に提案する気持ちを示す場合に付けます。

[suggest]

相手に提案する場合に付けます。
「こう書くのはどう?」と相手に提案する場合に付けます。
imoより、若干強い意味を持ちますが、それでも決定権は相手が持っている感じです。

[should]

こちらも相手に提案する場合に付けます。
「こう書きましょうか?」「こう書いた方がいい」と相手に提案する場合に付けます。
suggestより、もっと強い意味を持ち、直してほしい気持ちが強くなります。

[must]

「必ず直して」という意味合いです。
明らかに仕様と違う場合や、イケてない処理の場合に付けます。
ただ、このラベルは結構インパクトが強いので、私は成るべく使わないで、他のラベルで代用するようにしています。

[nits]

「nitpick」の略です。
細かい指摘をする場合に付けます。
例えば、コメントが違うとか、単語のスペルミスなど、どうでもいい指摘時に使います。

[ask]

素直に実装者に質問したい場合に付けます。
自分の意図とは違う実装になっていたり、実装が高度すぎて分からない時などです。

[liked]

「いいね」ですね。
Facebookなどで使う時をイメージすると分かりやすいでしょう。

[thanks]

実装者に感謝の意を表す場合に付けます。
最初から素晴らしい実装になっていたり、ついでに他のところも合わせて修正してくれたりした時に使います。

[sorry]

実装者に申し訳ない気持ちを伝える場合に付けます。
指摘の内容が間違っていたりして、実装者に手数をかけてしまった時などに使います。

[discuss]

正解のない実装方法について、実装者と議論し合いたい場合に付けます。
その後、どこかのタイミングで声をかけるかして、議論を進めます。

[laugh]

思わず笑ってしまいそうなことが起こった時に使います。
何らかの決めごとを忘れてコメントしたのに、実装者がコメント通りに対応してくれて、後でその間違いに気づいたら思わず笑っちゃいますよね。
そんな時に使います。

[god]

実装者が神対応した時に使います。
褒め言葉です。

※ 2024/07/05追記
テキストラベルより画像の方が分かりやすいので、アイコンをつけるようになりました。

github コメント ラベル

で検索してみると、サイトがヒットします。参考にしているサイトはこちらです。

最後に

レビューは一種のコミュニケーションだと私は思っています。
どうせなら気持ちよく分かりやすいレビューにした方が、お互いに嬉しいでしょう。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?