12月11日にソニックガーデン主催エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」に参加しました！
エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」
そのときの感想を記録しておきたいと思います。

はじめに

私は現在フィヨルドブートキャンプ（以下FBC）というプログラミングスクールで勉強しています。
FBCではプラクティスという学習工程の中で提出物をメンターさんに見ていただきレビューをもらいます。
私が経験しているレビューは、仕事でのコードレビューと完全に同じではないことをご了承ください。

LT

LTは共感できるポイントが多く、また自分を省みる良いきっかけになりました。
発表してくださったみなさんありがとうございました。
以下LTの感想です。
LTの内容で自分がメモしたところを書いていきます。
自分の感想は色を変えてあります。
途中に入れ込んでしまったので読みにくいですが、あえてそのように書かせていただきました。すみません。

samayou12 さん

「レビュアーとして成長するためには」

なぜレビュアーとして成長すべきか
- チームに貢献できる
  新人のうちはどうしても頼ることが多い
  新人にとってもコードレビューはgiveする手段の１つになる
  giveできていれば頼る時も申し訳なさが減る、自分のためにもなる

→ なるほどなぁと思いました。レビュアーとして成長することが自分のためにもなる、という意味が分かりやすく納得しました。

レビュアーとして成長するには：技術書とレビュー
技術書は自分の引き出しを増やす効果が大きい
ただし背伸びしすぎると効率が悪い
内容を理解できるが読むのが少し苦しい　くらいがちょうど良い

→ 今自分が参加しているぱRails輪読会はちょうど良いのかなと思えました
（理解できると言いきれるほど理解できているかは微妙ですが）

レビューを受ける/読む
レビューをもらったらまず意味を理解する、なぜそうなのかを理解したり議論することが大事
- 新人には難しい…なぜ？
  - レビュアーにとっては当たり前すぎて伝える必要がないと思っている情報がある（可能性がある）
  - そもそも何がわからないのか伝えないとレビュアーは何を教えるべきかわからない
    つまりレビューのコメントは完全なものではなく、時には自分で情報を取りにいく必要がある

→ レビューの意味を理解する必要がある理由や、自分から情報を取りにいく必要性が言語化されていて、「もっと情報を取りにいくようにしよう」と考えさせられました。

最初のうちはリアルタイムでレビューを受けると良い

→ これがよくメンターさんと受講生がやってるペアプロか！と思いました。私は提出物に関するペアプロをやったことがないのですが、直接のほうが意図を聞いたり質問したりしやすく時間もかからずいいなと思いました。またエディタの使い方とか直接的な技術以外のところも教えてもらえるというのは盲点でした。

自分がレビューする時は小さく始めよう、まず一行からわかるところから始める（一行単位のミス的なもの）
ここがわかりにくい、というコメントも役にたつ。新人でも理解できるコードはみんな理解できるコード

→ 自分はまだコードレビューする側はやったことないけれども、チーム開発になったら最初絶対焦るし一行目から必死に読んで集中力続かずみたいなLTの失敗例通りの展開になるのが目に見えるので、「小さく始める」は覚えておいていざ自分がやるときに意識したいです！

Nobo02149847 さん

「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」

気になることは質問する

→ 今回１番の共感＆反省ポイントでした！！！
悪い例としてあげられていた、
レビュアー「ここ修正してください」私「修正しました！」
が最近自分のプラクティスの提出物のレビューでとてもあてはまってしまっていたからです。
レビューの内容をよんで、確かにその通りだなぁと思って修正していますが、それだけでは本当に理解しておらず、他で活かせないことになってしまうので、
「なぜそのレビューを受けたのか、なぜ自分が書いたコードよりもレビューのコードの方が良いのか」をレビュアーに確認し理解することが大事とのことでした。
（私は〇〇の意図でこの実装にしました。こちらの方が適しているのは◎◎が理由でしょうか？、みたいな感じ）
それによって今後も応用が効くとおっしゃってました。
本当にその通りだなと。
最近プラクティスを早く終わらせたい気持ちが出てしまっていて、そのような部分が欠けているなと反省しました。
今後も使える知識にするために、そして就職後もレビューからたくさん学べるように、いまのうちにレビューに対する姿勢を正しておこうと思いました！

