💞

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

2022/03/18に公開約2,400字3件のコメント

こんにちはnasaちゃんです。

コードレビューの記事を見かけたので僕がコードレビュー時に考えていること、行っていることを書いてみようと思いました。

https://qiita.com/emjo1804/items/48f6e78237a04684ab38

この記事ではレビューを受ける側、行なう側それぞれの話がありましたが、ここではレビューを行なう側のことを書いていきます。(洗い出してみるとすべてがレビューコメントに関するものでした。)

Whyを書く

コードの変更をリクエストする際になぜ変更したほうが良いのかを書くようにしています。
レビュイーが変更を取り込むか判断する材料になるのでちゃんとなぜこっちのコードのほうが望ましいのかを書くようにしています。あと、言語化することで自分の理解も深まるので良いですね。

このとき、レビュー中のコードを批判しないことを心がけています。
「今のコードは〇〇というデメリットがあるので変えたほうが良い」と伝えるよりも「このような書き方をすることで〇〇がよくなると思いました💡」という伝え方をするようにしています。

レビューでは「悪いコードを直していく」という考え方よりも「コードをより良くするもの」と捉えることでお互いに気持ち良いコミュニケーションが出来ると思っていますし、結果コードがどんどん良くなると考えています。

お気持ち度合いをコメントする

nitsとかimoとかありますよね。あれをちゃんと書くのは重要だと思っています。
imo(私個人の意見です)と明記しておくことでレビュイーが不要だと思った議論をスキップすることができます。
リリースまでの速度を維持しつつどんな些細なことでもコメントできるのでどれくらいのお気持ちなのか明記するといいなーと感じています。

関連する話で、いつやってほしいのかも明記するようにしています。
ここの温度感のすり合わせができていないと1つのPRに時間を書けすぎてリリースが遅くなってしまうので、リリース後にやってほしいことや、負債返済日にやってほしいこと、将来的にはこうしたいねーなど時間軸を明確にしつつコメントするようにしています。

自分の感想や理解を書く

お気持ち度合いを明確にするのと似ていますが、コードを読んで理解したことや感想を書くようにしています。

例えば「この通知は現状iOSにしか送信しないが来週にはAndroidにも送る」といったコメントをしています。
これを残すことで仕様の細かいところ(例だと細かくないですが)をお互いすり合わせることができます。

実は漏れてたとか、実は仕様とずれちゃってたといったことが減ると思うので自分の理解を残しています。

あとは、PR descriptionに明記されていないオペレーションもコメントするようにしています。
DBマイグレーション必要だよねーとかこの部分モバイルやフロントエンドエンジニアと合意が必要だよねーなどがこれに該当します。

これらのコメントはやりすぎるとレビュイーにとってストレスになると思うので塩梅が難しいです。踏み込みすぎない程度に補助するというのを心がけてやっています。大きなお世話にならないようにしないと。。。

絵文字を結構使う 😀

テキストだけだと気持ちが伝わりづらいので絵文字を意識して使うようにしています。よく使う絵文字を紹介していこうと思います。

提案系だったら 💡をよく使いますね。
「Aという理由でこっちのほうが良さそうです 💡」といった感じですね。

あとよく使うのはこれら3つですね。 🙈 📝 💭
あちゃー!🙈 と思った時に見ざるを使っていますがこれは若干煽りっぽいですね。。
「ここ仕様とずれてそうです 🙈」という使い方をしています。

📝と💭は先程書いた感想や理解をコメントする時に使っています。

他にも意味もなく絵文字を使ったりしていますね。 🧋とかたまに使いますが、全く意味がない絵文字です。🦊

この意味もない絵文字はやる意味あるのかなーと思うこともあるんですが、まあ賑やかしでもしておくかと思って付与しています。上司も同期もこの意味ない絵文字についてコメントしてきた人は居ないので邪魔にはなっていないはず!知らんけど

無言〇〇は絶対にやらない

無言で何かを投稿するのは絶対にやらないようにしています。
例えばドキュメントやアンチパターンのリンクの投稿などですね。(余談ですが、僕はリンクを無言で投げつける行為を「リンクで殴る」と呼んでいます)

これは普通に治安が良くないのでやらないようにしています。やるという発想がそもそもないので意識している訳ではないですがやられて非常に嫌だったので取り上げてみました。

GitHubのsuggested changeも絶対に無言でやらないようにしています。

これは明確に理由やメリットが有るわけじゃないんですが、昔気に食わなかったので同じ轍は踏まないぞい!!ということでやらないようにしています。

捉え方次第なのでなんとも思わない、むしろ感謝する人もいるんですかね?
僕は「こう直せ!」と言われているように感じてしまいますね。。。


今回はレビュー時に気をつけていることを取り上げました。すべてがレビューコメントに関するものでしたね。(実際のレビューコメントを例として話せると良かったのですが業務に関するものばかりなのでサボりました)

コードを読むことにもフォーカスして書きたいなーと思いました。

ここまで読んでくれてありがとうございます。それではコードリーディング編でお会いしましょう(書くとは言ってないが、、、)

GitHubで編集を提案

Discussion

NITS

あとよく使うのはこれら3つですね。 🙈 📝 💭
あちゃー!🙈 と思った時に見ざるを使っていますがこれは若干煽りっぽいですね。。
「ここ仕様とずれてそうです 🙈」という使い方をしています。

🕵️や🔎(or 🔍)に変えると煽り成分が抜けると思いました!
ただ、

  • 「あちゃー!」ではなく「発見、気付き」という意味合いに変わってしまうかも
  • この例以外では変換不可の場合もあるかも

MUST

  • Why書くの最後の段落で、 typo を発見しました!🕵️
    「コードをより良くするのも」 -> 「コードをより良くするもの」
  • コメントを書いてて気付きましたが、見出しに脱字を発見しました🙈
    Why書く -> Whyを書く

おお。ありがとうございます!修正しました

ログインするとコメントできます