laravel:code-review-requests

代码审查请求

聚焦的审查请求能获得可执行的反馈。含糊的请求只能得到泛泛的建议。

指定关注领域

含糊

“审查这段代码”

聚焦

“审查 OrderService 的安全性和性能：

关注以下方面：

• 授权检查（是否验证用户拥有该订单？）
• SQL 注入风险（是否有原始查询？）
• N+1 查询问题（是否正确使用了预加载？）
• 事务处理（操作是否具有原子性？）
• 错误处理（是否能优雅地处理失败？）

代码：

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 进行验证？
• 相较于手动赋值，批量赋值是否更安全？
• 响应是否应该使用 Resource？
• 密码哈希是否处理正确？
• 用户创建是否应该放在服务/操作中？
• 是否缺少授权检查？
• 是否遵循 Laravel 13.x 约定？”

**有效原因：**针对具体的 Laravel 模式和约定提出问题。

指定经验水平

深度不明确

“审查我的代码”

深度明确

“审查此身份验证实现：

**我的经验：**初级开发者，有 6 个月 Laravel 经验

我需要：

• 详细解释任何安全问题（我还在学习身份验证最佳实践）
• 指出我遗漏的 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——询问框架特有的模式
• 设定深度——初级开发者需要解释，资深开发者需要快速反馈

聚焦的请求 = 可执行的反馈。