© Findy Inc. Findyの爆速開発を⽀える Pull requestの粒度の話 1 

© Findy Inc. 弊社の開発⽣産性 2 

© Findy Inc. 3 

© Findy Inc. ⼤きなPull request 4 

© Findy Inc. 5 ⼤きなPull requestのデメリット ● topic branchの⽣存期間が⻑くなり、結果的にbase branchとの差分が⼤きくる ○ conflictの発⽣確率が⾼くなる ● 変更内容が多岐に渡るため、問題発⽣時の原因特定に時間が掛かってしまう ● revert時に余計な内容までrevertされてしまう ● レビューの質が落ちる ○ レビュワーが⾒るべき範囲が広くなるため、認知負荷が⼤きくなる ■ あとで⾒とこ、、、となりがち ● 結果的にtopic branchの⽣存期間が⻑くなる ● base branchとの差分が⼤きくなる ● conflictの発⽣確率が⾼くなる ○ 指摘内容が増え、結果的に⼿戻りが増える ● etc 

© Findy Inc. 適切な粒度とは 6 

© Findy Inc. 7 サイズと粒度の違い ● 関数名を変更して⼀括置換した場合 ○ 変更ファイル数は多くなるが、変更内容は⼀意になる ○ 変更内容を全て確認せずとも変更後の関数名をレビューし、CIが通ればマージしてOK ● 変更ファイル数が少ないが、データ取得‧加⼯‧描画を同じPull requestで対応した場合 ○ それぞれの処理は全く異なる内容 ○ 同じPull request内で対応してしまったため、変更内容全てを⼀度にレビューする必要がある ○ レビュワーに対する認知負荷が⼤きくなってしまう ● 変更⾏数が20⾏程度の不具合修正の際に、ついでにリファクタした内容が含まれていた場合 ○ 不具合修正に失敗していてrevertしようとした際に、ついでにリファクタした内容もrevertされて しまう ● 本質はコードの変更⾏数や変更ファイル数ではなく、変更内容そのものにある ○ 粒度が適切であれば、1⾏だけの修正でも、1万⾏の修正でも問題ない ○ 10のプルリクを1回レビューするよりも、1のプルリクを10回レビューする⽅が負担が少ない 

© Findy Inc. 適切な粒度を維持するためのTips集 8 

© Findy Inc. 9 タスク分解 ● コードを書く前の準備が重要 ● メリット ○ ⼯数⾒積もりの精度が上がる ○ 対応⽅針の認識を他メンバーと合わせやすくなる ○ 対応漏れに気づきやすくなり、⼿戻りの発⽣が少なくなる ○ Pull requestの粒度を適切に保つことができる ○ 他メンバーへの引き継ぎをしやすくなる ● 最初から完璧なタスクリストを作ろうとしないことがコツ ● 詳細は弊社テックブログを参照 ○ https://tech.findy.co.jp/entry/2024/05/27/090000 ○ Findyの爆速開発を⽀えるテクニック 

© Findy Inc. 10 迷ったら⼩さく ● 最初のうちは粒度に対して悩むことが出てくる ○ もっと作り込んでからレビュー依頼を出す？ ○ それとも今の段階で出す？ ○ でも修正内容が⼩さすぎないか？ ● 迷った時は⼩さい粒度の段階でレビュー依頼を出したほうが良い ○ Pull requestを⼤きく作って後から分解するより、⼩さく作って後から修正内容を追加する⽅が 圧倒的に楽 ● 最初は⼩さすぎても良いので、そこから⾁付けしていくようなイメージでPull requestを作成していく 

© Findy Inc. 11 レビュー最優先 ● Pull requestの粒度が⼩さくなった場合、レビュー依頼に対して最優先で取り組む必要がある ○ レビューがボトルネックになり、結果的に開発スピードが遅くなってしまう ● 粒度が適切であれば、レビュワーが確認する内容も⼩さくなる ○ レビューに掛かる時間が短縮される ○ ⾃分の作業を⼀時中断することになったとしても、すぐまた⾃分の作業に戻ることができる ● 粒度が適切なPull requestが当たり前となれば、レビューを最優先にする習慣、⽂化が組織に根付く 

© Findy Inc. 12 CI⾼速化 ● 粒度が⼩さくなってくると、当然ながら作成されるPull requestの数が増える ○ CIの実⾏回数も⽐例して増える ● CIの実⾏回数が増えた状態で実⾏速度が遅いと、逆に開発効率が落ちる ○ CIが遅いからPull requestの粒度も⼤きくなってしまうといったケースも⾒たことがある ● CIの⾼速化も同時に進めた⽅が良い ○ 10分切りが⽬安 ○ 5分を超えたら遅いと思ったほうがいい ● 詳細は弊社テックブログで ○ https://tech.findy.co.jp/entry/2024/09/17/090000 ○ ファインディでのGitHub Actions⾼速化の事例 

© Findy Inc. 13 feature flag ● Pull requestの粒度は適切にしたいが、本番環境に影響を出したくないパターン ○ feature flagを使う ● ローカル環境でのみ実⾏されるようなコードにしておく ○ その状態を維持しつつbase branchにマージし続ける ○ 本番公開OKのタイミングでfeature flagを解除し、本番環境に反映 ● SaaSやライブラリを使うなどの⽅法がある ○ 今回は⼀番カンタンに導⼊できる⽅法の、コード上にフラグを埋め込んで切り替える⼿法を紹介 

© Findy Inc. 14 feature flagのコード例 export const SampleComponent = () => { const isEnabledNewLabel = process.env.FEATURE_NEW_LABEL === 'true'; return ( ); }; 

© Findy Inc. 15 topic branch base branch topic branch develop branch develop branch develop branch topic branch を作成 base branch の変更取込 base branch へmerge 

© Findy Inc. まとめ 16 

© Findy Inc. 17 まとめ ● Pull requestの粒度を適切に維持し続けましょう ○ レビュワー、レビュイーの両者に対して優しいPull requestを作成し続けることができるように なる ● 弊社では最重要テクニックの1つとしている ● ⽐較的カンタンに覚えることができ、コツさえ掴めば誰でも実践できる内容 ● Pull requestをサクサク作って、速攻でmergeするリズムを覚えることが重要 ● 是⾮、皆さんも試してみてください。