めるノート

一児の母 兼 へっぽこWebエンジニアの内省ノート

コードレビューを受けるのがつらくなったときは

そういうときがよくあります。
コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。

「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。

anond.hatelabo.jp

さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。

私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？

刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をまとめておきます。

www.slideshare.net

ソニックガーデンの方です。
7つの秘訣は、

  1. レビューの観点を明確にすること
  2. 我が身に返ることを恐れずに指摘すること
  3. 何故悪いコードなのかを論理的に説明すること
  4. 良いコードについて共通認識を持つこと
  5. 小さい単位でレビューを繰り返すこと
  6. 指摘は素直な気持ちで受け入れること
  7. 指摘は人格否定でないことを理解すること

レビューを受ける立場として、6と7は「あっ、そうだよな」と自身の未熟さに気づいたところがありました。
一方で、1や4のような、共通認識とか、前提としての観点っていうのもあまり明確でないことがあるので、それは自分からある程度提示したり、問題提起したりで改善できそうです。

speakerdeck.com

ペパボの方で、新卒のメンバーに向けてお話されたそう。「コードレビューのやり方」な話です。
勉強会などでよくペパボの方を見かけますが、ほんと、いい会社なんだなあ、という感じがします。

印象に残ったところだけ、かいつまんでしまいますが、
（主に新卒など駆け出しのエンジニアが）コードレビューをやる上で大切なのは、コードを読んで理解することだそうで、

  1. なんでこうなっているのか？を考えながらコードを読む
  2. わからないところがあると悩む
  3. 10分悩んだら自分ではわからないと判断して聞く

この「なんで・悩む・聞く」を繰り返すとできるようになる、とのことでした。

あとはコードレビューは「伝え方が9割」ということで

  1. 理由を書く
  2. 褒める
  3. 提案する
  4. 提案にも理由を書く
  5. コードで示す

ただし、このへんは上級者じゃないと難しいかも？だけど、LGTM画像、絵文字、顔文字で「めでたく」盛り上げることはできるよね、という感じでシメられていました。

ここからは自分の感想になりますが、コードレビューはとてもデリケートだから、レビュアーはいろんなこと意識しないといけないなって思いました。
指摘されたとき、レビューイ側は「じゃあどうすればいいの！」ってなっちゃうとき、ありますもんね。

LGTM画像については、以下の記事でも「叩かれすぎて凹む問題」で取り上げられていました。
http://ogihara-ryo.herokuapp.com/blogs/1

あとは、まあ、やっぱり「悩んだら聞く」ことが大事だなと。
自分もレビュアー側のとき、さっぱり分からずチンプンカンプンだったらレビューイに聞くようにしてます。当たり前ですがｗ

レビュアー側が「聞く」ことは初心者じゃなくても大事だということで、以下の記事でも取り上げられていました。

qiita.com

そして、レビューイ側も「聞く」ことが大事だと、以下の記事で取り上げられていました。

blog.sushi.money

レビューイ側としても「悩んだら聞く」こと、痛いほど、わかっているんですよね。。。
ちょっとしたCSSの設計とか、エラーハンドリングとか、書く前に相談すれば間違いないんですよね。

techblog.timers-inc.com

この記事で良いなって思ったのは「修正対応の有無はハッキリと」のところです。
MUST・THINK・INFO・TRIVIALなど、修正対応の必要性がわかると、自分がレビューイだったら嬉しいなーと思いました！今度やってみよっと。

よーし、いろいろ見てたら楽しくなってきたぞ。

www.chirashiura.com

わかるわかる！と読んでいたら、存じている方の2年前の記事でした。
すごい人だなぁ、と思っていたので、誰もが最初はそうなんだな、とも思えて、元気が出ました。笑

変数やクラス名について批判されるのもなんだかセンスがないと言われているようで辛い。

これもあるある！な感じで、こういうものこそ、具体的な提案とその理由がほしいですよね。

qiita.com

この記事くらいちゃんと説明してくれないと、エラーが出たりパフォーマンスに関わる問題じゃないので、センスとか才能の問題なのかな？ってなっちゃって、違うと分かっていても、自分を否定されたような気持ちになっちゃいますよね。

ということで、いくつか記事や資料を挙げてきました。

コードレビューがつらくなっちゃうときは誰しもあるけれど、だからこそ、自分が担当するレビューイにはそんな思いをさせないよう、つらさを胸に刻みながら、精一杯相手のことを思ってレビューしよう、という感じでしょうか。
将来、後輩ができたときには「わかりやすくてやさしいから、あのひとにレビューされたい」って思われたらいいなあ。うん。