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
690
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.7k
Other Decks in Technology
See All in Technology
SIEMを用いて、セキュリティログ分析の可視化と分析を実現し、PDCAサイクルを回してみた
coconala_engineer
0
320
元インフラエンジニアに成る / Human Resources to Human Relations
bobtani
4
920
Building Dashboards as a Hobby
egmc
0
220
ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない
saramune
0
160
非同期推論システムによるコスト削減と信頼性向上
koki_nishihara
0
260
開発パフォーマンスを最大化するための開発体制
ham0215
2
420
エンジニア候補者向け資料2024.04.24.pdf
macloud
0
3.3k
GrafanaMeetup_AmazonManagedGrafanaのアクセス制御機能とマルチテナント環境下でのアクセス制御について
daitak
0
230
DMM.com アルファ室採用案内資料
hsugita
1
150
JAWS-UG Bedrock Claude Night
yamahiro
3
610
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
5
530
開発生産性大幅アップ!Postman VS Code拡張機能
nagix
2
380
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
355
18k
KATA
mclloyd
15
12k
Gamification - CAS2011
davidbonilla
76
4.6k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
Design by the Numbers
sachag
274
18k
Build your cross-platform service in a week with App Engine
jlugia
225
17k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
19
1.7k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
YesSQL, Process and Tooling at Scale
rocio
164
13k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Being A Developer After 40
akosma
57
580k
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を)
まとめ • レビューで品質を高められるかどうかは、レビューの出し方次第 • レビューを活用して品質を担保するのは作業者の責任 • 誰に、何を期待して、何を、どのようにチェックしてもらうかを意識しよう