2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
ソニックガーデンジムに参加してコードに対する向き合い方が変わった話(全1記事)
リンクをコピー
記事をブックマーク
登川仁至氏:じゃあ始めていきたいと思います。「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」という長めなタイトルなんですが、そのまんまの感じになります。
まず自己紹介から言っていきます。ソニックガーデンジム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は少ないほうなんですね。じゃあぜんぜん大丈夫です(笑)。きれいなコードの書き方を知れたので、そこからだんだん楽しくなってきて、コードレビューはやはり絶対必要なんじゃないかなと思ってきました。
参加終了後の心境としては、コードレビューを受けて成長を実感しました。レビュワーとの仲が深まった気がします。コードレビューが怖くなくなって、むしろコードレビューがないと怖いという状況になっていきました。
心境の変化をまとめると、コードレビューが怖かったのが怖くなくなって、むしろないと怖いみたいな状況です。
次に、今回の(発表の)題材が「自分なりの妥協しないコードレビュー」だったので、そこを考えていきたいと思います。
「妥協しないコードレビューとは」はちょっとわからなかったので、妥協をしたコードレビューを考えてみました。思い当たるものが、命名規則がバラバラ、シンプルでない実装、よくわからないコメント、使用しているのかわからないメソッドやファイル、メンテナンスコストだけが増える効果の低いテスト。
それが、妥協しなかったコードレビューに書き換えたら逆になるのかなと思いました。命名規則が統一されている、シンプルで見やすい実装、意味のあるコメント、使用しているのかわからないメソッドやファイルが存在しない、効果のあるテストみたいなところで。
その差分を見てみると、妥協をしなかったコードレビューのほうが、絶対に良いプロダクトになるよなというのが単純な感想としてありました。
妥協しないコードレビューというのは、良いプロダクトを作るために必要な、チームの共通の認識になるのかなと思っていました。ここのところは、もう少し深堀っていきたいです。
というところで、まとめに入ります。ソニックガーデンジムを通して、レビューしやすいように工夫したり、「気になることは質問しよう」とか、他人のレビューを見てみることを実際にやっていって、コードレビューがほぼ怖くなくなって、むしろレビューがないと怖いとなってきました。
妥協しないコードレビューというのがあって、良いプロダクトを作ることができると思ったので、これからも実践できればなと思っています。
ご清聴ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには