7 تقنيات التصحيح لتسريع استكشاف الأخطاء وإصلاحها في الإنتاج

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

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

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

النصيحة رقم 1: قم بإزالة أو أتمتة جميع التكوينات اللازمة لتشغيل التطبيق.

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

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

وبالمثل ، قم بتبسيط إعداد المطور ، بحيث لا يستغرق الكثير من الوقت للتشغيل ، بما في ذلك إعداد IDE. يجب أن يكون المطور قادرًا على الانتقال من الصفر إلى البطل في أقل من 30 دقيقة.

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

نصيحة رقم 2: لا تسقط في فخ حساء المكدس التكنولوجي.

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

• لا تقم بإضافة تبعية إطار عمل جديدة لمجرد أنك بحاجة إلى فئة StringUtils .
• لا تقم بإضافة لغة جديدة تمامًا لمجرد أنك تحتاج إلى كتابة نص سريع لنقل الملفات.

كومة التبعية الكبيرة يمكن أن تجعل حياتك بائسة عندما تصبح المكتبات غير متوافقة أو عندما يتم العثور على تهديدات أمنية إما الأطر نفسها أو على تبعياتها متعدية.

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

نصيحة رقم 3: يجب أن يرشدك التسجيل للعثور على المشكلة ، وليس إغراقك بتفاصيل غير مفيدة.

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

نصيحة رقم 4: تعامل مع المواقف غير المتوقعة.

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

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

نصيحة رقم 5: يجب أن يكون من السهل تكرار مشكلة تحدث للعميل.

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

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

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

نصيحة رقم 6: يجب أن يكون واضحًا مكان وضع نقاط التوقف في التطبيق.

إذا كانت لديك شاشة عميل ، فيجب أن يكون هناك بعض كائن العميل حيث يمكنك وضع نقاط التوقف لتصحيح مشكلة على تلك الشاشة. يقع المطورون أحيانًا في حمى التجريد ويخرجون ببعض المفاهيم الذكية بشكل لا يصدق حول كيفية التعامل مع أحداث واجهة المستخدم. بدلاً من ذلك ، يجب أن نعتمد دائمًا على مبدأ KISS (Keep it Simple، St - er، Silly) وأن يكون لدينا طريقة واحدة يمكن تحديد موقعها بسهولة لكل حدث واجهة مستخدم. وبالمثل ، بالنسبة لوظائف معالجة الدُفعات والمهام المجدولة - يجب أن تكون هناك طريقة سهلة لتحديد مكان نقاط توقف المكان لتقييم ما إذا كان هذا الرمز يعمل أم لا.

نصيحة رقم 7: تأكد من توثيق جميع التبعيات الخارجية بشكل صريح.

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

ما وراء تقنيات التصحيح

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