مراجعة كود PHP: 10 أخطاء تثير حنق كبار المطورين

مقدمة: لماذا يُطلب منك إعادة كتابة كود PHP الخاص بك؟

لقد أرسلت طلب سحب (Pull Request) وأنت مليء بالثقة بأنك كتبت كوداً مثالياً. تمر ساعة، وتجد 15 تعليقاً من مطور كبير. هل هذا مألوف؟ مراجعة الكود في PHP ليست مجرد إجراء شكلي، بل هي اختبار حقيقي للنضج. ينظر كبار المطورين إلى الكود ليس كمجموعة تعليمات، بل كنظام سيعيش ويتطور.

في هذه المقالة، سنحلل أكثر الملاحظات شيوعاً التي تتلقاها في المراجعات. لن نعلمك بناء الجملة - فأنت تعرف بالفعل كيفية تعريف متغير. سنتحدث عن ثقافة الكود، والهندسة المعمارية، والمزالق التي تحول الكود العامل إلى كابوس للصيانة. استعد: سيكون الأمر مؤلماً ولكنه مفيد.

1. الأرقام والسلاسل السحرية: "ماذا يعني 42؟"

الخطأ الأكثر شيوعاً والأكثر إزعاجاً. يرى المطور الكبير في الكود if ($status == 3) ويضع على الفور علامة ناقص. الرقم 3 هو ثابت سحري. بعد شهر، لن تتذكر أنت نفسك ما يعنيه. وسيظل المطور الجديد يتخمّن: هل هي حالة "منشور"، "مسودة"، أم "محذوف"؟

سيء:

if ($order->getStatus() == 3) {\n    $order->sendNotification();\n}

جيد:

class OrderStatus {\n    const PENDING = 1;\n    const CONFIRMED = 2;\n    const SHIPPED = 3;\n    const DELIVERED = 4;\n}\n\nif ($order->getStatus() === OrderStatus::SHIPPED) {\n    $order->sendNotification();\n}

استخدام الثوابت المسماة يجعل الكود موثقاً ذاتياً. أنت لا تكتب كوداً فحسب - بل تروي قصة. هذه واحدة من أهم php best practices التي يتجاهلها المبتدئون غالباً.

2. الكائنات العملاقة (God-Objects) والوحوش ذات الـ 500 سطر

"هذه الفئة تفعل كل شيء!" - عبارة ترعب المطور الكبير. عندما تكون فئة واحدة مسؤولة عن إرسال البريد الإلكتروني، وإنشاء PDF، والعمل مع قاعدة البيانات - فهذا انتهاك لمبدأ المسؤولية الفردية (SRP). لا يمكن اختبار هذه الفئة، ومن الصعب تعديلها، وهي مضمونة أن تتعطل عند أدنى إعادة هيكلة.

علامات الكائن العملاق:

\n
• تحتوي الفئة على أكثر من 200-300 سطر
\n
• تحتوي الدالة على أكثر من 20-30 سطراً
\n
• ينتهي اسم الفئة بـ "Manager" أو "Helper"
\n
• تستقبل الدوال 5 معاملات أو أكثر
\n

الحل بسيط: جزّئ! انقل المنطق إلى خدمات، ومستودعات، ومعالجات. إعادة هيكلة PHP تبدأ من الصغر - اصنع فئة تفعل شيئاً واحداً فقط، ولكنها تفعله جيداً.

3. العمل "الخام" مع SQL عبر PDO

نعم، PDO يحمي من حقن SQL إذا كنت تستخدم الاستعلامات المحضرة (prepared statements). لكن المطور الكبير يريد رؤية تجريد، وليس SQL خام في المتحكم (Controller). ORM مثل Eloquent أو Doctrine هو المعيار. إذا كان المشروع صغيراً، استخدم على الأقل Query Builder.

النمط المضاد:

$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');\n$stmt->execute([$email]);\n$user = $stmt->fetch();

النهج الصحيح:

class UserRepository {\n    public function findByEmail(string $email): ?User {\n        return User::where('email', $email)->first();\n    }\n}

العمل من خلال المستودع (Repository) يسمح بتغيير مصدر البيانات بسهولة (مثل الانتقال إلى ذاكرة التخزين المؤقت Redis) دون إعادة كتابة المشروع بأكمله. هذا هو جودة كود PHP الذي يُقدّر بوزن الذهب.

4. تجاهل strict_types

PHP هي لغة ذات كتابة ديناميكية، لكن هذا ليس عذراً لكتابة كود كما في عام 2005. إعلان declare(strict_types=1); في بداية كل ملف هو علامة على الاحترافية. يكره المطور الكبير عندما تتوقع دالة int، لكنها تستقبل سلسلة نصية "42" وتحولها بصمت.

declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// هذا سيسبب TypeError، وليس تحويلاً صامتاً\necho calculateTotal('100', 2); /