GIT PRレビュー観点チェック表(現場用)
- リンクを取得
- ×
- メール
- 他のアプリ
いいね、レベル4=「レビューできる・守れる」段階に入ってる 👍
ここでは**実務でそのまま使える「PRレビュー観点チェック表」**を渡すね。
PRレビュー観点チェック表(現場用)
※ 上から順に見ればOK
※ ★は特に重要(まずここだけ見てもレビューになる)
① 目的・前提(★最重要)
「このPRは何を解決するのか」
-
PRタイトルが作業内容を表している
-
PR概要に「なぜやるか」が書かれている
-
影響範囲(どのページ / 機能 / 環境)が分かる
-
チケット・課題・要望と紐づいている
👉 ここが曖昧なら、コードを見なくていい
「このPRのゴールを一言で教えてください」
② 差分の粒度・構成(★)
「このPRは大きすぎないか?」
-
1つの目的に対して1つのPRになっている
-
無関係な修正(空白・整形・別機能)が混ざっていない
-
ファイル数・行数が妥当
-
レビュー可能な量か(5〜15分で読める)
👉 NG例
-
機能追加 + デザイン修正 + リファクタ
-
「ついでに直しました」
③ 影響範囲・壊れやすさ(★)
「戻せるか?壊れないか?」
-
既存機能への影響が想定されている
-
共通JS / 共通CSS / 共通コンポーネントを触っていないか
-
既存の挙動が変わる点が明記されている
-
rollback(戻す)手段がある
👉 ディレクター視点の質問
「このPRをrevertしたら何が起きますか?」
④ コード・実装の妥当性
「今じゃなくて未来の人が困らないか」
-
命名が意図を表している
-
魔法の数値・ハードコードがない
-
同じ処理をコピペしていない
-
コメントが「なぜ」を説明している
※ 書き方の好みではなく
**「保守性・再利用性・理解コスト」**で見る
⑤ 可読性・レビューしやすさ
「読む側への配慮があるか」
-
不要な差分が含まれていない
-
フォーマットが崩れていない
-
PR内コメントで補足がある
-
レビュアーが迷わない構成
👉 良いPRの特徴
-
「ここが一番見てほしいです」
-
「この判断は○○の理由です」
⑥ 動作確認・検証
「本当に動くか」
-
ローカル / 検証環境での確認内容が書いてある
-
確認URL・操作手順がある
-
edgeケース(スマホ / 古いブラウザ等)を考慮
-
未確認点・不安点が明示されている
👉 完璧より正直さが大事
⑦ マージ判断(★)
「今マージしていいか?」
-
mainに入っても事故らない
-
他PRと競合しにくい
-
緊急度とリスクが釣り合っている
-
必要なら「条件付きOK」にしている
よくある判断パターン
-
✅ LGTM(問題なし)
-
⚠️ 条件付きOK(後続PR前提)
-
❌ 差し戻し(粒度 or 目的)
レベル4の人がよく使うレビューコメント例
-
「目的は理解できました。影響範囲だけもう少し明記ください」
-
「この修正、別PRに分けた方が安全そうです」
-
「rollback時の影響を教えてもらえますか?」
-
「急ぎ対応としてはOKですが、後続で整理PRを切りましょう」
👉 技術マウントはしない/判断軸を言語化する
コメント
コメントを投稿