Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
なんでもPull Requestにする / Kichijoji.pm 31
Search
utagawa kiki
November 22, 2022
Programming
3
6.4k
なんでもPull Requestにする / Kichijoji.pm 31
吉祥寺.pm 31
https://kichijojipm.connpass.com/event/265657/
utagawa kiki
November 22, 2022
Tweet
Share
More Decks by utagawa kiki
See All by utagawa kiki
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
300
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
1.1k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
2.4k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
16k
Dive into gomock / Go Conference 2024
utgwkk
14
7.7k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.6k
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
utgwkk
7
4.2k
ありがとう、create-react-app
utgwkk
4
11k
mockgenによるモック生成を高速化するツール bulkmockgenのご紹介 / Kyoto.go #43
utgwkk
2
2.4k
Other Decks in Programming
See All in Programming
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
120
RDoc meets YARD
okuramasafumi
4
170
Processing Gem ベースの、2D レトロゲームエンジンの開発
tokujiros
2
130
Azure SRE Agentで運用は楽になるのか?
kkamegawa
0
2.2k
AIコーディングAgentとの向き合い方
eycjur
0
270
時間軸から考えるTerraformを使う理由と留意点
fufuhu
16
4.8k
Rancher と Terraform
fufuhu
2
400
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
10
4.1k
概念モデル→論理モデルで気をつけていること
sunnyone
2
170
Testing Trophyは叫ばない
toms74209200
0
870
Updates on MLS on Ruby (and maybe more)
sylph01
1
180
Design Foundational Data Engineering Observability
sucitw
3
200
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
330
21k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
The Invisible Side of Design
smashingmag
301
51k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Into the Great Unknown - MozCon
thekraken
40
2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
13k
Transcript
なんでもPull Requestにする 吉祥寺.pm 31 @utgwkk (うたがわきき)
自己紹介 • @utgwkk (うたがわきき) • 株式会社はてな Webアプリケーションエンジニア • 主にTypeScriptとReactを書いて 暮らしています
今回のテーマ • 「来年に向けて、今年やったこと、書いたコード」 • 書いたコード 🔜 Pull Request の話
Pull Request (PR) • PR作ってますか?
PRの例 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/60797
PRに対するイメージ • 機能追加 • バグ修正 • ドキュメントの修正 • etc.
それだけじゃない • 日々の暮らしでこのようにPRを作っている、という例をご紹介
PoC (Proof of Concept, 概念実証) • ある機能を実装したい、というときに雑でもいいのでとにかく動くものをPRとして 作っておく • 実際に作る段階になったら、少しずつ実装を切り出したり整えたりして別途PRを
作っていく • こうやったらできそう、ここは考えることがありそう、というのを確かめてから本実装 に入れる
お試しPR • 日々、いろいろなことを思いつく ◦ こういう機能があると便利なのでは ? ◦ こういうふうに実装を整理すると見通しがよくなるのでは ? •
思い立って時間ができたらカカッと実装してPRを作る • これいいじゃん、となったら本実装に入る
書き捨てスクリプトを使った調査 • データ量の見積もりや検証などを行いたい場合 • 手元でスクリプトやワンライナーを使って調査したような内容でもPRとして残してお く • 調査結果をPRのコメントに残しておく • あとから再現しやすい
マージしないPRによって生み出される価値 • ここまで紹介してきたようなPRは、必ずしもマージできるとは限らない ◦ だいたいマージせずに閉じる • マージされないことを前提として実装する ◦ 雑でもいいから実装する ◦
とにかく高速に実装する ◦ マージしたくなったら実装を整える • 実現可能である・見通しが立つようになることに価値があると思う ◦ マージしなかったので無駄、ということはないと思う
PRを作っておく利点 • コードを見ながら議論できる • 手元でcheckoutして動作確認できる • 進捗の可視化 ◦ 手元のブランチだけに残さずPRにする ◦
ここまではできた、というのをURL付きで共有できる
git stashとの比較 • stashをあとからapplyするとコンフリクトしがち ◦ 開発が進むとapply困難になる ◦ PRにしておくとcheckoutして動作確認できる ▪ base
branchとはコンフリクトするけど • PRはURLやブランチ名などで共有しやすい ◦ stashだと、手元のdiffを共有する、みたいな形になる
まとめ • ここで一句: 万物を プルリクにして 残したり • いろいろな用途でPRを作っておくと便利 • 来年もたくさんのPRを作っていくことになるでしょう