code-review-checklist

コードレビューのチェックリスト

概要

徹底したコードレビューを実施するための体系的なチェックリストを提供します。このスキルは、レビュアーがコード品質を確保し、バグを発見し、セキュリティ上の問題を特定し、コードベース全体の一貫性を保つのに役立ちます。

このスキルを使うタイミング

• プルリクエストをレビューするとき
• コード監査を実施するとき
• チームのコードレビュー基準を定めるとき
• 新しい開発者にコードレビューの実践方法を教えるとき
• レビューで見落としがないようにしたいとき
• コードレビューのドキュメントを作成するとき

動作の仕組み

ステップ 1：背景を把握する

コードをレビューする前に、次の点を把握できるようサポートします。

• このコードはどのような問題を解決しますか？
• 要件は何ですか？
• どのファイルが変更され、その理由は何ですか？
• 関連する課題やチケットはありますか？
• テスト戦略はどのようなものですか？

ステップ 2：機能をレビューする

コードが正しく動作するか確認します。

• 述べられている問題を解決していますか？
• エッジケースに対応していますか？
• エラー処理は適切ですか？
• ロジック上の誤りはありませんか？
• 要件に合致していますか？

ステップ 3：コード品質をレビューする

コードの保守性を評価します。

• コードは読みやすく、明確ですか？
• 名前は内容を適切に表していますか？
• 適切に構成されていますか？
• 関数やメソッドの役割は絞られていますか？
• 不必要に複雑ではありませんか？

ステップ 4：セキュリティをレビューする

セキュリティ上の問題がないか確認します。

• 入力値は検証されていますか？
• 機密データは保護されていますか？
• SQL インジェクションのリスクはありますか？
• 認証や認可は適切ですか？
• 依存関係は安全ですか？

ステップ 5：パフォーマンスをレビューする

パフォーマンス上の問題がないか確認します。

• 不必要なループはありませんか？
• データベースアクセスは最適化されていますか？
• メモリーリークはありませんか？
• キャッシュは適切に使用されていますか？
• N+1 クエリの問題はありませんか？

ステップ 6：テストをレビューする

テストの網羅性を確認します。

• 新しいコードに対するテストはありますか？
• テストはエッジケースを網羅していますか？
• テストには意味がありますか？
• すべてのテストが成功しますか？
• テストカバレッジは十分ですか？

例

例 1：機能レビューのチェックリスト

## Functionality Review

### Requirements
- [ ] Code solves the stated problem
- [ ] All acceptance criteria are met
- [ ] Edge cases are handled
- [ ] Error cases are handled
- [ ] User input is validated

### Logic
- [ ] No logical errors or bugs
- [ ] Conditions are correct (no off-by-one errors)
- [ ] Loops terminate correctly
- [ ] Recursion has proper base cases
- [ ] State management is correct

### Error Handling
- [ ] Errors are caught appropriately
- [ ] Error messages are clear and helpful
- [ ] Errors don't expose sensitive information
- [ ] Failed operations are rolled back
- [ ] Logging is appropriate

### Example Issues to Catch:

