よくあるアンチパターン

Laravelでよくあるアンチパターンと、実際に事故った構造を詳しく解説します。

A. リソースの「垂れ流し」

実際に事故った構造

// ❌ アンチパターン: 例外を握りつぶしてファイルやDB接続を閉じない
public function processFile($filePath)
{
    $file = fopen($filePath, 'r');
    try {
        // ファイル処理...
    } catch (Exception $e) {
        // 問題: 例外を握りつぶしてファイルを閉じない
        Log::error("File processing failed: " . $e->getMessage());
        // ファイルが閉じられず、ファイル記述子がリーク
    }
    // 問題: finallyブロックがないため、正常終了時もファイルが閉じられない
}

なぜ事故るか:

ファイル記述子の枯渇: ファイルが閉じられず、OSのファイル記述子が枯渇する
接続リーク: DB接続が閉じられず、接続プールが枯渇する
数時間後の停止: リソースリークは数時間後にシステム全体を停止させる

設計レビューでの指摘文例:

【指摘】リソースが適切に解放されていません。
【問題】例外時にファイルやDB接続が閉じられず、リソースリークが発生します。
【影響】ファイル記述子・接続プールの枯渇、数時間後のシステム停止
【推奨】try-finallyブロックまたは適切なリソース管理で確実にリソースを解放する

B. 無防備な待機

実際に事故った構造

// ❌ アンチパターン: 外部API呼び出しにタイムアウトを設定しない
public function createOrder(Request $request)
{
    return DB::transaction(function () use ($request) {
        // 1. 注文を作成（データベースに保存）
        $order = Order::create($request->all());

        // 2. トランザクション内で外部APIを呼ぶ（問題）
        // 問題: タイムアウトが設定されていない
        // 問題: サーキットブレーカーがない
        $response = Http::post('https://payment-api.example.com/charge', [
            'order_id' => $order->id,
            'amount' => $request->amount,
        ]);

        if (!$response->successful()) {
            throw new PaymentException('Payment failed');
        }

        // 3. 決済結果を保存
        $order->update(['payment_status' => 'COMPLETED']);

        return $order;
    });
}

なぜ事故るか:

トランザクションの長時間保持: 外部APIの応答を待つ間、データベースのロックが保持される
外部障害の影響: 外部APIの障害がデータベーストランザクションに影響する
ロールバックの困難: 外部APIが成功した後にトランザクションが失敗した場合、外部APIのロールバックが困難
タイムアウトのリスク: 外部APIの応答が遅い場合、トランザクションがタイムアウトする
プロセスプールの飽和: 遅延が連鎖してプロセスプールが飽和し、全エンドポイントが応答不能に

C. 非冪等な再試行

実際に事故った構造

// ❌ アンチパターン: 再送時にデータが二重登録される
public function createOrder(Request $request)
{
    // 問題: Idempotency Keyがない
    // 問題: 再実行時に注文が二重作成される
    return Order::create($request->all());
}

// クライアント側でリトライ
function createOrderWithRetry($orderData)
{
    for ($i = 0; $i < 3; $i++) {
        try {
            createOrder($orderData);
            return; // 成功
        } catch (Exception $e) {
            if ($i === 2) {
                throw $e; // 最終リトライ失敗
            }
            sleep(1 * ($i + 1)); // リトライ
        }
    }
}

なぜ事故るか:

二重登録: ネットワークエラーでクライアントが再送すると、注文が2つ作成される
データの不整合: 同じ注文が複数存在し、在庫や決済に影響する
ビジネスロジックの破綻: 重複データにより、ビジネスロジックが正しく動作しない

設計レビューでの指摘文例:

【指摘】非冪等な再試行が実装されています。
【問題】再送時にデータが二重登録され、データの不整合が発生します。
【影響】データの不整合、ビジネスロジックの破綻
【推奨】Idempotency Keyを使用して冪等性を保証する

D. N+1クエリ問題

実際に事故った構造

// ❌ アンチパターン: N+1クエリ問題
public function getOrders()
{
    $orders = Order::all();

    // 問題: 注文ごとにユーザーを取得（N+1クエリ）
    foreach ($orders as $order) {
        $user = $order->user; // 各ループでクエリが実行される
    }

    return $orders;
}

なぜ事故るか:

クエリ数の増加: 注文が100件ある場合、101回のクエリが実行される
パフォーマンスの低下: データベースへのアクセス回数が増加し、パフォーマンスが低下する
スケーラビリティの問題: データが増えると、パフォーマンスがさらに低下する

設計レビューでの指摘文例:

【指摘】N+1クエリ問題が発生しています。
【問題】注文ごとにユーザーを取得するため、クエリ数が増加します。
【影響】パフォーマンスの低下、データベースへの負荷増加
【推奨】eager loading（with）を使用して関連データを事前に読み込む

まとめ

よくあるアンチパターンのポイント：

A. リソースの「垂れ流し」: 例外を握りつぶしてファイルやDB接続を閉じない → 数時間後にシステム停止
B. 無防備な待機: 外部API呼び出しにタイムアウトを設定しない → プロセスプールの飽和、全エンドポイントの応答不能
C. 非冪等な再試行: 再送時にデータが二重登録される → データの不整合、ビジネスロジックの破綻
D. N+1クエリ問題: クエリ数の増加、パフォーマンスの低下

これらのアンチパターンを避けることで、安全で信頼性の高いLaravelアプリケーションを構築できます。

重要な原則: 「正常に動く」よりも「異常時に安全に壊れる」ことを優先する。