تصحيح أخطاء البرمجة للمبتدئ: أعد إنتاج المشكلة قبل تغيير الكود

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

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

اكتب الفرق بين المطلوب والموجود

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

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

ثبّت ظروف ظهور المشكلة

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

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

صغّر المثال مع بقاء الخطأ

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

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

افحص القيمة قبل موضع اختلاف النتيجة

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

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

غيّر شيئًا واحدًا تستطيع تفسيره

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

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

اختبر حدود الإصلاح ثم أغلق المحاولة

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

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

عن الكاتب

فريق جادالحق

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

تنبيه: المحتوى المالي في الموقع للتثقيف العام فقط، وليس نصيحة استثمارية أو مالية شخصية؛ استشر مختصًا مرخّصًا قبل أي قرار يخص أموالك.