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

مقدمة: لماذا مراجعة الكود ليست عن السيطرة، بل عن النمو

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

في هذه المقالة، سنناقش بالتفصيل ما يجب التركيز عليه تحديدًا عند مراجعة كود PHP، وكيفية صياغة الملاحظات دون الإساءة إلى الزميل، وكيفية استخلاص أقصى فائدة من هذه العملية. تستند المادة إلى خبرة عملية حقيقية مع مشاريع على PHP 7.4+ وأطر عمل مثل Laravel و Symfony.

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

لا توجد قائمة شاملة، ولكن لمشاريع PHP يمكن تحديد 5 مجالات رئيسية يجب تمريرها بالتأكيد من خلال منظور المراجعة.

1.1. الأمان (Security)

PHP هي لغة يسهل فيها ارتكاب ثغرات أمنية. أول ما نتحقق منه:

\n
• حقن SQL: هل تُستخدم الاستعلامات المُعدّة (PDO / prepared statements) بدلاً من دمج السلاسل النصية؟
\n
• XSS (البرمجة النصية عبر المواقع): هل يتم ترميز المخرجات باستخدام htmlspecialchars() أو محركات القوالب (Blade, Twig)؟
\n
• حماية CSRF: هل توجد رموز مميزة (tokens) في النماذج التي تغير الحالة؟
\n
• التحقق من صحة الإدخال: هل يتم التحقق من نوع وطول البيانات على جانب الخادم؟
\n

// سيء: دمج السلاسل في SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// جيد: استعلام PDO مُعد\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. البنية المعمارية و SOLID

حتى لو لم يكن المشروع مؤسسيًا، يجب الالتزام بالمبادئ الأساسية:

\n
• المسؤولية الواحدة: هل يقوم الصف/الدالة بعمل أكثر من اللازم؟
\n
• عكس التبعيات: هل يستخدم الكود واجهات (interfaces) بدلاً من الصفوف الملموسة؟
\n
• غياب الكائنات العملاقة: هل توجد صفوف تحتوي على أكثر من 1000 سطر؟
\n

1.3. الأسلوب ومعايير PSR

بالنسبة لـ PHP، هذا أمر بالغ الأهمية. نتحقق من الامتثال لـ PSR-12 (أسلوب الترميز):

\n
• المسافات البادئة — 4 مسافات، وليس علامات جدولة.
\n
• الأقواس المتعرجة في سطر جديد للصفوف والدوال.
\n
• التسمية الصحيحة: camelCase للدوال، snake_case للمتغيرات (إذا لم يكن هناك اتفاق مختلف في المشروع).
\n

1.4. الأداء

من السهل كتابة كود بطيء في PHP. نبحث عن:

\n
• الاستعلامات داخل الحلقات (مشكلة N+1) — بدلاً من ذلك، استخدم التحميل المتعطش (Eager Loading) في ORM.
\n
• تجاهل التخزين المؤقت: إعادة حسابات متكررة لنفس البيانات.
\n
• الدوال غير الفعالة: على سبيل المثال، من الأفضل استبدال in_array() على مصفوفة كبيرة بـ isset($hash[$key]).
\n

// سيء: استعلام داخل الحلقة\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// جيد: استعلام واحد مع التحميل المتعطش\n$users = User::with('posts')->get();\n

1.5. معالجة الأخطاء وتحديد الأنواع

\n
• هل يوجد strict_types في بداية الملف؟
\n
• هل تُستخدم الأنواع للوسائط وقيم الإرجاع؟
\n
• هل تتم معالجة الاستثناءات، وليس إسكاتها باستخدام try-catch فارغ؟
\n

2. كيفية تقديم الملاحظات: من "هذا سيء" إلى "دعنا نحسّن"

أصعب مهارة في مراجعة الكود ليست العثور على خطأ، بل تقديمه بشكل صحيح. الملاحظات السيئة تقتل الدافع. الملاحظات الجيدة تعلم وتقرّب الفريق.

2.1. قاعدة "الساندويتش"

الحشوة