الحفاظ على مشروع في PHP: 5 أخطاء يجب تجنبها

PHPكغيرها من اللغات، لها بعض العيوب التي لا تساوي شيئًا عندما يتعلق الأمر بإدارة تكنولوجيا المعلومات المشروع حيث PHP هي اللغة الرائدة.

وقد قمنا أدناه بتنسيق قائمة بها، إلى جانب نصائح حول كيفية تجنبها.

1. عدم اتباع توصيات معايير PHP

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

المستمع - المستمع هو أي PHP قابل للاستدعاء الذي يتوقع تمرير حدث. قد يتم تمرير حدث واحد أو أكثر من المستمعين إلى نفس الحدث. يمكن أن يقوم المستمع باستدعاء بعض السلوكيات غير المتزامنة الأخرى إذا اختار ذلك.

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

كيف يمكنني تجنب ذلك؟

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

2. عدم تأمين إصدارات تبعيات composer.json الخاصة بك

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

كيف يمكنني تجنب ذلك؟

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

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

3. ضعف جمع المتطلبات

> إنه مجرد CRUD، لماذا العناء؟

> هناك مكتبة تقوم بذلك بالضبط!

في PHP المجال، من السهل الوقوع في دوامة النسيان عند تنفيذ منطق أعمال المنتج. على مر السنين كانت هناك المئات من المشاريع التي [تنشئ لوحات إدارية لإدارة نماذج البيانات] (https://backpackforlaravel.com/)، أو [إنشاء طرق عرض شبيهة بتحليلات جوجل] (https://github.com/Kunstmaan/KunstmaanDashboardBundle) أو [حل مشاكل المزامنة في PHP] (https://laravel.com/docs/9.x/octane) بلمسة عصا سحرية (حسناً، باستعلام سطر أوامر واحد).
عالم PHP مليء بالتطبيقات الجاهزة التي تعمل 99.9% من الوقت.
هذا 0.1% هو المكان الذي يصطدم فيه منطق العمل بالقيود الوظيفية للمكتبات المستخدمة.
إن ما يسمى بـ "الرمي" هو الأكثر صعوبة في التنفيذ في نهاية المشروع.

كيف يمكنني تجنب ذلك؟

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

4. خفض التكاليف عن طريق تجنب كتابة الاختبارات

PHP ليست مثالية، هذا أمر مؤكد. لا تزال عيوبها من حيث الكتابة الثابتة، ونقص دعم الأجناس العامة، والدعم المستمر للطرق القديمة مصدرًا للسخرية بين المبرمجين. ومع ذلك، لبعض الوقت مطورو PHP المزيد والمزيد من الأدوات القوية مثل PHPSTAN, Xdebug, PHP-CS-Fixer التي تسمح لهم بالحفاظ على الاتساق والكتابة الثابتة - وبالتالي تجنب العديد من الأخطاء. ومع ذلك، لا يتم إيلاء اهتمام كبير للاختبارات، والتي، عند تنفيذها بشكل صحيح، تؤدي إلى عائد سريع على الاستثمار في شكل
- تقليل أخطاء الانحدار
- زيادة الوعي بقدرات المنتج
- زيادة إحساس المطور بملكية الكود البرمجي

كيف يمكنني تجنب ذلك؟

لا تقلل من تكاليف الاختبار. إن كتابة البرامج النصية البسيطة لـ Behat ليست بهذه الصعوبة، فلست مضطرًا لكتابة اختبارات معقدة من النهاية إلى النهاية على الفور أو الدخول في تفاصيل التنفيذ واختبار كل طريقة.
غالباً ما يساوي اختبار "بيهات" البسيط الموصوف بلغة المجال الطبيعي أكثر من أكثر الاختبارات المكتوبة بدقة متناهية.

5. عدم مراعاة أنماط العمارة الحديثة

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

كيف يمكنني تجنب ذلك؟

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