| name | code-next-developer-review |
| description | 実装済みの差分、PR、コミット、指定ファイルを「次に開発する人が困らないか」という観点でレビューするときに使う。実装者の前提や正常系中心の説明を鵜呑みにせず、後続開発で見落とされる失敗条件や迷いやすさについて敵対的検証を行い、変更箇所の見つけやすさ、責務境界、命名、型・契約、テストの読みやすさ、前提知識の残し方、追加ケースの足しやすさ、ローカル検証のしやすさを確認したい場合に使う。欠陥、仕様違反、セキュリティ、データ破壊の検出を主目的にする場合は code-review を優先する。 |
Code Next Developer Review スキル
このスキルは、実装済みの差分を 次に開発する人が困らないか という観点でレビューする。
ここでいう「次に開発する人」は、数週間後の自分、初めてこの領域を触るチームメンバー、障害対応中に急いで読む人、類似機能を追加する人を含む。
目的
- 次の開発者が変更箇所を見つけやすい状態にする
- 変更時に守るべき前提、契約、責務境界を読み取れる状態にする
- 追加ケースや修正が局所的に済むかを確認する
- テスト、命名、コメント、ドキュメントが実装理解を助けているかを見る
- 暗黙知や作業手順の不足による手戻りを減らす
レビューの前提
- 差分を起点に見る
- 「今バグがあるか」より「次に触る人が迷うか」を優先する
- 理想論ではなく、次の開発者が実際に詰まる場面を具体化する
- 既存コード全体の問題ではなく、今回の変更で増えた迷いやすさを指摘する
- 実装者の説明やテスト結果を鵜呑みにせず、後続開発で前提が崩れる状況を想定して敵対的検証を行う
- 欠陥や重大リスクを見つけた場合は、通常の
code-review 観点として分けて書く
進め方
- 差分で追加・変更された概念、責務、型、設定、テストを把握する
- 次の開発者が行いそうな作業を 2-3 個想定する
- その作業で、どのファイルを見ればよいか、どこを変えればよいかが分かるかを見る
- 守るべき前提が型、命名、テスト、コメント、ドキュメントに残っているかを見る
references/next-developer-axes.md の必要な観点で指摘候補を整理する- 指摘は「次の開発者が困る場面」「根拠」「影響」「改善方向」に分けて出す
指摘として成立する条件
指摘は、次を満たす場合だけ出す。
- 次の開発者が何をしようとして困るのか説明できる
- 困る原因が今回の差分に紐づいている
- どのファイル、型、関数、テスト、ドキュメントで迷いが生じるか示せる
- 放置すると、変更漏れ、誤用、重複実装、調査時間の増加、レビュー往復の増加につながる
避ける指摘:
- 「好み」「美しさ」「一般論」だけのコメント
- 今回の差分で悪化していない既存の読みにくさ
- 具体的な開発シナリオを伴わない将来不安
- 実装案を一つに決めつける指摘
重要度
High
- 次の開発者が安全に変更するための必須前提が読み取れない
- 追加ケースで触るべき場所が散らばり、変更漏れが高確率で起きる
- 型、契約、責務境界が曖昧で、誤用すると公開挙動やデータを壊しうる
- ローカル検証や再現手順がなく、変更後に正しさを確認しづらい
Medium
- 命名、配置、テスト名、コメント不足により、初見の理解や調査に時間がかかる
- 追加ケースの実装パターンが読み取りづらく、重複や条件分岐が増えやすい
- テストが何を保証しているか分かりづらく、変更時の安心材料になっていない
- 暗黙の業務ルール、設定値、順序依存、例外条件がコードから読み取りづらい
Low
- 小さな命名、コメント、テスト整理で次の開発者の迷いを減らせる
- 後続課題として残せば十分な開発者体験の改善
- 今すぐ詰まらないが、近い変更で説明コストが増えそうなもの
レビュー観点
詳細な観点は references/next-developer-axes.md を参照する。
必要な観点だけを使う。すべてを網羅するより、次の開発者が本当に困る点を優先する。
出力形式
出力は次の順で行う。
- 次の開発者が困る点
- 重要度 High / Medium / Low
- ファイル / 行
- 困る開発シナリオ
- 根拠
- 影響
- 改善方向
- 次の開発者が行いそうな作業
- 足りない手がかり
- 型、命名、テスト、コメント、ドキュメント、検証手順の不足
- 通常レビューへ回すべき即時リスク
- 短い要約
指摘がない場合:
次の開発者が困る観点での重大な指摘はなし と明示する- 見た範囲と残る不確実性を書く
注意
- 次の開発者の行動を具体化してから指摘する
- 欠陥レビュー、設計レビュー、リファクタリング提案と混ぜすぎない
- 改善方向は示してよいが、パッチ作成を主目的にしない
- 「自分ならこう書く」ではなく「次の人がどこで迷うか」を軸にする
