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.5k
なんでも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
new(1.26) ← これすき / kamakura.go #8
utgwkk
0
1.4k
tparseでgo testの出力を見やすくする
utgwkk
2
580
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
4
1.1k
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
1.8k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
3.3k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
17k
Dive into gomock / Go Conference 2024
utgwkk
14
8.4k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.7k
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
utgwkk
7
4.3k
Other Decks in Programming
See All in Programming
Oxlint JS plugins
kazupon
1
1.2k
AI駆動開発の本音 〜Claude Code並列開発で見えたエンジニアの新しい役割〜
hisuzuya
4
450
あなたはユーザーではない #PdENight
kajitack
4
290
Rubyと楽しいをつくる / Creating joy with Ruby
chobishiba
0
200
New in Go 1.26 Implementing go fix in product development
sunecosuri
0
120
Go Conference mini in Sendai 2026 : Goに新機能を提案し実装されるまでのフロー徹底解説
yamatoya
0
490
Raku Raku Notion 20260128
hareyakayuruyaka
0
430
今更考える「単一責任原則」 / Thinking about the Single Responsibility Principle
tooppoo
3
1.3k
Rで始めるML・LLM活用入門
wakamatsu_takumu
0
140
社内規程RAGの精度を73.3% → 100%に改善した話
oharu121
12
7.3k
ご飯食べながらエージェントが開発できる。そう、Agentic Engineeringならね。
yokomachi
1
280
AIコーディングの理想と現実 2026 | AI Coding: Expectations vs. Reality 2026
tomohisa
0
870
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
340
58k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
117
110k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Design in an AI World
tapps
0
160
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
850
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
620
Everyday Curiosity
cassininazir
0
150
A Soul's Torment
seathinner
5
2.4k
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
The SEO Collaboration Effect
kristinabergwall1
0
380
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を作っていくことになるでしょう