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
150
ペアレビューは同期的でなくてもよくないですか?
Kyoto.js 19 にて
ten986
May 26, 2023
Tweet
Share
More Decks by ten986
See All by ten986
ANGEL Dojo 最終発表資料
ten986
0
910
自作のEsolangでQuineを書いてみた
ten986
0
260
【解説付き】自作のEsolangでQuineに挑戦してみた
ten986
0
170
Other Decks in Programming
See All in Programming
Ruby Parser progress report 2025
yui_knk
1
270
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
2
1.8k
Improving my own Ruby thereafter
sisshiki1969
1
150
Laravel Boost 超入門
fire_arlo
2
180
AIエージェント開発、DevOps and LLMOps
ymd65536
1
380
rage against annotate_predecessor
junk0612
0
160
MCPでVibe Working。そして、結局はContext Eng(略)/ Working with Vibe on MCP And Context Eng
rkaga
5
1.6k
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
390
ECS初心者の仲間 – TUIツール「e1s」の紹介
keidarcy
0
150
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
3
1.2k
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
330
TROCCO×dbtで実現する人にもAIにもやさしいデータ基盤
nealle
0
410
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Side Projects
sachag
455
43k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Statistics for Hackers
jakevdp
799
220k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
GraphQLとの向き合い方2022年版
quramy
49
14k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Code Review Best Practice
trishagee
70
19k
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にチェックポイントを設ける • チェックポイントまでは非同期でレビュー • チェックポイントの到達を同期し、全員到達したら次に向
かう • 非同期レビュー中に疑問点があれば、都度声を挙げて同 期的に解決する