اشکال‌یابی: خودتان پیدا کنید

بیشتر مبتدیان با اشکال برنامه مثل دیوار رفتار می‌کنند. به آن برخورد می‌کنند، متوقف می‌شوند، و از کسی می‌خواهند برای آن‌ها کار را انجام دهد. عادتی که واقعاً مهارت ایجاد می‌کند متفاوت است: یاد می‌گیرید اشکال را مثل سؤالی تعامل کنید که پاسخ آن قابل یافتن است، و قبل از اینکه سؤال کنید برای یافتن آن تلاش کنید.

پیام خطا را مثل شاهدی بخوانید، نه صدای نویز

Stack trace ها مرتب به خاطر ظاهر ترسناک‌شان نادیده گرفته می‌شوند. اما معمولاً دقیقاً می‌گویند کجا و چرا چیزی خراب شده. اگر TypeError: 'NoneType' object is not subscriptable در Python دریافت کنید، این تصادفی نیست — به این معنی است که متغیری که انتظار داشتید لیست یا دیکشنری داشته باشد، در واقع None است. شماره خط به شما می‌گوید کجا اتفاق افتاده. کار شما این است که از آن خط به عقب بروید و بیابید مقدار کجا باید تعیین می‌شد اما نشد.

این کار را قبل از جستجو در اینترنت انجام دهید: ابتدا آخرین خط traceback را بخوانید، سپس بالا بروید. آخرین خط معمولاً نام استثنای واقعی را ذکر می‌کند. خطوط بالایی زنجیر فراخوانی‌هایی را نشان می‌دهند که شما را به آن‌جا رساندند.

آن را عمداً تکرار کنید

اگر اشکالی فقط گاهی اوقات ظاهر می‌شود، هنوز آن را نمی‌فهمید. قبل از تغییر کد، سعی کنید آن را قابل تکرار کنید. یک ورودی را در یک بار تغییر دهید. آیا با لیست خالی ناموفق است اما با لیست کامل نه؟ آیا فقط در دومین فراخوانی تابع ناموفق است، نه در اول؟ اشکالی که می‌توانید عمداً تکرار کنید 80 درصد حل شده است، چون حالا می‌توانید بررسی کنید که تعمیر واقعاً کار کرد یا نه، نه اینکه حدس بزنید.

مسئله را نصف کنید، سپس دوباره نصف کنید

جستجوی دودویی فقط برای آرایه‌های مرتب نیست — سریع‌ترین راه برای یافتن کد خراب در تابع یا pipeline طولانی است. دومین نیمی از منطق خود را کامنت کنید یا دور بزنید و بررسی کنید که نیمی اول هنوز اشکال را تولید می‌کند یا نه. اگر بله، مسئله در نیمی اول است. اگر نه، در نیمی دوم است. تکرار کنید. این برای اسکریپت 200 خطی درست کار می‌کند، همان طور که برای pipeline داده‌ای چند مرحله‌ای کار می‌کند که خروجی را در هر مرحله با print() یا df.head() بررسی می‌کنید.

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

وقتی print() دیگر کار نمی‌کند، از debugger استفاده کنید

print() عبارت‌ها برای موارد ساده خوب هستند، اما زمانی که state را در چند فراخوانی تابع تعقب می‌کنید، یک debugger واقعی وقت واقعی صرفه‌جویی می‌کند. در Python، import pdb; pdb.set_trace() را درست قبل از خط مریب قرار دهید، اسکریپت را اجرا کنید، و یک prompt زنده دریافت می‌کنید جایی که می‌توانید متغیرها را بررسی کنید، خط به خط با n جلو بروید، و با s داخل فراخوانی‌های تابع بروید. Debugger داخلی VS Code کار یکسانی با breakpoint‌هایی که کلیک می‌کنید جای تایپ انجام می‌دهد. هر طریقی، هدف یکسان است: state واقعی برنامه‌تان را تماشا کنید نه اینکه حدس بزنید احتمالاً چیست.

آن را از بقیه پروژه خود جدا کنید

اگر اشکالی داخل codebase بزرگ اتفاق افتد، آن را درون codebase بزرگ debug نکنید. تابع مرتبط را در فایل تازه‌ای با ورودی جعلی و کمینه که همان خرابی را تولید می‌کند کپی کنید. اگر اشکال ناپدید شود، چیزی در زمینه اطراف — متغیر global، یک import، state قدیمی — دلیل واقعی است، و شما به‌تازگی چیز مهمی یاد گرفتید. اگر اشکال در تنهایی ادامه یابد، حالا یک مورد کوچک، قابل اشتراک، قابل آزمایش دارید، و بسیار نزدیک‌تر به تعمیر واقعی هستید.

فرض‌های خود را در برابر واقعیت بررسی کنید، نه حافظه

بخش عظیمی از وقت اشکال‌یابی به فرض‌های بی‌سؤال می‌رود: