コードレビューが怖かった私の、レビューへの向き合い方が変わった話

登川氏の自己紹介

登川仁至氏：じゃあ始めていきたいと思います。「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」という長めなタイトルなんですが、そのまんまの感じになります。

まず自己紹介から言っていきます。ソニックガーデンジム7期生。前期ですね。プログラマー歴も2、3年ぐらいですね。今はWebアプリケーション開発をしています。沖縄に住んでいて今日はすごく暑くて半袖でもぜんぜんいけました。すごく暖かいです。「白くま」が横なのは、あんまり気にしないでください（笑）。ちなみに名前は「ノボ」です。よろしくお願いします。

本セッションで話すこと

今回何を話すのかです。タイトルどおり、「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」について話します。「コードレビューが怖いな」「ソニックガーデンジム、気になるな」と思っている人の参考になるかなと思っています。わりと体験ベースで話していくので、細かいコードの説明とかはやらない感じです。

ソニックガーデンジムに参加した経緯

参加した経緯ですが、仕事でコードを書いて2、3年目になって、「コードを書くのに慣れてきたな、だいたい実装できるな」というところだったんですが、もっと良いコードの書き方が知りたいということで、「なにかいい方法がないかな？」といろいろ探していました。そうしたら、知り合いが「ソニックガーデンジムというのがあるぞ」ということで、「何だそれは？」と。

（スライドを示して）これがサイトなんですが、「レビューを受けることで自分の実力を知ると共に、目指すべき目標地点を知ることができます」と書いてあったので、「これだ、これは行くしかない」となり、参加を申し込みました。

応募して、参加できるようになりました。そこから3ヶ月間、課題に沿ったアプリケーションの開発をすることになったというかたちです。

「レビューしやすいように工夫する」ことは意外と意識していなかった

そこから何を学んだかを大きく分けてだいたい3つ話せるかなと思っています。「レビューしやすいように工夫する」と「気になることは質問しよう」と「他人のレビューを見てみる」というところです。

「レビューしやすいように工夫する」というところですが、意外と意識していなかったところで、ソニックガーデンジムに入って、「プルリクエストのサイズが大きくならないようにまず気をつけよう」ということで、わりと意識していました。

最近もやってしまったんですが、「機能ごとに区切って出すのがすごくわかりやすいよね」と。負担も少なくて、レビューの本質を割きたいところにレビューの時間を使うことができるというところですね。

また、コメントにはアノテーションとかTODOとかFIXMEとかをつけて……。（スライドを示して）「言い訳」と書いているんですが、コードの説明というよりは、なんでこのコードにしたのかの説明。「こうやったけど、こうできなくて、こうしました」みたいな。

（コメントを見て）「大きい、小さいの具体例の基準は？」。認証機能と登録機能のプルリクエストをまとめて送っちゃったようなところがあって。「認証だったら認証とかでレビューしてよね」みたいなところがあると思っています。

あと、UIの変更があれば変更箇所の動画や写真を添付したりすることで、レビュワーからしたらやりやすいのかなと思っています。ここは、たぶんチームによると思っています。

あと、「Linter」を使用したり「RuboCop」とかを入れたりして、細かいところを自分で修正する。また、セルフレビューを行って、レビューの本質ではない箇所をレビューさせないようにするというところですね。ここはけっこう大事なところかと思っています。

コードレビュー初期にやりがちだったコメントというか。私の例では、レビュワーの方が「この実装AはAがいいんじゃないんですか？」と言ったら、「Aがいいと思います、Aで実装します」「さっきのは修正します」みたいな感じでした。

「絶対わかっていないだろ」みたいな匂いがぷんぷんするような感じで（笑）。「なぜ実装Aがいいのかを理解していないまま実装してしまっているんじゃないか」と、後々自分で振り返ったときに感じました。「応用が利かなさそうだよね」と。

