تصحيح الأخطاء: إيجادها بنفسك

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

اقرأ رسالة الخطأ كأنها دليل وليست ضوضاء

يتم تجاوز Stack traces باستمرار لأنها تبدو مخيفة. لكنها عادة ما تخبرك بالضبط أين وملاذا انهار شيء ما. إذا حصلت على TypeError: 'NoneType' object is not subscriptable في Python، هذا ليس هراء عشوائي — هذا يعني أن متغيراً كنت تتوقع أن يحتوي على قائمة أو قاموس هو في الواقع None. رقم السطر يخبرك أين. مهمتك أن تتتبع للخلف من هذا السطر وتجد أين كان يجب ضبط القيمة لكنها لم تُضبط.

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

أعد إنتاجه بقصد

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

قسّم المشكلة إلى نصين، ثم نصين مرة أخرى

البحث الثنائي ليس فقط للمصفوفات المرتبة — إنه الطريقة الأسرع لإيجاد الكود المعطوب في دالة طويلة أو خط أنابيب. اعلق على أو تجاوز النصف الثاني من منطقك وتحقق مما إذا كان النصف الأول لا يزال ينتج الخطأ. إذا كان الجواب نعم، المشكلة في النصف الأول. إذا كان لا، فهي في النصف الثاني. كرر. هذا يعمل مع سكريبت بـ 200 سطر تماماً كما يعمل مع خط أنابيب بيانات متعدد المراحل حيث تتحقق من المخرجات في كل مرحلة باستخدام print() أو df.head().

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

استخدم المصحح بدلاً من print() عندما يتوقف print() عن العمل

تعليقات print() جيدة للحالات البسيطة، لكن بمجرد أن تكون تتعقب الحالة عبر استدعاءات دوال متعددة، مصحح فعلي يوفر وقتاً حقيقياً. في Python، ضع import pdb; pdb.set_trace() قبل السطر المريب مباشرة، شغّل السكريبت، وستحصل على موجه مباشر حيث يمكنك فحص المتغيرات والتنقل سطراً تلو الآخر باستخدام n، والدخول إلى استدعاءات الدوال باستخدام s. المصحح المدمج في VS Code يفعل نفس الشيء مع نقاط توقف تنقر عليها بدلاً من الكتابة. على أي حال، الهدف واحد: راقب الحالة الفعلية لبرنامجك بدلاً من التخمين بشأن ما هي على الأرجح.

افصله عن بقية مشروعك

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

تحقق من افتراضاتك مقابل الواقع وليس الذاكرة

حصة ضخمة من وقت تصحيح الأخطاء تذهب للافتراضات غير المطروحة: