AIが生成したコードをレビューする

要約より先に要件を読む

要求された動作と受入基準から始めます。次に実際の差分を確認します。エージェントの要約は確認箇所を探す助けになりますが、変更を省略したり、確認の内容を誤って説明したりすることがあります。

レビュー対象のブランチとcommitを確認してください。アプリのコードに加えて、設定、依存関係、インフラ、テストの変更も確認します。画面上では小さな機能でも、権限やデプロイ動作の大きな変更を含む場合があります。

影響が最も大きい動作からレビューします。整形や命名も大切ですが、データ境界の欠落から注意をそらしてはいけません。

次の不完全な、架空のエンドポイントを考えます。レビュー上の問題を説明する例であり、本番用コードではありません。

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

関数は認証済みの利用者を取得しています。ただし、請求書に対する認可の判断は示していません。別の層がその判断を強制しているか、レビュー担当者が調べる必要があります。利用者の値が未使用であることは、調査する理由になります。それだけで悪用可能な不具合の証拠にはなりません。

実際のシステム内でリクエストを追跡します。信頼できる情報源に基づいて、利用者とその所属組織を特定してください。要求されたレコードへのアクセスを、クエリがどう制限するか確認します。エラー時の動作と、拒否すべきリクエストのテストも調べます。

ボタンを隠せばAPIを保護できると思わないでください。画面を使わずにリクエストを送ることもできます。有効なレコードIDがあればアクセスが許される、とも考えないでください。

成功したテストが、管理者のテストデータや認可のmockを使っている場合があります。重要な境界を実際に試しているか確認してください。必要に応じて、別の組織と実際の認可経路を使うケースを追加します。

画面の変更では、実際の表示を確認します。キーボード操作、データがない状態、読み込み中の動作、エラーを調べてください。型チェックでは、ダイアログをキーボードで使えることは確認できません。

依存関係の変更では、その必要性を確認します。バージョン、ライセンス、セキュリティの検出結果をレビューします。エージェントがタスク中に生成したというだけで、無関係なアップグレードを受け入れてはいけません。

別のモデルが有用な問題を見つける場合があります。一方、実装と同じ仮定を繰り返すこともあります。レビュー担当に要件と差分を渡してください。変更はすでに正しいと伝えることは避けます。

指摘には、具体的な不具合の発生経路と関連コードを求めます。裏付けのない警告は、調査すべき問いとして扱います。自信のある承認も、重要な主張に証拠がそろうまでは、一つの意見として扱ってください。

人によるレビューは、引き続き責任を伴う判断です。レビュー担当者は、動作、リスク、検証を説明できる程度に変更を理解する必要があります。差分が大きすぎる場合は、範囲を狭めるか、レビューできる単位に分けます。

修正後は、影響する確認を再実行します。修正で新しい問題が生じていないか調べます。リポジトリのポリシーに従い、必要なレビューが最終リビジョンに適用されていることを確認します。

受け入れの判断は、動作と証拠に基づいて記録します。残る制約には、担当者と次の対応を記録してください。未解決の問題を、すべての確認に合格したという主張に変えてはいけません。

実際の変更を調べる前に、コードレビュー演習で不足する判断を見つける練習をしてください。