وقتی مدل اشتباه می‌کند؛ حلقهٔ خطا و اصلاح

هیچ مدلی، هرقدر هم قوی، همیشه از اولین بار کد درست تولید نمی‌کند. این طبیعی است و بخشی جدایی‌ناپذیر از وایب کدینگ است. تفاوت بین کسی که با مدل به نتیجه می‌رسد و کسی که خسته و ناامید رها می‌کند، در نحوهٔ برخورد با خطاست. یک حلقهٔ ساده و تکرارشونده وجود دارد که اگر آن را بلد باشید، اغلب خطاها در دو یا سه رفت‌وبرگشت حل می‌شوند: خطا، توضیح، اصلاح. مشکل از جایی شروع می‌شود که این حلقه را نمی‌شناسیم و به‌جای دنبال‌کردن آن، فقط دوباره و دوباره همان درخواست را تکرار می‌کنیم و انتظار نتیجهٔ متفاوت داریم.

حلقهٔ خطا، توضیح، اصلاح

این حلقه سه مرحله دارد و هر مرحله یک هدف مشخص دارد:

1. خطا: کد را اجرا می‌کنید و پیام خطا یا رفتار نادرست را می‌بینید.
2. توضیح: پیام خطا را کامل، بدون خلاصه‌کردن، همراه با زمینهٔ اجرا (چه دستوری زدید، چه انتظاری داشتید) به مدل می‌دهید.
3. اصلاح: از مدل می‌خواهید فقط همان بخش را اصلاح کند، نه کل فایل را بازنویسی کند.

بعد از اصلاح، دوباره اجرا می‌کنید. اگر خطای جدیدی آمد، حلقه از نو شروع می‌شود. نکتهٔ مهم این است که هر بار باید خطای جدید را کامل بدهید، نه اینکه بگویید «باز هم خطا داد».

چرا باید پیام خطا را کامل بدهیم

خیلی‌ها فقط یک خط از خطا را کپی می‌کنند یا آن را با جملات خودشان خلاصه می‌کنند؛ مثلاً می‌نویسند «یک خطای undefined داد». این کار دقیقاً همان مشکلی را ایجاد می‌کند که در مقالهٔ زمینه‌دادن به مدل گفتیم: مدل بدون اطلاعات کامل مجبور به حدس‌زدن می‌شود. پیام خطای کامل معمولاً شامل این‌هاست:

• متن کامل خطا، از جمله نوع خطا (مثلاً TypeError یا SyntaxError)
• stack trace یا مسیر فایل و شماره خطی که خطا در آن رخ داده
• دستوری که اجرا کردید و محیطی که در آن اجرا شد (لوکال، مرورگر، سرور)
• چه چیزی انتظار داشتید اتفاق بیفتد در مقابل چه چیزی واقعاً اتفاق افتاد

خطا (کامل، کپی‌شده از ترمینال):
TypeError: Cannot read properties of undefined (reading 'map')
    at ProductList (src/components/ProductList.tsx:14:22)

دستوری که زدم: npm run dev، بعد رفتم به صفحهٔ /products
انتظار داشتم: لیست محصولات نمایش داده شود
واقعاً چه اتفاقی افتاد: صفحه سفید شد و همین خطا در کنسول آمد

کد مربوطه (src/components/ProductList.tsx):
[کد کامل کامپوننت]

درخواست: علت خطا را توضیح بده و فقط تغییر لازم را پیشنهاد بده.

چند نکته دربارهٔ اصلاح

وقتی مدل راه‌حلی می‌دهد، قبل از اجرا سریع بخوانید ببینید منطقی است یا نه. اگر مدل به‌جای اصلاح یک خط، پیشنهاد بازنویسی کامل فایل را داد، از او بخواهید فقط تغییر مینیمال را نشان بدهد؛ این هم خطر خراب‌کردن بخش‌های سالم را کم می‌کند و هم فهمیدن اینکه واقعاً چه چیزی عوض شده را ساده‌تر می‌کند.

