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
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');
  }
  return db.users.create({ email, password });
}
\`\`\`

例 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 API_KEY = 'sk_live_abc123xyz';
\`\`\`

**✅ 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

---

Pro Tip: 一貫性と網羅性を確保するため、すべてのレビューでチェックリストのテンプレートを使用してください。チームの特定のニーズに合わせてカスタマイズしてください。