مراجعة الكود في PHP: ما يجب التحقق منه وكيفية تقديم الملاحظات

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

مقدمة: لماذا مراجعة الكود ليست مجرد "اكتشاف الأخطاء"

Code review (مراجعة الكود) هي واحدة من أكثر الأدوات فعالية لتحسين جودة المنتج البرمجي. في مجتمع PHP، حيث توجد غالبًا تركة من "كود السباغيتي" ومزيج من الأساليب الإجرائية (procedural) والموجهة للكائنات (OOP)، تصبح المراجعة الجيدة مهمة بشكل خاص. ومع ذلك، ينظر إليها العديد من المطورين على أنها "صيد للأخطاء" أو، الأسوأ من ذلك، كوسيلة لتأكيد الذات. في الواقع، هدف code review هو نقل المعرفة، وضمان اتساق قاعدة الكود، ومنع المشكلات المحتملة قبل وصولها إلى مرحلة الإنتاج (production).

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

1. ما الذي يجب فحصه في كود PHP: قائمة مراجعة للمُراجع

لكي تكون المراجعة منهجية وليست عشوائية، استخدم قائمة المراجعة التالية. وهي مقسمة إلى فئات رئيسية.

1.1. الأمان (Security)

PHP هي لغة تكون فيها أخطاء الأمان مكلفة. تحقق من:

حقن SQL (SQL Injection): هل يتم استخدام الاستعلامات المُعدة (prepared statements) (PDO أو MySQLi)؟ يُمنع دمج السلاسل النصية في الاستعلامات.
XSS (Cross-Site Scripting): كل مخرجات المستخدم يتم تنقيتها باستخدام htmlspecialchars() أو محركات القوالب (مثل Twig, Blade).
حماية CSRF: هل توجد رموز مميزة (tokens) في النماذج؟
التحقق من صحة البيانات على الخادم: لا تعتمد فقط على التحقق من صحة البيانات من جانب العميل.

<?php// سيء: حقن SQL$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// جيد: PDO مع prepared statement$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. الامتثال لمعايير PSR

قامت PHP-FIG (Framework Interop Group) بتطوير معايير تتبعها معظم المشاريع الحديثة. تحقق من:

PSR-12: المسافات البادئة (4 مسافات)، الأقواس المتعرجة، التسمية (camelCase للدوال، snake_case للمتغيرات).
PSR-4: التحميل التلقائي للفئات (autoloading) والمساحات الاسمية (namespaces).

استخدم الأدوات التلقائية (PHP CodeSniffer, PHP-CS-Fixer) لتوفير الوقت في التنسيق اليدوي.

1.3. البنية المعمارية ومبادئ SOLID

حتى في المشاريع الصغيرة، تساعد مبادئ SOLID في تجنب "كتلة الطين الكبيرة". انتبه إلى:

مبدأ المسؤولية الواحدة (Single Responsibility): دالة/فئة واحدة تقوم بمهمة واحدة. إذا كانت الدالة تفعل 3 أشياء، فهذا سبب لإعادة الهيكلة (refactoring).
حقن التبعيات (Dependency Injection): لا تستخدم new داخل الفئات، بل قم بتمرير التبعيات عبر المُنشئ (constructor).
غياب "الكائنات الإلهية": لا ينبغي للفئة أن تعرف كل شيء عن النظام.