تحظى المشكلات الناشئة في عملية الإنتاج باهتمام الإدارة الوسطى والعليا تدريجيًا. سواء كنت مطورًا أو مهندسًا معماريًا، يجب عليك الاهتمام بالعناصر التالية لتجنب الوقوع في مواقف محرجة في المستقبل. يمكنك أيضًا استخدامه كملاحظة لاستكشاف الأخطاء وإصلاحها.
#1. لا تقم بإضفاء الطابع الخارجي على خصائص التكوين في ملفات الخصائص أو ملفات XML. على سبيل المثال، لم يتم تعيين عدد مؤشرات الترابط المستخدمة من خلال المعالجة المجمعة بحيث تكون قابلة للتكوين في ملف الخصائص. يمكن أن يعمل برنامج الدفعات الخاص بك بسلاسة سواء في بيئة DEV أو بيئة UAT (اختبار قبول المستخدم)، ولكن بمجرد نشره على PROD، عند استخدامه كبرنامج متعدد الخيوط لمعالجة مجموعات بيانات أكبر، سيتم طرح IOException إما بسبب اختلاف إصدارات برنامج تشغيل JDBC أو بسبب المشكلة التي تمت مناقشتها في رقم 2. إذا كان من الممكن تكوين عدد المواضيع في ملف الخصائص، يصبح من السهل جدًا جعله تطبيقًا ذو ترابط واحد. لم نعد بحاجة إلى نشر التطبيقات واختبارها بشكل متكرر لحل المشكلات. هذه الطريقة مناسبة أيضًا لتكوين عنوان URL والخادم ورقم المنفذ وما إلى ذلك.
#2. حجم مجموعة البيانات المستخدمة في الاختبار غير مناسب. على سبيل المثال، السيناريو النموذجي أثناء الإنتاج هو استخدام 1 إلى 3 حسابات فقط للاختبار، عندما يكون الرقم من 1000 إلى 2000. عند إجراء اختبار الأداء، يجب أن تكون البيانات المستخدمة حقيقية وغير مقصوصة. قد يؤدي اختبار الأداء غير القريب من البيئة الحقيقية إلى حدوث مشكلات غير متوقعة في الأداء والتوسع وتعدد مؤشرات الترابط. فقط من خلال اختبار التطبيق باستخدام مجموعة بيانات أكبر، يمكنك التأكد من أنه يعمل بشكل صحيح ويلبي اتفاقيات مستوى الخدمة (معايير مستوى الخدمة) للسمات غير الوظيفية.
#3. الاعتقاد بسذاجة أن الخدمات الخارجية والداخلية التي يتم استدعاؤها في التطبيق موثوقة ومتاحة دائمًا. سيؤثر عدم السماح بانتهاء مهلة استدعاء الخدمة وإعادة المحاولة سلبًا على استقرار التطبيق وأدائه. مطلوب اختبار انقطاع الخدمة المناسبة. وهذا أمر مهم لأن تطبيقات اليوم موزعة في الغالب وموجهة نحو الخدمة، وتتطلب عددًا كبيرًا من خدمات الشبكة. قد يؤدي طلب الخدمات غير المتوفرة إلى ما لا نهاية إلى الإضرار بتطبيقك. يجب أيضًا اختبار موازن التحميل للتأكد من أنه يعمل بشكل صحيح للحفاظ على توازن كل عقدة.
#4. لا يتم اتباع الحد الأدنى من متطلبات الأمان. كما ذكرنا أعلاه، فإن خدمات الشبكة موجودة في كل مكان، مما يجعل من السهل على المتسللين استغلالها لشن هجمات حجب الخدمة. لذلك، عند استخدام طبقة المقابس الآمنة، يجب عليك إكمال التحقق الأساسي وإجراء اختبار الاختراق باستخدام أدوات مثل Google Skipfish. لا يهدد التطبيق غير الآمن استقراره فحسب، بل يمكن أن يؤثر أيضًا سلبًا على سمعة الشركة بسبب مشكلات سلامة البيانات، مثل الموقف الذي يمكن فيه للعميل "أ" عرض بيانات العميل "ب".
#5.لا يوجد اختبار التوافق عبر المتصفحات. تطبيقات الويب اليوم هي في الغالب تطبيقات غنية بصفحة واحدة تستخدم لغة برمجة JavaScript وأطر العمل مثل angular js. لكي يعمل موقع الويب الذي تقوم بإنشائه بسلاسة عبر الأجهزة والمتصفحات المختلفة، يجب عليك تنفيذ تصميم مناسب. لذا، للتأكد من أن تطبيقك يعمل عبر جميع الأجهزة والمتصفحات، يجب اختبار توافقه.
#6. عدم إضفاء الطابع الخارجي على قواعد العمل التي قد تتغير بشكل متكرر. على سبيل المثال، قوانين الضرائب، والمتطلبات الحكومية أو المتعلقة بالصناعة، والتصنيفات، وما إلى ذلك. يمكنك استخدام محرك مثل Drools لمعالجة قواعد العمل، مما يساعدك على إضفاء الطابع الخارجي على قواعد العمل هذه عن طريق تخزينها في قاعدة بيانات أو ملف Excel. بمجرد أن تتقن الشركات قواعد العمل هذه، يمكنها الاستجابة بسرعة لقوانين الضرائب أو المتطلبات ذات الصلة بأقل قدر من التغييرات والاختبارات.
#7الوثائق التالية غير متوفرة
بالإضافة إلى COS (شروط الرضا)، وهو نموذج تم إنشاؤه بواسطة MindMap، هناك نموذجان رئيسيان للمستندات في التطوير السريع ، 1 و2.
#8. عدم وجود خطة مناسبة للتعافي من الكوارث واستراتيجية مراقبة وأرشفة النظام. مع اقتراب المواعيد النهائية للمشروع، غالبًا ما يتم تفويت هذه الأشياء أثناء الاندفاع لنشر المشروع. عدم وجود مراقبة مناسبة للنظام مع Nagios وSplunk لا يهدد استقرار التطبيق الخاص بك فحسب، بل يعيق أيضًا التشخيص الحالي وجهود التحسين المستقبلية.
#9. لا يوجد تصميم عمود مناسب لجدول قاعدة البيانات ، مثل create_datetm، وupdate_datetm، وcreated_by، وupdate_by، وtimestamp. كما أنه لا يوفر أعمدة سجل حذف منظمة، مثل العمود "المحذوف" الذي يمكن أن يأخذ "Y" أو. "N" أو يمكنك أخذ عمود "record_status" من "نشط" أو "غير نشط".
#10.الفشل في وضع خطة تصحيح مناسبة. ونتيجة لذلك، عند فشل النظام، لا توجد طريقة لاستعادة النظام إلى الحالة المستقرة قبل النشر. ويجب دراسة هذه الخطة بعناية وتوقيعها من قبل الفريق المعني. تتضمن الخطط العودة إلى الإصدار السابق من البرنامج، وإزالة جميع البيانات المدرجة في قاعدة البيانات وجميع الإدخالات في ملف الخصائص.
#11. الفشل في تطوير خطة القدرات قبل بدء المشروع. اليوم، عند وصف متطلبات النظام الأساسي، لا يكفي أن نقول ببساطة "يتطلب كمبيوتر Unix، وخادم قاعدة بيانات Oracle، وخادم تطبيقات JBoss." يجب أن يكون طلبك دقيقًا
#12 أدناه يأتي من تعليق "David DeCesare" من "java.dzone"،
#12. "لا تستخدم أفضل أداة لهذا المنصب." في كثير من الحالات، سيستخدم المطورون لغة أو أداة يريدون تعلمها في نظام الإنتاج. عادة لا يكون هذا هو الخيار الأفضل. على سبيل المثال، استخدام قواعد بيانات NoSQL للبيانات العلائقية بالفعل. تذكر، بغض النظر عن الأداة التي تستخدمها، ستحتاج إلى صيانة منتجك لمدة 3 إلى 5 سنوات القادمة (أو حتى لفترة أطول).
#13. عدم وجود احتياطيات كافية من المعرفة في 16 مجالًا تقنيًا رئيسيًا. تتضمن هذه المجالات تحديد وإصلاح 1) "مشكلات التزامن"، 2) مشكلات المعاملات، و3) مشكلات الأداء. في العديد من المقابلات، اعتمدت على هذه الجوانب الثلاثة من المعرفة للحصول على عقود جديدة.