دیباگ با دستیار کدنویسی: از حدس تا شواهد

بازتولید، خط زمانی، فرضیه قابل‌ابطال و یک تغییر در هر مرحله، دستیار را از حدس‌سازی به حل مسئله می‌برد.

پاسخ کوتاه

به دستیار نگویید «این خطا را حل کن» و انبوه log را رها نکنید. نسخه، ورودی، انتظار، نتیجه واقعی و حداقل مراحل بازتولید را بدهید؛ سپس از او بخواهید فرضیه‌ها را با شواهد موافق و مخالف رتبه‌بندی کند.

گردش‌کار پیشنهادی

1. باگ را در محیط کنترل‌شده و داده غیرحساس بازتولید کنید.
2. رویدادها را با timestamp و شناسه correlation در یک خط زمانی بچینید.
3. آخرین تغییرات مرتبط و مرزهای سرویس را با diff مشخص کنید.
4. سه فرضیه قابل‌ابطال و ارزان‌ترین مشاهده برای رد هرکدام بسازید.
5. در هر مرحله فقط یک متغیر را عوض و نتیجه را ثبت کنید.
6. پس از یافتن علت، تست regression بنویسید و اصلاح کوچک انجام دهید.

مثال اجرایی

اگر timeout فقط پس از انتشار رخ می‌دهد، فرضیه‌ها را به کندی dependency، تغییر retry یا اشباع pool تفکیک کنید. برای هرکدام metric یا log مشخص بخواهید؛ افزایش تصادفی timeout تشخیص علت نیست.

چطور نتیجه را راستی‌آزمایی کنیم؟

اصلاح باید تست بازتولید را سبز کند، بدون اینکه assertion یا مسیر خطا حذف شود. همان ورودی و شرایط اولیه را دوباره اجرا و نشانه‌های جانبی را پایش کنید.

خطاهای رایج

اطلاعات حساس در log، چند تغییر هم‌زمان، پذیرش اولین توضیح plausible و درمان نشانه به‌جای علت چهار دام رایج‌اند.

جایگاه این مطلب در مسیر یادگیری

برای قفل‌کردن علت، گردش‌کار تست‌نویسی با AI و برای کنترل اصلاح، چک‌لیست بازبینی را دنبال کنید.

منابع و محدودیت

این روش بر مشاهده‌پذیری و آزمون فرضیه تکیه دارد. مدل می‌تواند ارتباط‌ها را پیشنهاد کند، اما علت فقط با شواهد سیستم و بازتولید تأیید می‌شود. مستند git diff و GitHub: review AI-generated code.

جمع‌بندی

دستیار دیباگ زمانی ارزشمند است که سرعت ساختن و رد فرضیه را بالا ببرد، نه اینکه یک روایت قانع‌کننده بدون آزمایش بسازد.