Findyの爆速開発を支えるPull requestの粒度

Transcript

1. © Findy Inc. Findyの爆速開発を⽀える Pull requestの粒度の話 1
2. © Findy Inc. 弊社の開発⽣産性 2
3. © Findy Inc. 3
4. © Findy Inc. ⼤きなPull request 4
5. © Findy Inc. 5 ⼤きなPull requestのデメリット • topic branchの⽣存期間が⻑くなり、結果的にbase branchとの差分が⼤きくる ◦ conflictの発⽣確率が⾼くなる • 変更内容が多岐に渡るため、問題発⽣時の原因特定に時間が掛かってしまう • revert時に余計な内容までrevertされてしまう • レビューの質が落ちる ◦ レビュワーが⾒るべき範囲が広くなるため、認知負荷が⼤きくなる ▪ あとで⾒とこ、、、となりがち • 結果的にtopic branchの⽣存期間が⻑くなる • base branchとの差分が⼤きくなる • conflictの発⽣確率が⾼くなる ◦ 指摘内容が増え、結果的に⼿戻りが増える • etc
6. © Findy Inc. 適切な粒度とは 6
7. © Findy Inc. 7 サイズと粒度の違い • 関数名を変更して⼀括置換した場合 ◦ 変更ファイル数は多くなるが、変更内容は⼀意になる ◦ 変更内容を全て確認せずとも変更後の関数名をレビューし、CIが通ればマージしてOK • 変更ファイル数が少ないが、データ取得‧加⼯‧描画を同じPull requestで対応した場合 ◦ それぞれの処理は全く異なる内容 ◦ 同じPull request内で対応してしまったため、変更内容全てを⼀度にレビューする必要がある ◦ レビュワーに対する認知負荷が⼤きくなってしまう • 変更⾏数が20⾏程度の不具合修正の際に、ついでにリファクタした内容が含まれていた場合 ◦ 不具合修正に失敗していてrevertしようとした際に、ついでにリファクタした内容もrevertされて しまう • 本質はコードの変更⾏数や変更ファイル数ではなく、変更内容そのものにある ◦ 粒度が適切であれば、1⾏だけの修正でも、1万⾏の修正でも問題ない ◦ 10のプルリクを1回レビューするよりも、1のプルリクを10回レビューする⽅が負担が少ない
8. © Findy Inc. 適切な粒度を維持するためのTips集 8
9. © Findy Inc. 9 タスク分解 • コードを書く前の準備が重要 • メリット ◦ ⼯数⾒積もりの精度が上がる ◦ 対応⽅針の認識を他メンバーと合わせやすくなる ◦ 対応漏れに気づきやすくなり、⼿戻りの発⽣が少なくなる ◦ Pull requestの粒度を適切に保つことができる ◦ 他メンバーへの引き継ぎをしやすくなる • 最初から完璧なタスクリストを作ろうとしないことがコツ • 詳細は弊社テックブログを参照 ◦ https://tech.findy.co.jp/entry/2024/05/27/090000 ◦ Findyの爆速開発を⽀えるテクニック
10. © Findy Inc. 10 迷ったら⼩さく • 最初のうちは粒度に対して悩むことが出てくる ◦ もっと作り込んでからレビュー依頼を出す？ ◦ それとも今の段階で出す？ ◦ でも修正内容が⼩さすぎないか？ • 迷った時は⼩さい粒度の段階でレビュー依頼を出したほうが良い ◦ Pull requestを⼤きく作って後から分解するより、⼩さく作って後から修正内容を追加する⽅が 圧倒的に楽 • 最初は⼩さすぎても良いので、そこから⾁付けしていくようなイメージでPull requestを作成していく
11. © Findy Inc. 11 レビュー最優先 • Pull requestの粒度が⼩さくなった場合、レビュー依頼に対して最優先で取り組む必要がある ◦ レビューがボトルネックになり、結果的に開発スピードが遅くなってしまう • 粒度が適切であれば、レビュワーが確認する内容も⼩さくなる ◦ レビューに掛かる時間が短縮される ◦ ⾃分の作業を⼀時中断することになったとしても、すぐまた⾃分の作業に戻ることができる • 粒度が適切なPull requestが当たり前となれば、レビューを最優先にする習慣、⽂化が組織に根付く
12. © 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⾼速化の事例
13. © Findy Inc. 13 feature flag • Pull requestの粒度は適切にしたいが、本番環境に影響を出したくないパターン ◦ feature flagを使う • ローカル環境でのみ実⾏されるようなコードにしておく ◦ その状態を維持しつつbase branchにマージし続ける ◦ 本番公開OKのタイミングでfeature flagを解除し、本番環境に反映 • SaaSやライブラリを使うなどの⽅法がある ◦ 今回は⼀番カンタンに導⼊できる⽅法の、コード上にフラグを埋め込んで切り替える⼿法を紹介
14. © Findy Inc. 14 feature flagのコード例 export const SampleComponent = () => { const isEnabledNewLabel = process.env.FEATURE_NEW_LABEL === 'true'; return ( <div> {isEnabledNewLabel && <span>NEW</span>} <span>Sample</span> </div> ); };
15. © Findy Inc. 15 topic branch base branch topic branch develop branch develop branch develop branch topic branch を作成 base branch の変更取込 base branch へmerge
16. © Findy Inc. まとめ 16
17. © Findy Inc. 17 まとめ • Pull requestの粒度を適切に維持し続けましょう ◦ レビュワー、レビュイーの両者に対して優しいPull requestを作成し続けることができるように なる • 弊社では最重要テクニックの1つとしている • ⽐較的カンタンに覚えることができ、コツさえ掴めば誰でも実践できる内容 • Pull requestをサクサク作って、速攻でmergeするリズムを覚えることが重要 • 是⾮、皆さんも試してみてください。