コードレビューに慣れてきた頃は、レビュワーが先ほどと同じような質問をした時に、「私としては、Bの理由があるのでこの実装にしています」「レビュワーの方が言った、Aの実装に対する理由はCでしょうか？」みたいな、自分で考えたことを質問するというところで。

レビュワーの方から「Aの実装に対する理由は、Cではなく別の理由だからです」と質問が返ってきて、「なるほど。それは確かに、そのほうがAの実装がいいと思うな」という（かたちで）、理由が自分の中で落とし込めるようになりました。完全に理解できているため応用が利くんですね。

自分のレビューだけでなくても学べることはある

次に「他人のレビューを見てみる」というところです。ソニックガーデンジムでは、一緒に3ヶ月走る方が他にいたので、その方のプルリクの中のレビューを見ました。

自分と同じ指摘をされていたところとか、違うレビューの仕方がされていたり、そのコメントに対して別のレビュワーがコメントするみたいな、流派の概念を垣間見ることができたりして、すごく勉強になりました。自分のレビューだけでなくても、学べることはすごくあると思っています。

詳しくは『コードレビューで学ぶRuby on Rails』にメッチャ書いてあるので、読んだほうが良いと思います。

「コードレビューが怖い」から「コードレビューがないと怖い」に

心境の変化です。ソニックガーデンジムに参加するまでの心境は、「この実装がベストかどうかわからない」とか「理解できないコメントが来たらどうしよう」とか「コメントが多すぎたらへこみそう」とか。「コードレビューは必要だけど、最低限あればいいんじゃないかな」というところで、正直コードレビューが怖いと思っていました。

参加中の心境というところで、コメントがいっぱい来たなと思って（笑）。ちょっとへこんだんですが、レビューコメントが89ぐらい来て、けっこう多めだなと思って。そのわりにはコメントが優しくて「わっ、優しい」となったりして。

あと、レビューしているところで、「こういうふうな流派がある」と（感じたりと）か、おもしろい（と思ったり）とか。

（コメントを見て）あっ、89は少ないほうなんですね。じゃあぜんぜん大丈夫です（笑）。きれいなコードの書き方を知れたので、そこからだんだん楽しくなってきて、コードレビューはやはり絶対必要なんじゃないかなと思ってきました。

参加終了後の心境としては、コードレビューを受けて成長を実感しました。レビュワーとの仲が深まった気がします。コードレビューが怖くなくなって、むしろコードレビューがないと怖いという状況になっていきました。

心境の変化をまとめると、コードレビューが怖かったのが怖くなくなって、むしろないと怖いみたいな状況です。

妥協しないコードレビューのほうが絶対に良いプロダクトを作れる

次に、今回の（発表の）題材が「自分なりの妥協しないコードレビュー」だったので、そこを考えていきたいと思います。

「妥協しないコードレビューとは」はちょっとわからなかったので、妥協をしたコードレビューを考えてみました。思い当たるものが、命名規則がバラバラ、シンプルでない実装、よくわからないコメント、使用しているのかわからないメソッドやファイル、メンテナンスコストだけが増える効果の低いテスト。

それが、妥協しなかったコードレビューに書き換えたら逆になるのかなと思いました。命名規則が統一されている、シンプルで見やすい実装、意味のあるコメント、使用しているのかわからないメソッドやファイルが存在しない、効果のあるテストみたいなところで。

その差分を見てみると、妥協をしなかったコードレビューのほうが、絶対に良いプロダクトになるよなというのが単純な感想としてありました。

妥協しないコードレビューというのは、良いプロダクトを作るために必要な、チームの共通の認識になるのかなと思っていました。ここのところは、もう少し深堀っていきたいです。

というところで、まとめに入ります。ソニックガーデンジムを通して、レビューしやすいように工夫したり、「気になることは質問しよう」とか、他人のレビューを見てみることを実際にやっていって、コードレビューがほぼ怖くなくなって、むしろレビューがないと怖いとなってきました。

妥協しないコードレビューというのがあって、良いプロダクトを作ることができると思ったので、これからも実践できればなと思っています。

ご清聴ありがとうございました。