تصحيح أخطاء Python في Visual Studio Code خطوة بخطوة

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

الفكرة الأساسية

نقطة التوقف توقف التنفيذ قبل السطر المحدد، وتسمح بمشاهدة call stack والقيم المحلية. Step over ينفذ السطر الحالي من دون الدخول إلى الدالة، وstep into يدخلها، وstep out يخرج منها. نافذة watch مفيدة لمراقبة تعبير محدد، بينما debug console يسمح بفحص قيمة أو استدعاء بسيط. لا ينبغي ترك نقاط توقف حساسة في جلسة المستخدم النهائية، لكنها لا تغير الكود عند وضعها داخل المحرر.

مثال برمجي عملي

def average(scores):
    total = 0
    for score in scores:
        total += score
    return total / len(scores)


def passed_students(students):
    result = []
    for student in students:
        mean = average(student["scores"])
        if mean >= 60:
            result.append(student["name"])
    return result

classroom = [
    {"name": "ليان", "scores": [80, 70, 90]},
    {"name": "سليم", "scores": [55, 58, 61]}
]

print(passed_students(classroom))

شرح المثال

ضع نقطة توقف على السطر الذي يحسب mean، ثم شغل الملف من وضع Run and Debug. راقب student وstudent["scores"] وmean، وتأكد أن العتبة تطبق على المتوسط لا على آخر درجة. إذا ظهرت نتيجة غير متوقعة، تحرك داخل average وتحقق من total وlen. الكود يفترض أن كل طالب يملك قائمة غير فارغة، لذلك سيظهر خطأ عند وجود قائمة فارغة. هذه الملاحظة تقود إلى قاعدة تحقق ينبغي إضافتها، لا إلى إخفاء الاستثناء.

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

طريقة العمل قبل كتابة الكود

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

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

اختبار المثال في حالات مختلفة

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

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

ملاحظات تتعلق بجودة الكود

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

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

متى تعرف أن الحل يحتاج إلى تطوير؟

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

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

أخطاء ينبغي تجنبها

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

خطوة تالية مناسبة

تعلم conditional breakpoints عندما تريد التوقف لطالب معين، واستخدم logpoints في الحلقات الطويلة. بعد إصلاح الخطأ، نظف نقاط التوقف واكتب اختباراً للحالة. الهدف من المصحح أن يقلل زمن التفكير، لا أن يحل محل فهم الخوارزمية أو قراءة رسالة الاستثناء.

استخدم سجل التصحيح بذكاء

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

اكتب فرضية قبل التصحيح

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

الخلاصة

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

تعديل المقال

إيفلون

تصحيح أخطاء Python في Visual Studio Code خطوة بخطوة