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
Fear, and loathing In KUSO pull request
Search
Masahiro Doi
December 06, 2020
Technology
0
780
Fear, and loathing In KUSO pull request
Masahiro Doi
December 06, 2020
Tweet
Share
More Decks by Masahiro Doi
See All by Masahiro Doi
AbemaTVの広告オークション / ads auction in abematv
doilux
2
1.9k
Other Decks in Technology
See All in Technology
Wasmで社内ツールを作って配布しよう
askua
0
160
モバイルゲームの開発を支える基盤の歩み ~再現性のある開発ラインを量産する秘訣~
qualiarts
0
920
Microsoft Learn MCP/Fabric データエージェント/Fabric MCP/Copilot Studio-簡単・便利なAIエージェント作ってみた -"Building Simple and Powerful AI Agents with Microsoft Learn MCP, Fabric Data Agent, Fabric MCP, and Copilot Studio"-
reireireijinjin6
1
190
Vision Language Modelと自動運転AIの最前線_20250730
yuyamaguchi
2
890
Jitera Company Deck / JP
jitera
0
310
東京海上日動におけるセキュアな開発プロセスの取り組み
miyabit
0
210
テキストからの実世界知能の実現に向けて
sumoai
0
110
KCD Lima: eBee in Peru!
lizrice
0
110
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
920
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
130
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
110
MCPと認可まわりの話 / mcp_and_authorization
convto
2
340
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
The Invisible Side of Design
smashingmag
301
51k
BBQ
matthewcrist
89
9.8k
Designing for Performance
lara
610
69k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
770
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Transcript
Fear, and loathing In KUSO PULL request
Workshop 以下のPRのレビュワーにアサインされた場合に、イラっとくるポイントをあげて みよう https://github.com/doilux/kusopr/pull/1
レビューの意義 INPUTとOUTPUTの整合性チェック ダブルチェック 異なる観点からのチェック
work is ... 設計書 実装 input output 作業者 INPUTとOUTPUTの整合性チェック
review is ... 設計書 実装 input output 作業者 レビュワー INPUTとOUTPUTの整合性チェック
設計通りに実装できているかチェック
ダブルチェック レビューしてみよう(疑似コードです) val pref_country_map = [ “埼玉”: “関東”, “千葉”: “関東”,
“東京”: “関東”, “京都”: “関東”, “大阪”: “関西”, “兵庫”: “関西”, ]
ダブルチェック レビューしてみよう(疑似コードです) val pref_country_map = [ “埼玉”: “関東”, “千葉”: “関東”,
“東京”: “関東”, “京都”: “関東”, <- おそらくコピペミス “大阪”: “関西”, “兵庫”: “関西”, ]
異なる観点からのチェック レビューしてみよう(疑似コードです) val pref_jabanese_english_map = [ “栃木” : “tochigi”, “埼玉” : “saitama”,
“茨城” : “ibaragi”, “群馬” : “gunma”, “千葉” : “chiba”, “東京” : “tokyo”, “神奈川”: “kanagawa”, ]
異なる観点からのチェック レビューしてみよう(疑似コードです) val pref_jabanese_english_map = [ “栃木” : “tochigi”, “埼玉” : “saitama”,
“茨城” : “ibaragi”, <- ibaraki “群馬” : “gunma”, “千葉” : “chiba”, “東京” : “tokyo”, “神奈川”: “kanagawa”, ] 東日本出身者のほうが気付くか も(実は、自分はずっとibaragi だとおもってましたorz
レビュー依頼の心得 WHO:誰に WHY:なぜ(なにを期待して) WHAT:何を HOW:どのようにチェックしてもらうか
レビューして欲しいのは設計?実装? 設計ならクラス図やシーケンス図をレビューしたほうがよくない? 実装なら、設計については合意している? (レビュワーも設計を理解している?)
レビューして欲しいのは手順?変更箇所? どちらにしろ、このコミットの切り方だと、どこまでがツールのアウトプットで どこが手を加えたところかわからない
知るか なぜ、リファクタリングでテストコードも変えたし なぜ、大事なファイルを修正したし(コミットメッセージはWhyやHowを)
まとめ • レビューで品質を高められるかどうかは、レビューの出し方次第 • レビューを活用して品質を担保するのは作業者の責任 • 誰に、何を期待して、何を、どのようにチェックしてもらうかを意識しよう