コードレビューの重要性
みなさんこんにちは、microCMS FM です。この番組は、microCMSの中の
人がいろいろなトピックについて 雑談する番組です。最初に自己紹介
ですが、僕がプロダクトマネージャー をやってます、平松です。そして
では、microCMSでCTをやっています 大西です。この2人で喋っていき
たいんですけど、今日のテーマは コードレビューというところで、
コードレビューとかその周りの コード品質の担保みたいなところ
で話していければなと思ってます。
はい、コードレビューね。コードレビュー みなさん好きなんでしょうか。ちょっと
嫌いですけど、僕は嫌いでござい まして。まあ、めんどくさいですよ
ね。たぶんエンジニアの仕事の中で 一番めんどいかもしれない。過激派
なんですけど、人のコードを見ても 興味を持てないし、あんまり知らん
なと。書き方こうしたほうがいい とか言っても、なんかその絶対的な
正解みたいなの少ないしね。ほんまに 絶対的にこうしたほうがいいとか
あるかもしれんけど、あとはここ 明らかバグってるみたいな。めっちゃ
本気出してコードレビューしたら たぶんそういうのも見つけれるん
かもしれないですけど、人のコード、 書いたコード。しかも仕様も知らん
しみたいな時にはそういう時も あるじゃないですか。結局めちゃ
くちゃ頭使えばできるかもしれん けど、めっちゃ疲れるという。コード
レビューで疲弊するみたいなのは たぶん一般的にもよくあるあるある
な感じですよね、たぶんね。
AIコードレビューの導入
そうですね。でも結構こういうふう にしたら品質担保できるとか、そういう
コードレビューの方法論みたいな のも結構やりとり活発なイメージ
確かにそういうのも方法論的な 結果あります。そういうのはまず
思ってはいて、もちろんコードレビュー やってるんですけども、最近という
か1年前、Code Rabbitというのを導入 しまして、AIコードレビューですね。
これを導入してまして、結構クオリティ 高くて、指摘の内容もかなりいい
し、そのプルリクの内容をさま ってくれたりは当然するんですけど、
最近シーケンス図みたいなの書いて くれるんですよね。しかもそれ結構
たぶん合ってるんですよ、ほぼ。
どういうやつなの?
そのリクエストが来て、ここに渡 って、違う別のシステムに投げて
DBにデータを保存するリクエスト をして、その後監査ログみたいな
のを別のシステムに保存するみたい なのをやってみたいなのがシーケンス図
で表現されてるみたいな。だから 視覚的にコードでやってる、どの
システムが登場して、どういう ふうな順序でリクエストしたり
し合ってるのかみたいなのが視覚 的に分かる。
プルリクエストでこういう変更 ですよねっていうところを無視して
くれるってこと?
たぶんそうだと思うんですよね。 どこの範囲まで見てくれてるのか
やや微妙なんですけど、関係ありそうな ところをそれで作れれば。
ですね。それは便利そうよね。
プルリク、最初にコードの一行一行 見ていくところからいっても、なかなか
頭に入らなかったりするから、 全体像を俯瞰してからの、なるほどね
っていうのをなってから一行一行 見ていくっていうのが、たぶん分かり
やすいというか。コードラビット めちゃくちゃ改善というか、精度
もめっちゃ上がってる気がします ね。おすすめ。
正しく立てたら、変更差分で微妙 さなとこあったらコメントして
くれるみたいな。
そうです。結構、普通のエンジニア よりAI、ちゃんとGPTとか、平均的な
エンジニアよりは頭いいって言われてる じゃないですか。
平均?
平均っていうか、コメント指摘内容 もめっちゃあってるし、いいと思います
ね。うちではコードラビットの指摘 に何かしら必ず対応というか、コメント
返すなり修正するなり、リアクション スタンプだけ返すなり、何かしら
全部のリアクションというか、 全部リゾルブドした状態で人間
にレビュー依頼するというのを ちゃんと徹底してるというか、そういう
人間の負担軽減
ふうにしてますね。そうしないと なあなあになってくると思うん
ですよ。たぶん、なあなあになってる プロジェクト結構ありそう。
そうですね。窓外れなコメントみたいな ものもあるはある?
あるときもたぶんあるんだと思います けど、でも交流済みのことを言って
くるっていうのは結構ありますね。 それはしょうがない。たぶん人間
でもなんですけど、それとかもちゃんと コメント返しは、これは大丈夫な
やつですって。
なるほど。どうせ人間やるもんね、 それ。
そうですね。あとは、コードラビット のコメントが放置されたままやと
結局これは交流したのかしてない のかもわからんから、ちゃんと
したならしたで、無視していいなら 無視しますとか、今回は関係ない
ですとか、ちゃんと人間と同じように 返してあげるというふうにしてます
ね。この辺の運用スタイルって あの会社とかどうやってるかとか
聞きたいですね。
コメント自体はみんな使ってるん か、広く知られてるもんなのか。
結構知らない。なんか結構使われて そうでしたけどね。うちでも使ってる
みたいなちょいちょい。
そうなの。
でもちゃんと実はやってないみたい なのは結構ありそう。
結構運用のテクニックみたいな、 ありそうだね。この言語とかドメイン
の情報を与えといて、こういう ふうに指摘さすみたいな。
フロンプトは結構大事だと思います ね。
フロンプトは結構拡張してるんで したっけ?Micro-CMS。
めちゃくちゃこだわってやってる わけではないですけど、技術スタック
伝えたりとか、ここのコードはこういう 感じのコードですみたいな、ふん
わり。そんなにめちゃくちゃ考え 抜いてっていうよりは、思ったこと
をとりあえずフロンプトには伝 えといて、ふんわりね。それだけ
でもかなりの精度改善にはなり そうな感じ。
いいですね。
あと、あまりにも細かいことは 指摘しないでくださいとか、ちょっと
そういうのは入れたり、本質的な ところになるべくフォーカスする
みたいなね、いうふうにしたり とか。あとはコンピューターサイエンス
とか、そういう世の中のベストプラクティス とかはなるべく指摘してください
とかね。結構、エンジニアのそもそも 勉強になったりすると。
そういうのいいそうだね。
そうですね。細かいところを見て くれるというふうに育てるという
よりは、賢いリードエンジニアとして 育てるみたいな感覚のフロンプ
とかもしれないです。
はい。
学習のきっかけをくれたりとか。
とかね、そっち側かな。設計があまり にも変じゃないかとか。
はい。コードラビット入れて、人間 がやる負担を結構減らしていってる
ということね。
そうですね。コードレビューの 人間がやる部分をどんどん減らして
最終的には人間がコードレビュー しなくてもいいようにはしたい
ですよね。
なるほど。
はい。本質的なレビューに人間が 集中。本質的というのはビジネス
ロジックとか仕様の部分ですね。 技術的な書き方だったり、そういった
とか全部コードラビットとかに 修正したり、指摘してくれたり
そういうのを無視すればいいかな と思ってね。
はい。確かにね。他はどうですか?
あとは、そもそも自分がコードレビュー、 あんまりいらないんじゃないって
ストレスフリーな開発スタイル
思いがちなのは、昔Yahoo!時代、 全職Yahoo!だったんですけど、そこで
XP開発という、エクストリーム プログラミングだったっけな。これは
PMの平松さんとも一緒にやってたん ですけども、そこでTDDですね。テスト
駆動開発をやってまして、かなり ハードな過激的なプログラミング
で開発スタイルでやってまして、 ユニットテストはめっちゃ格子
カバリ値100パーだし、みたいな そういう環境でやってて、この時
コードレビューしてなかったですよね。 ペアプロでやってるっていうのも
もちろんあって、コードレビュー しながら作ってるのと一緒なんでね。
もう直接メインのブランチにプッシュ するみたいな感じでやってまして、
そこでコードレビューないという このライフスタイルがめちゃくちゃ
ストレスフリーでよかったですね。 こんなに作ってプッシュして作って
プッシュしてるだけで前に進む ってめっちゃいいなっていう。
ペアプロを説明しておこうか。
ペアプロの説明をしたい。
ペアプロの説明してもらっていいですか。
2人で1ペアになって、同じ画面を 見るんですよね。エディターを見て。
片方がナビゲーターだって、片方 がドライバーみたいなのがあるんですけど、
片方が書いてる間、もう1人は見てる。 交代交代にテスト書いて実装書いて、
で、次テスト書いて実装書いて みたいなのをしながら進めていく
みたいな感じでやってましたね。
こんな感じで。常に同じコードを見 ながら、同じ考え方とか共有しながら
こうやって作っていくかみたいな のを常にリアルタイムに共有しながら
やってたと。かつテストもめちゃ くちゃやってたという感じの環境
で、コードレビューもなくてとやって たんですよね。あと設計レビュー
というか、設計ミーティングみたいな の多分あったりすると思うんですよね。
こういうふうに作ろうと思うけど みたいなレビューお願いしますみたいな。
それもなくて、ペアペアでしゃべ ってやればいいだけなんで。
あとペア同士の会話とかはありました かね。それは普通のチームの振り返り
だったりあったのと、あとペアローテーション というのをやってたんですよね。
1日同じ人がペア、AさんとBさんが ペアでやったら次はAさんが抜けて
Cさん、BさんとCさんがペアになる という感じで。次はBさんが抜けて
Cさん残ってDDさんが入ってくる みたいなこの知識を引き継いで
いくというか。同じペアがずっと 同じことやってると知見が広がらない
ので、ペアローテーションをやってました よね。なので全員がまんべんなく
だいたいのシステムに詳しいという か、だいたいのコードに詳しい
みたいなのが1ヶ月とかすればできる わけですね。そうなるとかなり
強いですね。どんなやつでもこの辺 手入れたら良さそうとか、すぐ分かった
かしましたね。ペアローテはかなり 良かったかなと思って。自分がずっと
同じの作ることないから、ここは 俺の機能みたいな、ないよね。
ないじゃなかった。サイリチョーでも 2日間ローテーションしていくんで
2日しかモジュールしないから、分かる ように日々よくコード書いていかない
といけないから小さく作っていく のも習慣化するし、引き継ぐときに
言語化するから相手にも伝えれる ように自分も整理するし。チーム
としては全員のスキルが等しく 高くなっていくみたいな感じで
良いことがあったかなと思いました ね。そうですね。俗人化が多分
これでだいぶ減ってる気がします ね。休みやすいとかもあるしね。
ちょっとペアプロの話しちゃいました けど、とはいってもペアプロリソース
めっちゃ潤沢いないとなかなか できないとかあるんでマイクロシステム
でそれをやろうというつもりは そんなにないんですけども、テスト
駆動のとこですかね。ユニットテスト めっちゃ書きまくってて、カバレッジ
100パーにしててとか、このファイル は書かんでもいいかみたいなも
なくて、だいたいそういうところ でミスって差が落ちたりする
ちょっとしたセットアップやから いらんやろうみたいな、そういう
のがなくて、もう全ファイル100パー みたいな感じかな、めっちゃ極端に
言うと。そういうふうにしてると どんな変更をリリースするときも
もう自信持ってリリースできるような 感覚にだんだんなってきて、めっちゃ
心理的安全性じゃないか、ストレス フリーな開発が、仕事もそんなに
知識の共有とチーム強化
嫌じゃなくてっていう感覚になって きてたかな。ほんま毎日プログラミング
して作ってリリースして淡々と やっていくと。時間が来たら体験
していこう。良かったです。
おだしょー 変な恐れみたいなのはなかった
ね。
三沢 うん、不安とかなく。休み はしっかり休んで。かなりメンタル
がめちゃめちゃ良かったですね。 そんなこんなでいろいろ話しました
けども、マイクロSMSでもユニット テストとか言い継いテストとか元々
やってはいたんですけど、ここ最近 また力を入れ直してみんなで充実
させていってまして、その感覚になる べく近づけれるようになればいい
なと思っております。そんな感じ ですかね。今日はまとまりがない
と。
おだしょー はい。
三沢 そんな感じですね。
おだしょー はい。
