laravel:code-review-requests

コードレビューの依頼

焦点を絞った依頼には、実行可能なフィードバックが返ってきます。曖昧な依頼には、一般的なアドバイスしか返ってきません。

確認してほしい点を指定する

曖昧な依頼

「このコードをレビューしてください」

焦点を絞った依頼

「OrderService のセキュリティとパフォーマンスをレビューしてください。

確認してほしい点：

• 認可チェック（ユーザーが注文の所有者であることを確認していますか？）
• SQL インジェクションのリスク（生のクエリを使用していますか？）
• N+1 クエリの問題（Eager Loading は適切ですか？）
• トランザクション処理（操作はアトミックですか？）
• エラー処理（問題発生時に適切に処理できますか？）

コード：

class OrderService
{
    public function createOrder(User $user, array $items): Order
    {
        $order = Order::create(['user_id' => $user->id]);
        
        foreach ($items as $item) {
            OrderItem::create([
                'order_id' => $order->id,
                'product_id' => $item['product_id'],
                'quantity' => $item['quantity'],
            ]);
        }
        
        return $order;
    }
}
```"

**Why it works:** Clear focus areas guide the review toward specific concerns.

## Provide Context

### Insufficient Context
"Is this controller okay?"

### Sufficient Context
"Review ProductController for our API:

**Context:**
- Public API used by mobile app and web frontend
- Handles 10k requests/day, needs to scale to 100k
- Products have categories (belongsTo) and reviews (hasMany)
- Using Laravel 13.x with Sanctum authentication
- Following repository pattern (ProductRepository exists)

**Concerns:**
- Is the response format consistent with our other API endpoints?
- Are we handling errors appropriately?
- Should we add rate limiting?

**Code:**
```php
class ProductController extends Controller
{
    public function index(Request $request)
    {
        $products = Product::with('category')
            ->paginate(20);
            
        return ProductResource::collection($products);
    }
}
```"

**Why it works:** Context about usage, scale, patterns, and specific concerns.

## Architectural Feedback

### Unclear
"Is the architecture good?"

### Clear
"Review the architecture of our payment processing:

**Current design:**

PaymentController → PaymentService → StripeGateway (direct Stripe API calls) → PaymentRepository (database)

**Concerns:**
1. PaymentService is tightly coupled to Stripe. What if we add PayPal?
2. No retry logic for failed payments
3. Webhook handling is in a separate controller, feels disconnected
4. No audit trail of payment attempts

**Questions:**
- Should we use a PaymentGatewayInterface for multiple providers?
- Where should retry logic live? Service or job?
- How to structure webhook handling?
- Best way to add audit logging?

**Current code:** [attach PaymentService.php]"

**Why it works:** Explains current design, identifies concerns, asks specific questions.

## Laravel-Specific Review

### Generic
"Check if this follows best practices"

### Laravel-Specific
"Review for Laravel conventions and best practices:

**Code:**
```php
class UserController extends Controller
{
    public function store(Request $request)
    {
        $validated = $request->validate([
            'email' => 'required|email|unique:users',
            'password' => 'required|min:8',
        ]);
        
        $user = new User();
        $user->email = $validated['email'];
        $user->password = Hash::make($validated['password']);
        $user->save();
        
        return response()->json($user, 201);
    }
}

確認事項：

• バリデーションは Form Request に記述すべきですか？
• 手動で代入するより、Mass Assignment を使うほうが安全ですか？
• レスポンスには Resource を使うべきですか？
• パスワードのハッシュ化は正しく処理されていますか？
• ユーザー作成処理はサービス／アクションに記述すべきですか？
• 認可チェックに漏れはありませんか？
• Laravel 13.x の規約に従っていますか？」

効果がある理由： 具体的な Laravel のパターンや規約について質問しているためです。

経験レベルを指定する

深さが不明な依頼

「コードをレビューしてください」

深さが明確な依頼

「この認証の実装をレビューしてください。

私の経験： Laravel の経験が 6 か月のジュニア開発者です。

必要なこと：

• セキュリティ上の問題を詳しく説明してください（認証のベストプラクティスをまだ学んでいるところです）
• 見落としている Laravel の規約を指摘してください
• 例を挙げて改善案を提案してください
• 問題がある場合は、その理由を説明し、正しい方法を示してください

コード：

public function login(Request $request)
{
    $user = User::where('email', $request->email)->first();
    
    if ($user && Hash::check($request->password, $user->password)) {
        $token = $user->createToken('auth')->plainTextToken;
        return response()->json(['token' => $token]);
    }
    
    return response()->json(['error' => 'Invalid credentials'], 401);
}

質問：

• 本番環境で使えるだけのセキュリティは確保できていますか？
• 見落としている点はありますか？
• シニア開発者ならどのように書きますか？」

効果がある理由： フィードバックの深さやスタイルに対する期待値を設定できます。

レビュー依頼のテンプレート

テンプレート：セキュリティレビュー

**Focus:** Security vulnerabilities and best practices
**Code:** [attach code]
**Context:** [authentication method, data sensitivity, user roles]
**Specific concerns:**
- [ ] SQL injection risks
- [ ] XSS vulnerabilities  
- [ ] Authorization checks
- [ ] Data validation
- [ ] Sensitive data exposure

テンプレート：パフォーマンスレビュー

**Focus:** Performance and scalability
**Code:** [attach code]
**Current metrics:** [response times, query counts]
**Expected load:** [requests/day, concurrent users]
**Specific concerns:**
- [ ] N+1 queries
- [ ] Missing indexes
- [ ] Inefficient algorithms
- [ ] Caching opportunities
- [ ] Memory usage

テンプレート：アーキテクチャレビュー

**Focus:** Design patterns and maintainability
**Code:** [attach code]
**Current architecture:** [describe structure]
**Team size:** [number of developers]
**Specific concerns:**
- [ ] Separation of concerns
- [ ] Testability
- [ ] Coupling between components
- [ ] Code duplication
- [ ] Complexity

テンプレート：Laravel の規約

**Focus:** Laravel best practices and conventions
**Code:** [attach code]
**Laravel version:** [e.g., 12.x or 13.x]
**Specific concerns:**
- [ ] Following framework conventions
- [ ] Using appropriate Laravel features
- [ ] Eloquent relationships correct
- [ ] Validation approach
- [ ] Resource/response formatting

クイックリファレンス

効果的なレビューを依頼するには：

• 焦点を指定する - セキュリティ、パフォーマンス、アーキテクチャ、規約
• 背景を伝える - 目的、規模、パターン、制約
• 具体的に質問する - 「これで問題ありませんか？」とだけ聞かない
• Laravel に言及する - フレームワーク固有のパターンについて質問する
• 深さを設定する - ジュニアには説明を、シニアには簡潔なフィードバックを求める

焦点を絞った依頼 ＝ 実行可能なフィードバック。