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
ペアレビューは同期的でなくてもよくないですか?
Search
ten986
May 26, 2023
Programming
2
140
ペアレビューは同期的でなくてもよくないですか?
Kyoto.js 19 にて
ten986
May 26, 2023
Tweet
Share
More Decks by ten986
See All by ten986
ANGEL Dojo 最終発表資料
ten986
0
820
自作のEsolangでQuineを書いてみた
ten986
0
220
【解説付き】自作のEsolangでQuineに挑戦してみた
ten986
0
140
Other Decks in Programming
See All in Programming
AWS Organizations で実現する、 マルチ AWS アカウントのルートユーザー管理からの脱却
atpons
0
130
Domain-Driven Transformation
hschwentner
2
1.9k
最近のVS Codeで気になるニュース 2025/01
74th
1
260
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
150
SwiftUI Viewの責務分離
elmetal
PRO
1
220
Formの複雑さに立ち向かう
bmthd
1
810
DevinとCursorから学ぶAIエージェントメモリーの設計とMoatの考え方
itarutomy
1
670
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
170
[Fin-JAWS 第38回 ~re:Invent 2024 金融re:Cap~]FaultInjectionServiceアップデート@pre:Invent2024
shintaro_fukatsu
0
410
GAEログのコスト削減
mot_techtalk
0
120
XStateを用いた堅牢なReact Components設計~複雑なClient Stateをシンプルに~ @React Tokyo ミートアップ #2
kfurusho
1
870
時計仕掛けのCompose
mkeeda
1
290
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
Site-Speed That Sticks
csswizardry
3
370
Designing for Performance
lara
604
68k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
430
Rails Girls Zürich Keynote
gr2m
94
13k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
KATA
mclloyd
29
14k
GraphQLとの向き合い方2022年版
quramy
44
13k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Visualization
eitanlees
146
15k
Transcript
ペアレビューは 同期的でなくても よくないですか? 5/26 Kyoto.js @ten986
自己紹介 • 名前: ten986 ◦ 呼び: てん / てんきゅー •
株式会社ゆめみ 新卒2年目 • フロントエンドエンジニア ◦ バックエンドも書く • 最近はNext.jsとKotlinやってる • 6月末に東京に引っ越す
注意 • 今日登壇することになりました • 今日作りました ◦ 業務放り出して作ってました • js関係ないです •
元記事が書けたが1時間前です • スライドはさっきできました
今日話すことの要約 • 半同期的ペアレビューの提案 • Pull Requestにチェックポイントを設ける • チェックポイントまでは非同期でレビュー • チェックポイントの到達を同期し、全員到達したら次に向
かう • 非同期レビュー中に疑問点があれば、都度声を挙げて同 期的に解決する
背景 • 数人〜数十人の開発チーム • Pull Request(PR)のマージに 2人のコードレビューが必要 • あなたはレビュワーのうちの1人となっている
非同期レビュー • 簡単なPRの場合 • 2人のレビュワーがそれぞれ自由な時間に レビューするとよい • タイミングを非同期的に行えるので、 今回は非同期レビューと呼ぶことにする
非同期レビュー • 自分の時間でできる • 自分のペースでPRを読める • 自分の詳しくない範囲の質問はすぐにはできない • 総じて簡単めなPR向け
ペアレビューの導入 • 開発現場では、時折難しいPRが出てくる ◦ 仕様上難しい・実装上難しい、など・・・ • それを1人で非同期レビューで行うと効率が悪い • そこでペアレビューが使われる ◦
3人以上ならモブレビューとも
ペアレビュー • 2人で時間を合わせて、集まってレビューする • 疑問点に当たった時に相方にすぐ質問できるので、 お互い能力を補い合い、質のいいレビューを高速に提供 できる • 強制的に時間を作れるので、モチベーション面でも ◦
もう1人のレビュワーからの監視の目 • 難しめなPRで使うとよい
同期的ペアレビューと呼ぶ • ペアレビューは同期的になりがち • 「PRの概要」「読むコードの箇所」を逐一同期する • レビュワーの片方が音読し、もう1人が聞くイメージ • このような同期的に行われるレビューを、ここでは 同期的ペアレビューと呼ぶことにする
同期的ペアレビューは非効率 • ペアレビューを逐一同期して行うと・・・ • 簡単な箇所も同期的に読んでしまう ◦ PRの概要のごく簡単な部分は読み飛ばしたい • コードを読む際、人の順番に合わせないといけない ◦
人によって読む順も読む速度も違う ◦ ある箇所はAさんのが早い、別の箇所はBさんが早い ◦ 自分のペースでレビューした方が早い箇所が多い
同期的ペアレビューを改善する • 同期的ペアレビューの改善点は 同期的に行いすぎていることから来ていそう
同期的ペアレビューを改善する • 同期的に行いすぎない • ペアレビューする以上「レビュワー同士の能力を補完する ことで、高速に質のいいレビューを行う」 ことを犠牲にしたくない • 難しいPRといえど、簡単な箇所もある ◦
その箇所は非同期レビューで行った方が早い
半同期的ペアレビュー • ペアレビューなので、時間を揃えて集まる • PRにチェックポイントを作る • チェックポイントに到達するまで、 各レビュワーは非同期的にレビュー ◦ 疑問点や指摘点などが出次第必ず発言し、同期的に解決
• チェックポイントだけレビュワー間で同期 ◦ 到達時に報告、全員が到達したら次に進む
チェックポイント • 例えば以下のように設ける ◦ PRの概要まで ◦ PRの動作確認を読み、実行するまで ◦ コミットXを読み、レビューコメントをつけるまで ◦
コミットYを読み、レビューコメントをつけるまで ◦ コミットZを読み、レビューコメントをつけるまで
半同期的ペアレビューのポイント • 基本的に非同期レビューをするので、 簡単な場所の同期など余計な時間を使わない ◦ 同期的ペアレビューの欠点解消 • チェックポイント間の同期をするので、 レビュー時の疑問点の文脈を共有しやすい ◦
レビュワー同士の能力を補完する目的が達成できる
余談 • 同期しすぎることで起きる問題点は、全部「チェックポイン トを用意して非同期で読む」ことで解決できそうな気がし ます。 • 「読書会」なんかでも、各人が音読して回し読みするより、 チェックポイントだけ同期した方が理解早いかもしれない ですね。
今日話すことの要約(再放送) • 半同期的ペアレビューの提案 • Pull Requestにチェックポイントを設ける • チェックポイントまでは非同期でレビュー • チェックポイントの到達を同期し、全員到達したら次に向
かう • 非同期レビュー中に疑問点があれば、都度声を挙げて同 期的に解決する