Kyoto.js 19 にて
ペアレビューは同期的でなくてもよくないですか?5/26 Kyoto.js @ten986
View Slide
自己紹介● 名前: 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にチェックポイントを設ける● チェックポイントまでは非同期でレビュー● チェックポイントの到達を同期し、全員到達したら次に向かう● 非同期レビュー中に疑問点があれば、都度声を挙げて同期的に解決する