私は10年間で数千のプルリクエストをレビューしてきました。パターンは驚くほど一貫しており、言語、フレームワーク、開発者の経験レベルにかかわらず、同じタイプの問題が繰り返し発生します。
私が実際に探していること
50項目の教科書的なコードレビューチェックリストは忘れてください。実際には、90%の実際の問題を捉える5つのことに集中しています：
1. エラーハンドリング
生産上のインシデントの最大の原因です。私が尋ねる質問：このAPI呼び出しが失敗した場合はどうなりますか？データベースがダウンした場合はどうしますか？入⼒がnullの場合はどうですか？答えが「クラッシュする」ですと問題です。
2. エッジケース
空の配列、ゼロ値、非常に大きな入力、ユニコード文字、同時リクエスト。ハッピーパスは常に機能します。エッジケースはバグが潜んでいる場所です。
3. セキュリティ
ユーザー入力がSQLクエリ、HTML、またはシェルコマンドに直接入ること。エンドポイントでの認証チェックが欠落しています。ソースコードにハードコーディングされた秘密。Googleのコードレビューガイドラインによれば、セキュリティの問題はすべてのPRをブロックすべきです。
4. 可読性
このコードを書いていない人が30秒で理解できますか？内容を説明する変数名。一つのことを行う関数。何故かではなく、何を説明するコメント。
5. パフォーマンス（重要な場合）
N+1データベースクエリ、不必要な再レンダリング、大規模データセットに対するO(n²)アルゴリズム。私は早急に最適化はしませんが、明らかなパフォーマンスの問題には注意を促します。
レビュープロセス
AIコードレビュアーは、コードレビューの機械的な部分を自動化します — 一般的なパターン、セキュリティの問題、スタイル違反をチェックします。しかし、アーキテクチャの決定やビジネスロジックのために人間のレビューに取って代わることはありません。
私のプロセス：AIレビュー（明らかなものをキャッチ）→ 人間レビュー（微妙なものをキャッチ）→ ディスカッション（意見の不一致を解決）。
良いフィードバックを与える方法
- 具体的であること。「これをもっと良くできる」と言うのは無意味です。「このSQLクエリはインジェクションに対して脆弱です — その代わりにパラメータ化されたクエリを使用してください」は実行可能です。
- 理由を説明する。「これを変更してください」と言うだけでなく、開発者が学ぶためにその理由を説明してください。
- ブロッカーと提案を区別する。「修正必須：セキュリティの問題」と「ニット：この変数の名前を明確にするために変更したい」
- 良いコードを称賛する。「ここでの素晴らしいエラーハンドリング」は良い習慣を強化します。