**❌ Bad - Missing validation:**
\`\`\`javascript
function createUser(email, password) {
  // No validation!
  return db.users.create({ email, password });
}
\`\`\`

**✅ Good - Proper validation:**
\`\`\`javascript
async function createUser(email, password) {
  if (!email || !isValidEmail(email)) {
    throw new Error('Invalid email address');
  }
  if (!password || password.length < 8) {
    throw new Error('Password must be at least 8 characters');
  }
  const passwordHash = await hashPassword(password); // configured password-hashing library
  return db.users.create({ email, passwordHash });
}
\`\`\`

例 2：セキュリティレビューのチェックリスト

## Security Review

### Input Validation
- [ ] All user inputs are validated
- [ ] SQL injection is prevented (use parameterized queries)
- [ ] XSS is prevented (escape output)
- [ ] CSRF protection is in place
- [ ] File uploads are validated (type, size, content)

### Authentication & Authorization
- [ ] Authentication is required where needed
- [ ] Authorization checks are present
- [ ] Passwords are hashed (never stored plain text)
- [ ] Sessions are managed securely
- [ ] Tokens expire appropriately

### Data Protection
- [ ] Sensitive data is encrypted
- [ ] API keys are not hardcoded
- [ ] Environment variables are used for secrets
- [ ] Personal data follows privacy regulations
- [ ] Database credentials are secure

### Dependencies
- [ ] No known vulnerable dependencies
- [ ] Dependencies are up to date
- [ ] Unnecessary dependencies are removed
- [ ] Dependency versions are pinned

### Example Issues to Catch:

**❌ Bad - SQL injection risk:**
\`\`\`javascript
const query = \`SELECT * FROM users WHERE email = '\${email}'\`;
db.query(query);
\`\`\`

**✅ Good - Parameterized query:**
\`\`\`javascript
const query = 'SELECT * FROM users WHERE email = $1';
db.query(query, [email]);
\`\`\`

**❌ Bad - Hardcoded secret:**
\`\`\`javascript
const leakedToken = '[redacted live key]';
\`\`\`

**✅ Good - Environment variable:**
\`\`\`javascript
const API_KEY = process.env.API_KEY;
if (!API_KEY) {
  throw new Error('API_KEY environment variable is required');
}
\`\`\`

例 3：コード品質レビューのチェックリスト

## Code Quality Review

### Readability
- [ ] Code is easy to understand
- [ ] Variable names are descriptive
- [ ] Function names explain what they do
- [ ] Complex logic has comments
- [ ] Magic numbers are replaced with constants

### Structure
- [ ] Functions are small and focused
- [ ] Code follows DRY principle (Don't Repeat Yourself)
- [ ] Proper separation of concerns
- [ ] Consistent code style
- [ ] No dead code or commented-out code

### Maintainability
- [ ] Code is modular and reusable
- [ ] Dependencies are minimal
- [ ] Changes are backwards compatible
- [ ] Breaking changes are documented
- [ ] Technical debt is noted

### Example Issues to Catch:

**❌ Bad - Unclear naming:**
\`\`\`javascript
function calc(a, b, c) {
  return a * b + c;
}
\`\`\`

**✅ Good - Descriptive naming:**
\`\`\`javascript
function calculateTotalPrice(quantity, unitPrice, tax) {
  return quantity * unitPrice + tax;
}
\`\`\`

**❌ Bad - Function doing too much:**
\`\`\`javascript
function processOrder(order) {
  // Validate order
  if (!order.items) throw new Error('No items');
  
  // Calculate total
  let total = 0;
  for (let item of order.items) {
    total += item.price * item.quantity;
  }
  
  // Apply discount
  if (order.coupon) {
    total *= 0.9;
  }
  
  // Process payment
  const payment = stripe.charge(total);
  
  // Send email
  sendEmail(order.email, 'Order confirmed');
  
  // Update inventory
  updateInventory(order.items);
  
  return { orderId: order.id, total };
}
\`\`\`

**✅ Good - Separated concerns:**
\`\`\`javascript
function processOrder(order) {
  validateOrder(order);
  const total = calculateOrderTotal(order);
  const payment = processPayment(total);
  sendOrderConfirmation(order.email);
  updateInventory(order.items);
  
  return { orderId: order.id, total };
}
\`\`\`

「関心事を分離する」順序の例は、構造のみを示しています。実際の決済、在庫、メールの処理では、失敗を待機して処理し、冪等性を確保したうえで、トランザクション／アウトボックス方式または補償戦略が必要です。検証だけでは、パスワードの保存は安全になりません。チェックリストには、確認、テスト、または利用できなかった項目を記録してください。確認していない項目にチェックを付けたり、スキャナーで検出されなかったことを問題がない証拠と見なしたりしないでください。

ベストプラクティス

✅ 推奨事項

• 小さな変更をレビューする - PR が小さいほど、徹底してレビューしやすくなります
• まずテストを確認する - テストが成功し、新しいコードをカバーしていることを確認します
• コードを実行する - 可能であれば、ローカルでテストします
• 質問する - 決めつけず、説明を求めます
• 建設的に伝える - 批判だけでなく、改善案を提案します
• 重要な問題に集中する - 細かなスタイル上の問題にこだわりすぎないようにします
• 自動化ツールを使う - リンター、フォーマッター、セキュリティスキャナーを活用します
• ドキュメントを確認する - ドキュメントが更新されているか確認します
• パフォーマンスを考慮する - 規模と効率を考慮します
• リグレッションを確認する - 既存の機能が引き続き動作することを確認します

❌ 避けるべきこと

• 読まずに承認しない - 実際にコードをレビューします
• 曖昧な指摘をしない - 例を挙げて具体的にフィードバックします
• セキュリティを軽視しない - セキュリティ上の問題は重大です
• テストを省略しない - テストされていないコードは問題を引き起こします
• 失礼な態度を取らない - 敬意を払い、プロフェッショナルに対応します
• 形式的な承認をしない - すべてのレビューに価値を加えます
• 疲れているときにレビューしない - 重要な問題を見落とす可能性があります
• 背景を忘れない - 全体像を把握します

完全なレビューチェックリスト

レビュー前

• PR の説明と関連する課題を読む
• 解決しようとしている問題を把握する
• CI/CD でテストが成功しているか確認する
• ブランチを取得し、ローカルで実行する

機能

• コードが提示された問題を解決している
• エッジケースに対応している
• 適切なエラー処理が行われている
• ユーザー入力が検証されている
• 論理的な誤りがない

セキュリティ

• SQL インジェクションの脆弱性がない
• XSS の脆弱性がない
• 認証／認可が正しく行われている
• 機密データが保護されている
• シークレットがハードコードされていない

パフォーマンス

• 不要なデータベースクエリがない
• N+1 クエリの問題がない
• 効率的なアルゴリズムが使用されている
• メモリリークがない
• キャッシュが適切に使用されている

コード品質

• コードが読みやすく、明確である
• 名前が内容を適切に表している
• 関数が目的に絞られ、小さく保たれている
• コードの重複がない
• プロジェクトの規約に従っている

テスト

• 新しいコードにテストがある
• テストでエッジケースが網羅されている
• テストに意味がある
• すべてのテストに合格している
• テストカバレッジが十分である

ドキュメント

• コードのコメントで、何をするかではなく、なぜそうするかを説明している
• API ドキュメントが更新されている
• 必要に応じて README が更新されている
• 破壊的変更が文書化されている
• 必要に応じて移行ガイドが用意されている

Git

• コミットメッセージが明確である
• マージコンフリクトがない
• ブランチが main と同期している
• 不要なファイルがコミットされていない
• .gitignore が適切に設定されている

よくある落とし穴

問題：エッジケースへの対応漏れ

症状： 正常系では動作するが、エッジケースで失敗する 解決策： 「もし〜だったら？」と問いかける

• 入力が null だったら？
• 配列が空だったら？
• ユーザーが認証されていなかったら？
• ネットワークリクエストが失敗したら？

問題：セキュリティの脆弱性

症状： コードがセキュリティリスクを招く 解決策： セキュリティチェックリストを使用する

• セキュリティスキャナーを実行する（npm audit、Snyk）
• OWASP Top 10 を確認する
• すべての入力を検証する
• パラメーター化クエリを使用する
• ユーザー入力を決して信頼しない

問題：テストカバレッジの不足

症状： 新しいコードにテストがない、またはテストが不十分である 解決策： すべての新しいコードにテストを必須とする

• 関数のユニットテスト
• 機能の統合テスト
• エッジケースのテスト
• エラーケースのテスト

問題：コードが不明瞭

症状： レビュアーがコードの動作を理解できない 解決策： 改善を依頼する

• より適切な変数名
• 説明コメント
• より小さな関数
• 明確な構造

レビューコメントのテンプレート

変更を依頼する

**Issue:** [Describe the problem]

**Current code:**
\`\`\`javascript
// Show problematic code
\`\`\`

**Suggested fix:**
\`\`\`javascript
// Show improved code
\`\`\`

**Why:** [Explain why this is better]

質問する

**Question:** [Your question]

**Context:** [Why you're asking]

**Suggestion:** [If you have one]

良いコードを称賛する

**Nice!** [What you liked]

This is great because [explain why]

関連スキル

• @requesting-code-review - レビューに向けてコードを準備する
• @receiving-code-review - レビューのフィードバックに対応する
• @systematic-debugging - レビューで見つかった問題をデバッグする
• @test-driven-development - コードにテストがあることを確認する

追加リソース

• Google Code Review Guidelines
• OWASP Top 10
• Code Review Best Practices
• How to Review Code

---

プロのヒント： 一貫性と徹底性を確保するため、レビューのたびにチェックリストのテンプレートを使用しましょう。チーム固有のニーズに合わせてカスタマイズしてください！

制限事項

• このスキルは、タスクが上記の説明にある適用範囲に明確に合致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。