→ 私がFBC内の日報に上記を書いたところ、「自分も気をつけます」とのコメントを複数いただきました！他の受講生の方も共感するポイントだったようでした。

コードレビューが怖くなくなった。むしろコードレビューがないと怖い。

→ 早く終わらせたいと書いた先ほどの感想と矛盾しますが、これも共感しました。笑

yatsuhashi168 さん

「コードレビューを受ける新人の心構えと準備」
レビュイーもできることがある

準備：同じレビューをされない、自分以外のレビューを見る
同じレビューをされない
同じレビューをされないことでレビュアーの負担を減らす
レビューにかかる時間を減らす
重要な指摘箇所の見落としを防ぐ

→ レビュアーの負担を減らすようにすることで、結果自分のためになることがよく分かりました！

自分以外のレビューを見る
自分もその指摘をされる可能性がある
心構え：コメントの口調は気にしない、なぜを汲み取る
コメントの口調は気にしない
攻撃したいわけではない、忙しいと口調まで気に掛けられなかったりする、慣れる

→ コードレビューが怖かった昔の自分を思い出しました。

なぜを汲み取る
なぜを汲み取ることで抽象度をあげて自分のストックにする

→ 具体的なレビューが出ていてとても分かりやすかったです！
総じて自分が提出物の提出前にもっと気をつけようと思えることばかりでした！
「レビュイーにもできることがある」という言葉がインパクトがありました。
「同じレビューをされない」と「なぜを汲み取る」は特に重要視しないといけないなと思いました！

Yoshito Tanakaさん

「妥協できないソニックガーデンのコードレビュー」

妥協しないコードレビューとは
- 将来にわたって面倒を見ることができるか
- コードを読めば全てがわかるようになっているか
- 思ったこと全てをフィードバックする

単なる品質チェックではなく、技術的な思想を共有・議論する重要な場になっている

→ 私の中でコードレビューはお言葉を借りるなら品質チェックのイメージが強かったので、「技術的な思想を共有・議論する場」という視点に変えようと思いました。
品質チェックだとそれこそ採点されているような気持ちになってしまうけど、思想を共有・議論する場と考えていればディベートして当たり前だしレビューがきても対等な気持ちで向き合えるなと思いました。（メンターさんと受講生はもちろん対等ではないですが、意見自体はどちらが上とかはなく対等と考えて良いのかなと思いました）

妥協しないコードレビューの実例
- 納得するまで議論する
- 空行にもこだわる
- 思想についても好みとしてコメントする
- 自分ことは棚に上げてでも思ったことは伝える
- 代替案がなくても違和感は伝える

→ 今自分はプラクティスで過去に自分が作ったコードを修正するというものをやっていて、昔自分が書いたコードなのに本当に何を書いているか分からなくて苦戦してます。
最近そういう思いをしたばかりだったので、「将来にわたって面倒を見ることができるか」と「コードを読めば全てがわかるようになっているか」は本当にそうだなぁと痛感しました。
また、実例を挙げて説明してくださり分かりやすかったです。
いざ自分がレビューする側になったとときに、最初は無理でも最終的にはそういった細かいところ・気になるところを意見として伝えられるようにしたいなぁと思いました。

雑談

印象に残っているのは、運営の方が「なぜ無料でこのような勉強会を外部にやってくれるのですか？」との質問に「妥協しないエンジニアが集まっていて、社内の勉強会をしたりしていくうちにそれが社外に広がった」とおっしゃっていたことです。無料でこのような勉強会を開いていただいて私のような初学者も参加しやすくて本当にありがたいなと感じました。

勉強会を終えての感想

レビュアーとして成長することがチームへの貢献にもなるし自分を助けることにもなる
レビューはその意図を（わからなければ質問した上で）きちんと理解することで、自分の中で抽象度をあげてストックにできて他に活かせるようになる
コードレビューは技術的な思想を共有・議論する場

どの方のLTも分かりやすく勉強になりました！
自分のコードレビューに対する意識を変えていきたいと思います。
ソニックガーデンの皆様、ありがとうございました！

おわりに

今回は、エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」に参加した感想を書いていきました。
勉強会に参加すると刺激をもらえるしモチベーションもあがるので、今後も参加していきたいなと思っています。

終わります👋