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