コードレビューを書式の議論にしないために
役に立つレビューが答えるのは二つだけです。この変更は壊れる可能性があるか、壊れたときに気づけるか。それ以外は二次的です。
進め方
作者がまず差分を自分で見る
PR を出す前に、diff を「コードレビュー」に貼ります。バグ、セキュリティ、性能につながる箇所だけを重大度順に残し、それぞれ発現条件と具体的な修正方法を書かせます。直してから同僚に依頼すれば、やり取りが一回減ります。書式はリンタに任せ、レビューの注意を奪わないようにします。
変更が正しいことを示すテストを足す
実装と現在のテストを「テストの抜けを見つける」に渡します。未カバーの分岐を洗い出し、本番影響の大きい五件を追加し、重複したテストと内部実装を検証するテストを削ります。レビュアーには「テストを足しました」ではなく、どの失敗シナリオをどのテストが守るかが見えるようになります。
レビュアーはコードより先に影響範囲を見る
diff、依存関係、トラフィック量を「変更の影響範囲を見積もる」に渡します。影響を受ける呼び出し元、データ、定期処理を挙げ、影響人数と復旧の難しさで上位三件を並べ、切り戻しのしきい値を出させます。影響の大きい変更では、変数名より切り戻し手順と公開順序をレビューの中心にします。
失敗経路を追う
diff のうちエラー処理の部分を「エラー処理をレビューする」に渡します。握りつぶされた例外、追跡できないエラーメッセージ、安全でない重複書き込み、失敗すべきなのに動き続ける箇所を見ます。テストでは拾いにくく、コードを読む人が必要な領域です。
並行性が関わる箇所は別に通す
共有状態に触れる変更なら、関係するコードを「並行性と競合状態のレビュー」に渡します。二つのリクエストが同じミリ秒に届くと仮定し、共有される可変状態、確認と使用の間の隙間、破綻する負荷、最小の修正とそのコストを挙げさせます。共有状態がなければ飛ばして構いません。
使うプロンプト
よくある質問
AI のコードレビューは同僚のレビューの代わりになりますか
なりません。AI はインジェクション、null 参照、N+1 のようなパターンの問題はある程度見つけますが、業務上の制約、過去の障害、リリースの状況は知りません。同僚の価値は、この変更を今やるべきか、他の作業と衝突しないかを判断できることです。
レビューの指摘が多すぎるとき、どう優先しますか
まずデータの誤りや本番障害につながるかで絞り、次に発現条件が現実的かを見ます。書式の指摘はリンタとフォーマッタに任せ、議論に持ち込みません。残ったものは、直すのが安く効果が明確なものから進めます。
小さな変更でもこの手順が必要ですか
すべては不要です。設定一行の変更ならステップ1と切り戻しの確認だけで足ります。共有状態、権限、お金に関わる変更は、ステップ4と5を省けません。判断は変更行数ではなく、壊れたときの影響で行います。