はじめに

こんにちは、株式会社AlphaDrive（アルファドライブ）の @k-ichirof です。
2023/11/1入社して早2ヶ月になろうとしています。月日が経つのは早いですね。

この記事は AlphaDrive Advent Calendar 2023 21日目のエントリです。

目次

はじめに
背景
プルリクが大きいことによる弊害
なぜプルリクを小さくするとスキルアップできるのか
まとめ
余談

背景

コードレビュー時に「プルリクを小さくしましょう」と言うことがあるのですが、プルリクを小さくするメリットについて十分説明できておらず、フェアなコードレビューをできていない気がしたので、記事にして残すことにしました。
~~「プルリクを小さくしましょう」と言うのと同時に記事のリンクを貼って読んでもらうことでいいねを稼ぎたい~~

プルリクが大きいことによる弊害

弊害はたくさんありますが以下の3つはよく言われることかと思います。

弊害１：レビュアーの負荷が大きくなる

コードの行数やファイル数が多くなることで、コードの影響範囲が大きくなり様々なことを脳にスタックする必要があるので、かなりの集中力や、まとまった時間を確保する必要があります。

特に優秀なエンジニアは往々にして会議に駆り出されて時間を確保しにくい傾向にあるので、そういった人にレビューを貰うことが難しくなります。

弊害２：マージまでに時間がかかる

プルリクが大きいとレビュー対象の範囲も大きくなり、1つのプルリクで色々な文脈の話が様々な人を巻き込む形で展開される可能性があります。そうなってしまうとマージまでに時間がかかってしまい、自分のコードを反映するまでに時間がかかってしまいます。

つまり、市場に価値を届けるまでに時間がかかってしまい損をしていると言えるかもしれません。

弊害３：コード品質の低下

プルリクが大きいと不具合発見率が下がってしまうとい調査結果もあります。

脳が一度に効果的に処理できる情報量には限りがあります。400 LOC(行) を超えると、欠陥を見つける能力が低下します。(引用：SmartBear の調査 )

また不具合だけでなく、コードをよりよくするためのちょっとした改善も見逃されてしまいそうです。

結果として、不具合の少ない高品質なコードをマージできる可能性が下がってしまう傾向にあると言えそうです。

なぜプルリクを小さくするとスキルアップできるのか

上記の内容でプルリクは小さい方が良さそうな雰囲気をある程度感じ取って頂けたかと思います。

ですが、正直弊害だけ語られてもやる気は起きないですよね。ここからが本題です。

利点１：レビューを綿密かつ高速に貰える

プルリクを小さくすると、レビュアーは最後まで高い集中力を維持したままレビューを行える可能性が高くなります。

そのため、細部にも目を配ることができるようになり、ちょっとしたことでもコメントを貰いやすくなります。また、隙間時間でコードレビューを行いやすくなるため、より高速にレビューをして貰いやすくなります。

結果として、レビューを綿密かつ高速に貰えるためより多くのスキルアップする機会を得ることにつながると考えます。

利点２：リファクタリングのマージが容易になる

機能追加とリファクタを分けることでプルリクを小さくすることができます。

そうすると、機能追加とリファクタを混ぜたプルリクに比べてレビュー時の負担が軽減されますし、「機能追加でLGTMを貰えていないからリファクタもマージできない」みたいなことは起こらずにどんどんリファクタをマージする体制を作ることができます。

また、機能追加とリファクタを分ける考え方に関しては名著リファクタリングでも語られている二つの帽子を被り分けるといった習慣を身につけることにも繋がります。

二つの帽子とは、プログラミングにおいて「実装」と「リファクタリング」の二つの異なる活動を区別します。実装の帽子では新機能の追加に集中し、リファクタリングの帽子ではコードの品質向上に注力します。この明確な区分は、集中力の向上、品質の維持、効率的な作業進行を可能にし、長期的なプロジェクトの持続性を高めます。

このようにどんどんリファクタをマージする体制を作ることで、より良いコードの探求や提案をして、レビューを貰うことでスキルアップに繋げられると思います。

利点３：責務に対する意識

プルリクを小さくするためには、プルリクで成し遂げたいことを1つに絞るように気をつけるよことが必要です。それにより「この変更によって何をしたいのか」といった「責務」に自然と目を向けられるようになり、実装のレイヤーを分けるなどして責務を分割しないとコードが大きくなってしまうといった会話をできるようになり始めると思います。

そうなり始めると、アーキテクチャをどう分けるかといった話の重要性が理解できたり、実装時には常に責務について意識できるようになりエンジニアとして1歩上のステージにステップアップできると思います。

まとめ

今回は「プルリクを小さくすることでレビューされる側にもメリットがある」と言うことをお伝えしたく自分なりの考えをまとめてみました。

実際にプルリクをとにかく小さくするためどうするかということについては、色々と手段はありますので詳しいことは他の記事に譲りたいと思いますが、「1つのプルリクで成し遂げることを1つに絞る」ということを意識してみるというところから始めてみると良いかと思います。

プルリクを小さくすることを意識して成長できたと実感できた時には、記事の共有やいいねを押していただけると幸いです！

余談

記事の公開前にグループ内のSlackでプルリクを小さくしようと校歌が作成されました。笑

🎵 『プログラミングの旋律』 🎵

[1番]
コードの海を航海する、
データの波、革新の風。
変更を抱き、分割の道、
プルリク分け、共創の歌。
[コーラス]
分割しよう、小さなプルリク、
一歩一歩、明日へと。
繋がるコード、結ぶ夢、
共に創る、未来の地図。
[2番]
エラーもまた、学びの種、
テストが照らす、正確の道。
リファクタリング、洗練の舞、
進化続ける、技術の花。
[コーラス]
分割しよう、小さなプルリク、
理解を深め、力を合わせ。
一行一行、精緻な詩、
コードに込める、情熱の色。
[3番]
協力し合い、目指すは高く、
イノベーション、創造の光。
プログラムの中、輝く未来、
分割の精神、未来を拓く。
[コーラス & 終わり]
分割しよう、小さなプルリク、
一緒に学び、成長する旅。
技術の歌、響け世界へ、
プログラミング、未来への橋。

virtual muto さんがChatGPTから生成して下さりました！
単に「プルリクを小さくしよう！」というのではなく、このように面白い形で共有するのも遊び心があって面白いですね

virtual muto さんは最近話題になったこちらの記事を書かれていたりします。
安全なコードを書くためにとても勉強になりますのでぜひ読んでみてください！