لدى الجميع ردّ الفعل الأول نفسه تجاه الـ stack trace: تتجمّد العينان، ويهبط القلب، وتريد إغلاق النافذة. عشرون سطرًا أحمر، نصفها عن ملفات لم ترها قط، وكلها تنتهي برسالة غامضة مثل TypeError: Cannot read properties of undefined (reading 'map').
الـ stack trace هو ببساطة طريقة الحاسوب في القول «حاولتُ، وهذا بالضبط أين عَلِقتُ». وClaude يقرأ ذلك بطلاقة. أنت لستَ مضطرًّا.
هذا الدرس عن تحويل «يا للهول» إلى «آه، هذا كل ما في الأمر».
ما هو الـ stack trace فعليًا
قبل أن نُسلّمه إلى Claude، تبسيط صغير. الـ stack trace هو قائمة استدعاءات الـ functions التي كانت جارية حين حدث الخطأ — تُقرأ من الأعلى إلى الأسفل، مع أحدث استدعاء في الأعلى.
يبدو مرهبًا لأنه مطبوع لآلة، لا لإنسان: paths كاملة للملفات، وأرقام أسطر، وأسماء functions، وأحيانًا عدد مرات الاستدعاء. لكن لا يوجد فيه حقًا سوى ثلاثة أشياء:
- رسالة الخطأ — ما الذي أخطأ، في سطر واحد.
- الملف والسطر — أين أخطأ.
- سلسلة الاستدعاءات المؤدّية إليه — كيف وصل البرنامج إلى هناك.
يستطيع Claude استخراج الثلاثة جميعًا من أي trace، بأي لغة، فورًا.
الخطوة
تصطدم بخطأ. تبقى هادئًا. تنسخ الـ trace كاملًا — كله، بما في ذلك الأسطر الفارغة والأجزاء التي لا تفهمها — وتلصقه مباشرةً في المحادثة مع Claude. الصياغة بالكاد تهمّ:
I'm getting this error. What does it mean and where do I look?
[paste the full trace here]هذا كل شيء. سيقوم Claude بما يلي:
- يترجم رسالة الخطأ إلى لغة بسيطة.
- يشير إلى الملف والسطر حيث أخطأ فعليًا.
- غالبًا، ينظر إلى ذلك الملف مباشرةً ويخبرك بالسبب المرجَّح.
- يقترح إصلاحًا — أو على الأقل الشيء التالي الذي ينبغي فحصه.
«النصّ المخيف» صار الآن فقرة.
لا تقتطعه
أكبر خطأ يرتكبه المبتدئون هو لصق السطر الأخير فقط. أسفل الـ trace هو حيث انطلق الخطأ، لكن أعلى الـ trace هو حيث جاء منه الخطأ. اقتطعه، وتكون قد رميتَ الجزء الذي يحتاجه Claude أكثر من غيره.
الصق الأمر كله. لا تتدخّل بتحريرٍ منك. لا تنتقِ السطر الذي تظن أنه المهمّ.
إن مرّ الخرج بالتمرير ولم ترَ سوى جزء منه، فمرّر إلى الأعلى والتقط الكتلة كاملةً — عادةً أول سطر فارغ في الأعلى هو بدايتك، وآخر سطر أحمر هو نهايتك.
أخطاء بلا stack traces
ليس كل خطأ يأتي مع stack trace مهذّب. أحيانًا تحصل على:
- سطر قصير غامض في سجلّ عمل Claude: «command not found» أو «port 3000 already in use».
- test فاشل مع diff بين المتوقَّع والفعلي.
- خطّ أحمر متعرّج في محرّرك مع تلميح.
- صندوق أحمر على صفحة وِب حين جرّبتَ شيئًا.
عامِل كل هذه بالطريقة نفسها: انسخ النصّ والسياق — ما كنتَ تفعله حين حدث — واسأل Claude. السياق هو المُضاعِف.
I asked you to start this project and got this. What's wrong?
[paste the output]قارن ذلك بـ*«إنه لا يعمل»* وسترى لماذا يهمّ السياق. (كل من سبق أن حاول مساعدة صديق في حاسوبه عبر الرسائل النصّية يعرف الفرق.)
النقطة التي تربك الناس
حين يشير الخطأ إلى عمق كود شخص آخر — أعماق Node، أو library لم تفتحها قط — يُصاب المبتدئون بالذعر. «لا أعرف ذلك الكود، كيف لي أن أصلحه؟»
لستَ مضطرًّا. في كل الأحوال تقريبًا، الخطأ الذي ينطلق هناك يكون سببه الحقيقي هو كودك أنت وهو يستخدمه استخدامًا خاطئًا. لنقل إنك أخطأت في كتابة import في server/index.js — require('./emial') بدلًا من require('./email') — فينفجر تشغيل المشروع بجدار ينتهي بـ Error: Cannot find module './emial'، مرميًّا من مكان ما داخل محمّل الوحدات في Node. تلصق ذلك الجدار في المحادثة، فيقرؤه Claude ويخبرك:
«هذا الخطأ يُرمى بواسطة نظام
requireفي Node، لكنه ناتج عنserver/index.js:4— كتبتَrequire('./emial')ولا يوجد ملف بهذا الاسم. كنتَ تقصد
تلك هي الإجابة التي احتجتَها. الإصلاح سطر واحد في ملفك أنت، لا في أي مكان في Node. (يُسمح لك أن تشعر بالارتياح.)
لماذا يوجد هذا الدرس
يكاد كل من يتوقف عن تعلّم البرمجة يتوقف أثناء خطأ. يبدو الجدار الأحمر كأنه فشل شخصي. ليس كذلك — إنه مجرد آلة تتصرّف بحرفية.
الأخطاء ليست عقوبات. إنها أدقّ تغذية راجعة ستحصل عليها من حاسوب على الإطلاق. وClaude يحوّل تلك الدقّة إلى شيء يستطيع الإنسان استخدامه.
بعد هذا الدرس، ينبغي أن يبدو الخطأ أقلّ شبهًا بجدار وأكثر شبهًا بباب. باب مخيف المظهر، أحيانًا. لكنه باب.
ما التالي
أحيانًا لا يكون الخطأ في ما هو موجود الآن — بل في ما تغيّر. «كان هذا يعمل أمس. ماذا فعلتُ؟» هذا سؤال عن git history، وClaude بارع فيه إلى حدّ مذهل أيضًا. الدرس التالي.