یک تلهٔ رایج این است که وقتی خطای جدید ظاهر می‌شود، بلافاصله راه‌حل قبلی را کنار می‌گذارید و کل مسیر را عوض می‌کنید. بهتر است اول ببینید آیا خطای جدید ادامهٔ همان مشکل قبلی است یا کاملاً جدا؛ اگر مدل توضیح داد چرا این خطا رخ داده، آن توضیح را بخوانید، چون معمولاً سرنخ خطای بعدی هم همان‌جاست.

وقتی خطا در محیط اجرا رخ می‌دهد نه در کد

گاهی پیام خطا اصلاً به کد شما ربطی ندارد؛ مثلاً پورت اشغال است، یک وابستگی نصب نشده، یا نسخهٔ نرم‌افزار روی سیستم شما با چیزی که مدل فرض کرده فرق دارد. در این موارد، دادن پیام خطا به همراه اطلاعات محیط (سیستم‌عامل، نسخهٔ ابزار مربوطه) به مدل کمک می‌کند تشخیص بدهد که مشکل از کد نیست، از محیط اجراست. اگر مدل چند بار پیشنهاد داد کد را تغییر دهید ولی مشکل حل نشد، این یک نشانهٔ قوی است که باید سراغ محیط اجرا بروید، نه کد.

چه وقت باید دست از تلاش برداشت

حلقهٔ خطا-توضیح-اصلاح همیشه جواب نمی‌دهد. چند نشانه هست که باید متوقف شوید و خودتان دستی وارد شوید یا مسیر را عوض کنید:

• اگر بعد از سه یا چهار رفت‌وبرگشت همان خطا (یا نسخهٔ کمی تغییریافته‌اش) دوباره برمی‌گردد، احتمالاً مشکل در جای دیگری از پروژه است که مدل نمی‌بیند.
• اگر هر اصلاح یک باگ جدید در جای دیگر ایجاد می‌کند، یعنی مدل دارد بدون فهم کامل معماری پروژه پچ روی پچ می‌گذارد.
• اگر خطا مربوط به چیزی بیرون از کد است (تنظیمات سرور، دسترسی شبکه، مجوز فایل)، این‌ها را باید خودتان بررسی کنید؛ مدل به محیط اجرای شما دسترسی مستقیم ندارد مگر اینکه ابزارش این امکان را بدهد.
• اگر خودتان هم دیگر نمی‌فهمید کد چه می‌کند، وقت آن است که عقب بروید، کد را ساده‌تر کنید یا از مدل بخواهید کل بخش را توضیح بدهد، نه اینکه فقط اصلاح کند.

در این لحظه‌هاست که دانش پایه اهمیت پیدا می‌کند؛ کسی که حتی سطح مقدماتی منطق برنامه‌نویسی را بداند، می‌تواند تشخیص بدهد کجا مدل در حلقه گیر کرده. برای همین در نقشهٔ راه وایب کدینگ همیشه تأکید می‌شود که وایب کدینگ جایگزین فهمیدن کد نیست، ابزار سریع‌ترکردن آن است.

جمع‌بندی

• حلقهٔ خطا، توضیح، اصلاح را دنبال کنید: هر بار خطای کامل بدهید، نه خلاصه.
• پیام خطا باید شامل متن کامل، مسیر فایل، دستور اجرا و انتظار شما باشد.
• از مدل بخواهید تغییر مینیمال بدهد، نه بازنویسی کامل فایل.
• اگر بعد از چند تلاش همان خطا برمی‌گردد یا باگ جدید می‌سازد، دست نگه دارید و خودتان دستی بررسی کنید.
• برخی خطاها بیرون از کد هستند (سرور، شبکه، مجوز) و مدل به آن‌ها دسترسی ندارد.
• وقتی خطای جدید ظاهر شد، اول ببینید ادامهٔ همان مشکل قبلی است یا کاملاً جدا، نه اینکه بی‌درنگ مسیر را عوض کنید.