سود:
- توانایی توصیف موثر یک باگ به هوش مصنوعی با پیام خطا، ردیابی پشته و کوچکترین نمونه بازتولید
- امکان اجرای یک جریان اشکال زدایی سیستماتیک با هوش مصنوعی برای یافتن علت اصلی با فرضیه سازی و محدود کردن گام به گام آن
- امکان تأیید اینکه آیا راه حلی که هوش مصنوعی پیشنهاد کرده است در واقع مشکل را با بازتولید و آزمایش رگرسیون برطرف کرده است.
اشکال زدایی وظیفه یافتن دلیل رفتار متفاوت برنامه با آنچه انتظار می رود و رفع آن است، و زمان زیادی از مهندسان را می گیرد. اشکال زدایی خوب مبتنی بر یک بازی حدس زدن نیست، بلکه بر اساس محدود کردن سیستماتیک است: علامت را روشن کنید، فرضیه سازی کنید، فرضیه را آزمایش کنید، به علت اصلی برسید. هوش مصنوعی شریک بسیار قدرتمندی در این چرخه است. اما فقط در صورتی که اطلاعات صحیح را به او بدهید. گفتن «کد کار نمیکند، آن را اصلاح کنید» هوش مصنوعی را مجبور میکند حدس بزند و پیشنهادات کلی بدهد. پیام خطای کامل، ردیابی پشته و کوچکترین نمونه تولید مثل را به آن بدهید و با هم علت اصلی را پیدا خواهید کرد.
در این بخش خواهیم دید که چگونه به طور موثر یک باگ را برای هوش مصنوعی توصیف کنیم، فرضیه ها را گام به گام محدود کنیم و از طریق آزمایش رگرسیون تأیید کنیم که اصلاح پیشنهادی واقعاً مشکل را حل می کند. به یاد داشته باشید: "رفع" یک باگ و "سرکوب علائم اشکال" دو چیز متفاوت هستند. تصحیح بدون یافتن علت اصلی، خطا را به مکان دیگری منتقل می کند.
مفاهیم: ردیابی پشته: تخلیه ای که نشان می دهد کدام توابع در زمان خطا به چه ترتیبی فراخوانی شده اند. Minimal repro: سادهترین و کوتاهترین کد/ورودی که باعث ایجاد خطا میشود. علت اصلی: منبع واقعی مشکل، نه علامت. تست رگرسیون: آزمایشی که اطمینان حاصل می کند که همان خطا تکرار نمی شود.
توصیف یک اشکال برای هوش مصنوعی
احتمال یافتن علت اصلی توسط هوش مصنوعی با کیفیت اطلاعاتی که ارائه میدهید مستقیماً متناسب است. یک توصیف خطای خوب شامل موارد زیر است: کاری که سعی کردید انجام دهید، انتظار داشتید، چه اتفاقی افتاد، متن خطای دقیق و ردیابی پشته، کد درگیر، محیط (زبان/نسخه/OS)، و کوچکترین نمونه ای که خطا را ایجاد کرد.
- علامت را روشن کنید. در قالب "X مورد انتظار، Y واقعی".
- متن خطای کامل را جایگذاری کنید و ردیابی را پشته کنید. آن را کوتاه نکنید، سانسور کنید، اما ساختار را نشکنید.
- کوچکترین تولید مثل را بدهید. حداقل ورودی و کدی که باعث ایجاد خطا می شود.
- محیط را مشخص کنید. نسخه زبان، نسخه کتابخانه، محیط زمان اجرا.
اعلان توصیف خطای موثر: "من در حال رفع اشکال هستم. اطلاعات:- کاری که میخواهم انجام دهم: [X]- رفتار مورد انتظار: [Y]- رفتار واقعی: [Z]- پیام خطای کامل و ردیابی پشته: [پیست کردن]- محیط: [زبان/نسخه، کتابخانه/نسخه]- ابتدا به احتمال زیاد کد اصلی را برطرف کنید. به ترتیب احتمال و به من بگویید چه چکی را برای هر کدام تأیید کنم."
محدود کردن جریان با فرضیه
اشکال زدایی سیستماتیک هنر حذف یک به یک احتمالات است. از هوش مصنوعی برای ایجاد فرضیه استفاده کنید و آزمایش را برای آزمایش هر فرضیه طراحی کنید. سپس آزمایش را اجرا کنید و نتیجه را برگردانید. این چرخه بسیار سریعتر از عادت ایجاد تغییرات تصادفی و توقف است که به آن "اشکال زدایی با تفنگ شاتگان" می گویند.
اعلان کمکی جستجوی دودویی (نصف بخش): "این خطا دیروز وجود نداشت، امروز وجود دارد. می خواهم بفهمم کدام یک از 20 تغییر آخر خطا را با bisect آورده است. یک طرح گام به گام به من بدهید: کدام نقطه را باید تست کنم، به کدام نیمه باید بسته به نتیجه بروم. همچنین به من بگویید دقیقاً در هر مرحله چه چیزی را بررسی کنم."
اعلان استراتژی درج گزارش: "من نمی توانم خطا را پیدا کنم زیرا نمی توانم مقادیر میانی را در این تابع ببینم. به من بگویید در چه نقاطی باید خطوط گزارشی را اضافه کنم که کدام متغیرها را چاپ می کند. توضیح "از این گزارش چه خواهم آموخت" را برای هر گزارش اضافه کنید. همچنین هشدارهایی را مشخص کنید که از ثبت اطلاعات محرمانه جلوگیری می کند."
نکته: اگر نمی توانید یک خطا را حل کنید، بیشتر اوقات مشکل در جایی است که شما اشتباه فرض کرده اید. از هوش مصنوعی بپرسید "چه فرضی که من می توانم اشتباه باشد؟" پرسیدن کوری تو را می شکند. سخت ترین اشتباهات در جایی پنهان می شوند که می گویید "مطمئنم این درست کار می کند".
اعلان ضعیف / اعلان قوی
ضعیف:"کد من یک خطا می دهد، آن را برطرف کنید: [200 خط کد]" (نتیجه: هوش مصنوعی نمی داند چه خطایی دارد، چه چیزی مورد انتظار است؛ پیشنهادهای کلی بر اساس حدس و گمان ارائه می دهد، اکثر آنها بی فایده هستند.)STRONG:"من NullPointerException را دریافت می کنم. انتظار می رود: لیست کاربران باید برگردانده شود. [paste]. Environment: Java 17. حداقل تکرار: زمانی اتفاق می افتد که لیست کاربران خالی باشد، اما نه زمانی که 15 خط مرتبط است: [کد] علت اصلی و چرایی فعال شدن لیست خالی را توضیح دهید.
اعلان قدرتمند خطا را در متن قرار می دهد: در این صورت اتفاق می افتد (فهرست خالی) و در این صورت اتفاق نمی افتد (لیست کامل). این سرنخ واحد ("وقتی خالی اتفاق می افتد") تقریباً مستقیماً به علت اصلی اشاره می کند. از آنجایی که این اطلاعات در اعلان ضعیف در دسترس نیست، هوش مصنوعی حدس میزند.
بررسی رفع مشکل
یک اصلاح تنها زمانی یک اصلاح واقعی است که سه کار را انجام دهد:
کنترل کنید
سوال
نحوه تایید
آیا خطا از بین رفته است؟
الان هم همین ورودی جواب میده؟
Minimal repro را دوباره اجرا کنید
خطای جدیدی وجود ندارد؟
آیا چیز دیگری خراب است؟
کل مجموعه آزمایشی را اجرا کنید
تکرار نمیشه؟
آیا همان خطا دوباره رخ خواهد داد؟
برای این سناریو تست رگرسیون اضافه کنید
اصلاحاتی که بدون یافتن علت اصلی انجام می شود، اغلب علائم را سرکوب می کند. به عنوان مثال، پنهان کردن یک خطای تهی با "پرش اگر خالی" دلیل واقعی را ایجاد می کند، "چرا داده ها باطل می شوند؟" نامرئی است و خطا در جای دیگری تکرار می شود.
موارد کوچک
مورد 1 - تله سرکوب علائم. یک تیم، گاه به گاه یک خطای تهی را با یک امتحان، خاموش می کند. خطا ناپدید می شود اما پس از 2 هفته به نظر می رسد داده ها از دست رفته اند. دلیل واقعی این است که یک سرویس در زمان وقفه تهی می شود. وقتی از هوش مصنوعی میپرسید «چرا پوچ میشود؟»، علت اصلی ظاهر میشود. تعمیر واقعی 1 ساعت طول می کشد اما دائمی است.
مورد 2 - حداقل قدرت مجدد. یک توسعه دهنده نمی تواند اشکالی را که می گوید "هر چند وقت یک بار خراب می شود" را برطرف کند. با پیشنهاد AI خطا را به کوچکترین ورودی کاهش می دهد: مشکل فقط با نام فایل های حاوی کاراکترهای ترکی رخ می دهد (خطای رمزگذاری). وقتی 300 خط عدم قطعیت به 5 خط تکرار قطعی کاهش یابد، راه حل آشکار می شود.
مورد 3 - تست ضد رگرسیون. هوش مصنوعی یک خطای محاسبه تاریخ را برطرف می کند. مهندس به این راضی نیست. یک تست رگرسیون برای سناریوی اشتباه اضافه می کند (پایان ماه، 31 ژانویه + 1 ماه). هنگامی که تغییر دیگری 4 ماه بعد به همان منطقه می رسد، تست قرمز می شود و اشکال قبل از رسیدن به مرحله تولید پیدا می شود.
اشتباهات رایج
- این به معنای "این کار نمی کند، آن را تعمیر کنید". بدون متن خطا، انتظار و تکرار، هوش مصنوعی حدس میزند.
- عدم دادن ردپای پشته. ردیابی پشته اغلب مستقیماً علت اصلی را نشان می دهد.
- به ایجاد تغییرات تصادفی ادامه دهید. آزمایشها بدون ایجاد فرضیه زمان را تلف میکنند.
- سرکوب علامت و از دست دادن علت اصلی. خطا در جای دیگری دوباره متولد می شود.
- ایمن نشدن رفع مشکل با تست رگرسیون. همان خطا در آینده بی سر و صدا برمی گردد.
به طور خلاصه
اشکال زدایی مؤثر، محدود کردن سیستماتیک است، نه حدس زدن. دادن متن کامل خطا، ردیابی پشته، حداقل بازتولید و اطلاعات محیطی به هوش مصنوعی شانس یافتن علت اصلی را به طور تصاعدی افزایش می دهد. از هوش مصنوعی برای ایجاد فرضیه استفاده کنید و آزمایش را برای آزمایش هر فرضیه طراحی کنید. شما آزمایش را اجرا کنید. تنها زمانی که میبینید که باگ از بین رفته است، هیچ باگ جدیدی معرفی نشده است، و با تست رگرسیون محافظت میشود، یک اصلاح "انجام شد" را در نظر بگیرید.
وظیفه کاربردی
یک خطای واقعی یا مصنوعی را در نظر بگیرید. ابتدا خطا را به کوچکترین بازتولید کاهش دهید (در کدام ورودی رخ می دهد، در کدام ورودی رخ نمی دهد). با استفاده از دستور دستور اشکال موثر، از هوش مصنوعی 3 فرضیه علت اصلی و یک مرحله تأیید برای هر کدام بخواهید. با آزمایش فرضیه ها یک به یک علت اصلی را پیدا کنید، آن را برطرف کنید، سپس یک تست رگرسیون برای این سناریو بنویسید و اجرا کنید تا نشان دهید که باگ از بین رفته است و تست محافظت می کند.
چک لیست
- [ ] من علامت را به صورت "منتظره در مقابل تحقق یافته" روشن کردم.
- [ ] من متن کامل خطا و stack trace را به هوش مصنوعی دادم.
- [ ] من خطا را به کوچکترین بازتولید کاهش دادم.
- [ ] با آزمون فرضیه ها یک به یک علت اصلی را پیدا کردم.
- [ ] به جای سرکوب علامت، علت اصلی را برطرف کردم.
- [ ] من اضافه کردم و یک تست رگرسیون برای همان خطا اجرا کردم.