より良いコードレビュー時間にするために、レビューイができること　2つの事前準備とレビューを受ける時の3つの心構え

遠藤氏の自己紹介

遠藤光敏氏（以下、遠藤）：では発表を始めていきたいと思います。タイトルは「コードレビューを受ける新人の心構えと準備」と、ちょっと堅めなタイトルですが、内容としてはとてもやりやすい、ハウツーに近いものになっているので、気軽に聞いてもらえればなと思います。

簡単な自己紹介をします。本名は遠藤光敏といいまして、「えんどう」の「どう」を取って「dosan」という名前で呼ばれているので、「dosan」と書いています。

現在、26歳で、先ほど発表した橋本さん（橋本遼太氏）と同じく2022年の4月にソニックガーデンに入社して、岡山で働いています。趣味はコーヒーとゲームで、ゲームはもっぱらスマホゲームばっかりやっていまして、『Fate』とか『OCTOPATH TRAVELER』『原神』とかをやっています。コーヒーは飲むのも淹れるのも好きで、毎日オフィスのみんなに振る舞っています。

レビューは採点ではなく、コードをより良くしていくためのもの

最初に、今回のLTで伝えたいことを言わせてもらおうかなと思っています。それは「いいコードレビューにするためにレビューイもできることがあるぜ」ということです。

動機ですが、入社した当初、もともとはレビューを受けるのがとても怖くて、「なんて言われるんだろう？」「こんなコードを書くなんて、こいつは駄目なやつだ」「見込みがないな」と思われるのがちょっと嫌で、恐る恐る出していました。

でも途中で、レビューってテストとか採点といったものじゃないんだな、ということに気づきました。レビューは、一方的にレビューを受けて終わり、採点されて「はい、ここは駄目」「はい、やり直し」と一方的に採点されるものではなくて、レビューイとレビュアーでそのコードをより良くしていくためのものだということに気づき、それからレビューが怖くなくなったというか、「どんと来い」「むしろ自分が成長するための機会なんだな」となったので、今回このLTをさせていただいています。

内容ですが、具体的なハウツーに近いことを言おうかなと思っていて、レビューを受けるまでの準備と、実際にレビューを受ける時の心構えみたいなことを話していこうかなと思っています。

レビューを受けるまでの準備

まずは準備ですね。「同じレビューをされない」ということからです。「同じレビューって、具体的にどういうことなんじゃい？」ということですが、こういうものですね。「不要な改行」「空行いらない」「2行あけてるのなんで？」と。この場合は「要らない空行は書かないようにしようね」ということです。

これは、レビュアーの負担をできる限り減らしましょうということです。これは実際にどういうデメリットがあるのかというと、同じことを何回も何回も指摘することで、単純にレビューにかかる時間が増えちゃうというのと、同じ指摘のほうに気を取られて、本当に指摘しなくちゃいけない重要な指摘箇所を見落としてしまう可能性があります。

実際にこういう同じレビューは凡ミスがけっこう多いと思っていて。例えばRubyやRailsでいうと、orderをつけ忘れている。括弧、波括弧の最初と最後の空白が揃っていない。あとはシングルクォートとダブルクォートがごっちゃになってしまっている。

自分でも気づけるようなことがけっこう多いのかなと思っていて。それは、セルフレビューでプルリクエストを作る前に防いでいこうという話です。

もう1つが、自分以外のレビューを見ること。先ほどの発表者の方も言っていたと思いますが、会社なら、同期だったり後輩や1年下とか。レベルが近いので読みやすいし、お互いにレビューするというのもありだなと思っています。実際にソニックガーデンでは同期入社、例えば自分と橋本でお互いレビューし合ったりしています。

「その指摘、自分も踏む可能性がありますよ」と。次はあなたの番かもしれません。そういう話です。

レビューを受ける時の心構え

準備の2つが終わり、次は心構えのほうに入りたいと思います。

1つ目です。コメントの口調は気にしないことです。もしかしたら、あなたのもとにこんなコメントが飛んでくるかもしれません。（スライドに表示された）こういうコメントだったり、こういうコメントだったり。「消して」とかね。

弊社のコメントから極めて作為的に選んで、文脈とか全部無視して、きつく見えるような言葉だけを選んで取ってきたので、そこまで心配しないでいほしいんですが、こういったコメントが来ても気にしないということですね。

レビュアーの方も、レビューイを攻撃したいわけではないということと、あとは働きながらレビューをしているので、忙しかったりすると口調まで気にかけられなかったりすることも当然あります。

働いていく中で信頼関係ができてきたりすると、慣れていきます。「言葉ではこうだけど実際には怒ってはいないんだな」ということがなんとなくわかってくるので、必要以上に怖がることはないです。

実際にレビューをする側に回っていくと、こういう言葉遣いにちょっとずつ近づきがちなことに自分でも気づくので。それはお互いさまなので大丈夫だということです。

心構えの最後ですね。先ほどの発表者の方も言っていたと思いますが、「なぜ」を考えようということです。

（スライドを示して）例えばこういうコードがあったとします。これはビューですね。ビューにこういうコードがあったとします。userのロールに合わせて表示するもの。adminだったら管理者、advisorだったらアドバイザー、otherだったらotherみたいに変えるといった時。

こういうコメントが来たとします。「モデルにメソッドを作ったほうがいいよ」と。「わかりました。モデルにメソッドを作ります」。adminなら管理者、advisorだったらアドバイザー、mentorはメンターで、その他。

結果としてビューがすっきりとした3行に収まりました。

比較するとこんな感じ。

めでたしめでたし、ではないということですね。このままでもいいんですが、このままだとすごくもったいない。まったく同じ場合にしか使えない、もしくは近い場合にしか使えないので、「なぜこのレビューを受けたのか」を考えましょうということです。

例えば今回の場合だと、ビューの構造がわかりづらい。ビューにそのまま処理のロジックを書いてしまうと、コードがわかりづらくなったり、テストが書きにくくなったりしてしまう。

抽象度を上げて自分のストックにしていこう。別のパターン、例えばビューにロジックを書いた時に、自分で「あっ、これはモデルにまとめたほうがいいな」とか気づけるようにしようということですね。

いいコードレビューにするために、レビューイもできることがある

最後にまとめになります。「準備」と「心構え」の大きく2つに分けて、それぞれで同じレビューをされない、自分以外のレビューを見る、コメントの口調は気にしない、「なぜ」を汲み取るという4つを発表しました。

最後に言いたいことをもう一度お伝えします。「レビューイもできることがあります」ということです。ご清聴いただきありがとうございました。以上で終わります。