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

الخلاصة

  • إعادة الكتابة الكاملة هي الخيار الأكثر إغراءً والأكثر خطورة؛ أما التحديث التدريجي فهو أكثر أمانًا ويحقق قيمة أبكر
  • ابدأ بتقييم الكود، والترقية إلى إصدار PHP مدعوم، وبناء شبكة أمان من الاختبارات حول السلوك الحرج
  • أدخِل Composer، والتحميل التلقائي، والبنية الحديثة، ثم أعد الهيكلة نحو فصل واضح للمسؤوليات
  • تبنَّ إطار عمل مثل Symfony تدريجيًا باستخدام نمط strangler fig، مستبدلًا النظام القديم قطعة قطعة

لماذا لا نعيد كتابته ببساطة؟

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

الخطوة 1: قيّم قبل أن تلمس أي شيء

  • اجرد إصدار PHP والاعتماديات وحالة دعمها.
  • حدّد المسارات الحرجة (الميزات التي لا يمكن للعمل خسارتها) وأكثر المناطق خطورة والأكثر تغيرًا.
  • ارسم المشكلات الواضحة: SQL متناثر عبر القوالب، وغياب فصل المسؤوليات، والحالة العامة، والكود الميت.
  • افهم قاعدة البيانات ومدى ارتباط الكود بها بإحكام.

لا يمكنك أن تحدّث بأمان ما لا تفهمه.

الخطوة 2: انتقل إلى إصدار PHP مدعوم

تشغيل إصدار PHP انتهى عمره الافتراضي هو مخاطرة أمنية وأدائية، ويعيق الأدوات الحديثة.

  • رقِّ تدريجيًا عبر الإصدارات بدلًا من القفز فوق عدة إصدارات دفعة واحدة.
  • أصلِح التحذيرات من الإهمال والتغييرات الكاسرة في كل خطوة.
  • إن PHP الحديثة أسرع وأكثر أمانًا بشكل هائل من الإصدارات القديمة، لذا تسدد هذه الخطوة كلفتها غالبًا بالأداء وحده.

الخطوة 3: ابنِ شبكة أمان من الاختبارات

أثمن استثمار في أي مشروع قديم هو الاختبارات حول السلوك القائم.

  • أضِف characterisation tests تلتقط ما يفعله النظام حاليًا، خصوصًا على المسارات الحرجة، قبل أن تغيّر أي شيء.
  • حتى الاختبارات الخشنة رفيعة المستوى تمنحك الثقة لإعادة الهيكلة دون كسر الأشياء بصمت.
  • مجموعة الاختبارات هذه هي ما يجعل كل خطوة لاحقة آمنة.

الخطوة 4: أدخِل أسسًا حديثة

  • تبنَّ Composer لإدارة الاعتماديات وPSR-4 autoloading لاستبدال أوامر include اليدوية.
  • أدخِل namespaces وبنية مجلدات معقولة.
  • أضِف static analysis وأدوات معايير الترميز لإيقاف تراكم دَين جديد.

الخطوة 5: أعد الهيكلة نحو فصل واضح

  • افصل منطق العمل عن العرض والوصول إلى البيانات؛ وأخرِج SQL من القوالب.
  • استخرج خدمات قابلة لإعادة الاستخدام وأدخِل dependency injection حيث يقلل الاقتران.
  • أعد الهيكلة في خطوات صغيرة مختبَرة، لا في عمليات إعادة كتابة شاملة لمناطق كاملة دفعة واحدة.

الخطوة 6: تبنَّ إطار عمل تدريجيًا (Strangler Fig)

بدلًا من إعادة الكتابة بالكامل داخل إطار عمل، دع النظام الجديد ينمو حول القديم.

  • أقِم إطار عمل حديثًا مثل Symfony بجانب التطبيق القديم.
  • وجِّه الميزات الجديدة وتلك المُرحَّلة تدريجيًا عبر إطار العمل، بينما يستمر الكود القديم في خدمة الباقي.
  • استبدل الوظائف القديمة قطعة قطعة حتى يصبح الكود القديم «مخنوقًا» ويمكن إحالته للتقاعد.

يبقي هذا العمل مستمرًا طوال الوقت ويتجنب مخاطرة الكل أو لا شيء لإعادة الكتابة. (لمقارنة خيارات أطر العمل، راجع Symfony مقابل Laravel في 2026 .)

إدارة الدَّين التقني

التحديث في جوهره هو سداد الدَّين التقني عن قصد. أعطِ الأولوية للدَّين الذي يكلفك فعليًا (الكود الذي تغيّره كثيرًا، والأجزاء التي تتعطل، والمخاطر الأمنية) بدلًا من محاولة إصلاح كل شيء. لمعالجة أوفى، راجع دليل الدَّين التقني لفرق الهندسة .

أبرز النقاط

  • ينبغي أن يتجنب تحديث PHP القديمة إعادة الكتابة الشاملة دفعة واحدة؛ حدّث تدريجيًا لتقليل المخاطر وتحقيق قيمة أبكر.
  • قيّم أولًا، ثم رقِّ إلى إصدار PHP مدعوم وأضِف اختبارات حول السلوك القائم.
  • أدخِل Composer، والتحميل التلقائي، والفصل الواضح للمسؤوليات خطوة بخطوة.
  • تبنَّ إطار عمل مثل Symfony باستخدام نمط strangler fig، محيلًا الكود القديم للتقاعد قطعة قطعة.

تحديث PHP القديمة مع خبراء

تحديث الأنظمة القديمة يتعلق بإدارة المخاطر بقدر تعلقه بالبرمجة. من أجل توظيف مطور Symfony لهذه المهمة، ترتقي Mecanik بقواعد أكواد PHP القديمة إلى معايير حديثة وقابلة للصيانة ومختبَرة جيدًا باستخدام معمارية نظيفة ونهج تدريجي، مع CI/CD لتصمد الجودة عبر الزمن.

الأسئلة الشائعة (FAQ)

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

ما الخطوة الأولى لتحديث PHP القديمة؟ قيّم الكود والاعتماديات وإصدار PHP، ثم رقِّ إلى إصدار PHP مدعوم وأضِف اختبارات حول السلوك القائم الحرج. شبكة الأمان هذه من الاختبارات هي ما يجعل كل خطوة إعادة هيكلة لاحقة آمنة.

كيف أنقل PHP القديمة إلى إطار عمل دون إعادة كتابة؟ استخدم نمط strangler fig: أقِم إطار عمل حديثًا مثل Symfony بجانب التطبيق القديم، ووجِّه الميزات الجديدة والمُرحَّلة عبره، واستبدل الوظائف القديمة قطعة قطعة حتى يمكن إحالة الكود القديم للتقاعد. يبقى العمل مستمرًا طوال الوقت.

لماذا تُعد ترقية إصدار PHP مهمة؟ تشغيل إصدار PHP انتهى عمره الافتراضي هو مخاطرة أمنية وأدائية ويعيق الأدوات الحديثة. إن PHP الأحدث أسرع وأكثر أمانًا بشكل ملحوظ، لذا تحسّن الترقية الأداء فورًا في الغالب وتفتح المكتبات والأدوات التي يعتمد عليها التحديث.

كيف أتعامل مع تطبيق قديم لا يملك اختبارات؟ أضِف characterisation tests تلتقط السلوك الحالي للنظام على المسارات الحرجة قبل أن تغيّر أي شيء. حتى الاختبارات رفيعة المستوى تمنحك ثقة كافية لإعادة الهيكلة بأمان. إن بناء هذه التغطية أولًا هو الخطوة الأعلى قيمة في أي مشروع قديم.