はじめに
こちらは転職ドラフト Advent Calender 2024の11日目の記事になります。
今年から外資のソフトウェア会社で働いています。普段、日本のオフィスで働いていますが、海外オフィスの開発チームと一緒に仕事をしています。
念願の外資テックへの転職を果たして絶好調！かと思いきや、これまで何度も経験してきた難題にぶつかっています。
そう、コードレビューです。
自分がレビューするのはいいのですが、問題はレビューを「頼む」ことです。
もし良い解決方法があれば教えていただきたく、この記事を執筆しました。
コードレビューのメリット
問題に触れる前に、コードレビューが如何に素晴らしいものかをまとめておきましょう！
ChatGPTに聞くと以下のようなメリットを挙げてくれました。
- コードの品質向上
- 知識の共有
- コミュニケーションの活性化
- バグの早期発見と修正コストの削減
- 開発者の成長促進
- コードの一貫性の確保
レビューを通して、プロダクトの品質向上と開発メンバーの成長を促せます。プロダクト開発の観点から言えば、コードレビューにはメリットしかないです。レビューをパスしないと変更したコードをマージできないのが、もはやソフトウェア業界の暗黙のルールになっていると言っても過言ではないでしょう。
コードレビューとの闘い
しかし、これまでコードレビューを頼むのにいろいろと苦労させられてきました。レビューワー達に直接聞いたわけではないので、想像で補っている部分を多分に含んでいますが、以下のような背景があったと思われます。
コードレビューをやりたくないエンジニアは一定数いる
個人的な意見ですが、全てのEMはこの現実を知っておくべきでしょう。そして、これは固定観念かもしれないですが、割と優秀なエンジニアでレビューを嫌がる人は少なくないです。
私が最初に入社した大手の電機メーカーでは優秀な先輩達はたくさんいましたが、コードレビューを頼むのは一苦労でした。頼むとあからさまに嫌な顔をするんですよ。できるだけレビューワーが苦労しないように、実装の趣旨を事細かくコメントに記載したり、平身低頭でお願いしたりといろいろ工夫しました。
優秀なプログラマーの３大美徳は「怠慢」「短期」「傲慢」と言われています。それを体現しているのか、他人の書いたコードを見るのも嫌だし、他人に自分が書いたコードをとやかく言われるのも嫌という人はいます。
これがこの問題のやっかいなところで、「コードレビューをやりたくない」理由は決してロジカルなものではないのです。だからコードレビューの重要性をいくら説いても解決しません。それでもその理由をもう少し深掘りすると以下のようなものが考えられます。
他人が書いたコードを読むのは疲れる
コードを読むのは疲れます。他人が書いたコードなら尚更です。
コードを早く読むのが得意と自負する人にも会ったことはありますが、得意な人でも神経を使って読んでいるはずです。
ソフトウェアって一字一句間違えると上手く動かなくなるような代物です。コンパイラーやエディター、IDEが補助してくれる機能も向上してますが、その分、そこから漏れた欠陥を見つけるのは骨が折れるわけです。
ずるいエンジニアで、他人が書いたコードを丸ごと自分が書いたコードで置き換えてしまう人もいます。自分が書いたコードなら理解できるからです。まあ、当人は「自分ならもっと良いコードが書ける！」と思ってやっているのかもしれないですが。
他人が書いたコードにまで責任持てない
レビューしてもバグが出るときは出ます！
だから意味ないよねって言ってる人も見たことはあります。バグをゼロにするのをマストにするときついですね。(レビューってそういうものじゃないですが)
これは今の私の職場でもそうですが、同時並行で複数の機能開発やバグフィックスが進んでいるので、それらの趣旨を全て十分に把握できていないです。「把握できていないからレビューできないし、責任持てません」というのは理解はできますが、それだと開発できなくなってしまいます。
レビューをしても成果にならない
エンジニアに限らず、優秀とされている人で、ものすごく成果にストイックな人はいます。そして、自分の成果になること以外をやらないことを宣言している人も見たことがあります。
これに忠実に従ってしまうとコードレビューなんてやらなくていいことになってしまいます。レビューしても成果にならないですから。ソフトウェアエンジニアは開発してなんぼです。ですが、ソフトウェア開発はチームワークであるという事実にも目を向けるべきでしょう。
解決策
あまり有効な解決策はないのですが、私が考えたり、実際に経験した解決方法を挙げていきます。
ペアプロ/モブプロ
実は私も以下の記事にあるように、前職では100%ペアプロで開発をしてました。(そして私も退職しました笑)
ペアプロのデメリットは上の記事の通りですが、（おそらく最大の）メリットはコードレビューが不要になることです。
ペアプロでは常に２人以上の目で見て実装しているので、レビューは既にできている体になります。コード変更はmainブランチに直コミットです！(個人的には凄く怖いですが...)
でも他人がコーディングしてるのを見てるの眠いんですよ。自分にとっても開発体験としてはあまり良くなかったです。
レビュータスクに優先順位をつけてスタックする
これは私が考えた方法です。
レビュータスクを優先度順にスタックして、上から取っていくようにする。上のタスクがレビュー完了にならないと、次のタスクもレビューされないようにして、強制的にレビューが行われるようにします。
欠点としては同時並行でタスクが進まなくなってしまうことです。理想的には優先度上位のタスクが既にレビュー中なら、他の開発者は次のタスクのレビューに臨むべきです。
生成AI
生成AIでコードレビューをするサービスは既に出ています。Githubのプラグインもありますね。
実際に個人プロジェクトで試してみました。全体のコードを理解していないと分からないような指摘を的確についてきます！
欠点は自社コードを生成AIに入力することでIPの漏洩が懸念されることです。私の会社でも禁止されています。
それにここまでくると、「コーディングも生成AIに任せてしまえばよくない？」ってなりますよね。
結局、今どうしているか？
現在は、レビューは言ってしまえばボランティアです。レビューリクエスト専用のChatスペースにPRのリンクを貼ってお願いします。
ただし、所詮は性善説に基づいたボランティア。無視されることもあります。
私の場合、何度リクエストを投げても１週間くらい無視されて、最終的に何人かのメンバーに個別にお願いして、やっとレビューしてもらえたことがありました。もう心が折れそうでした。
タスクの優先度によりますが、もうレビューしてもらえなかったら、そのまま放置しようかと思ってるぐらいです。
おわりに
「おまえのコードが汚いからレビューしてもらえないんじゃないのか？」という声が聞こえてきそうですが、「@smallrivさんのコードはきれいだよね」って褒められたこともあるので、そんなことはないと信じています(笑)