آموزش دیباگ کردن

دیباگ کردن یعنی چه، و چرا بیشتر وقتتان صرف پیدا کردن می شود نه درست کردن؟

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

یک تعریف دقیق تر هم هست که همه چیز را ساده می کند: باگ جایی است که باور شما درباره برنامه با کاری که برنامه واقعا می کند فرق دارد. برنامه هیچ وقت «عجیب» رفتار نمی کند و هیچ وقت خلق و خو ندارد؛ دقیقا همان کاری را می کند که نوشته اید. پس دیباگ کردن یعنی پیدا کردن نقطه ای که تصور شما از واقعیت جدا شد.

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

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

چرا قبل از هر کاری باید خطا را قابل تکرار کنید؟

یک تکرار مطمئن یعنی بتوانید بنویسید: «این کار را بکن، این اتفاق می افتد.» تا وقتی این جمله را ندارید، هیچ چیز دیگری معنی ندارد. هر تغییری که بدهید، بعدش نمی دانید درست شد یا فقط این بار پیش نیامد.

یک تکرار خوب سه چیز دارد: کوتاه ترین مسیری که به خطا می رسد، همان داده ای که خطا با آن رخ می دهد، و شرط شروع مشخص. «گاهی وقت ها موقع ثبت سفارش خطا می دهد» تکرار نیست. «با کاربر تازه ساخته شده، سبد خالی، و کد تخفیف منقضی، دکمه ثبت خطای ۵۰۰ می دهد» تکرار است و همین جمله نصف کار را انجام داده.

حالا تله ای که روی همین سایت بارها هزینه داده و در پرونده فنی خودمان نوشته شده است: ممکن است تکرار شما اصلا چیزی را که فکر می کنید امتحان نکند. ما وقتی فایل کش یک صفحه را پاک می کنیم، انجین وب تا یک دقیقه همان فایل پاک شده را سرو می کند، چون نتیجه بررسی وجود فایل را برای ۶۰ ثانیه نگه داشته است. پس اگر بلافاصله بعد از پاک کردن، صفحه را باز کنید، همان صفحه قدیمی را می بینید و نتیجه می گیرید که پاک کردن کار نکرد. کار کرده بود؛ شما زود نگاه کردید.

این شکل خاصی از یک اشتباه عمومی است: بین کاری که کردید و چیزی که می بینید، یک لایه هست که خبر ندارید. کش مرورگر، کش شبکه، کش کد، یک نسخه قدیمی فایل روی سرور دیگر. اولین سوالی که باید از خودتان بپرسید این نیست که «چرا کار نمی کند»، این است که «اصلا مطمئنم دارم چیزی را که عوض کردم اجرا می کنم؟» روی کد پی اچ پی، ساده ترین راه ثابت کردنش این است که یک خط چاپ عمدا اشتباه بگذارید و ببینید آیا اصلا ظاهر می شود.

پیام خطا را چطور بخوانیم؟

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

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

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

و مهم ترین نکته این بخش: شماره خطی که خطا می دهد، جایی است که مشکل دیده شد، نه لزوما جایی که ساخته شد. اگر خط ۴۲ می گوید متغیر خالی است، خط ۴۲ سالم است؛ جایی که باید آن متغیر پر می شد و نشد، بالاتر است. یک مثال روزمره: پیام «تلاش برای صدا زدن یک متد روی مقدار null» تقریبا هیچ وقت درباره خطی نیست که در آن نوشته شده. درباره خطی است که انتظار داشتید آن مقدار را بسازد و به جایش چیزی برنگرداند، و بین آن دو خط ممکن است ده تابع فاصله باشد.

وقتی برنامه هیچ خطایی نمی دهد چه کار کنیم؟

سخت ترین باگ ها آنهایی هستند که خطا نمی دهند. برنامه اجرا می شود، تمام می شود، و نتیجه اشتباه است یا اصلا نتیجه ای نیست. اینجا اولین کاری که باید بکنید این است که مطمئن شوید واقعا خطایی نیست، یا خطا هست و شما آن را نمی بینید. این دو خیلی فرق دارند و در بیشتر موارد جواب دومی است.

سه جای معمول که خطا در آنها گم می شود: تنظیمات زبان که نمایش خطا را روی سرور خاموش کرده، بلوکی که خطا را می گیرد و کاری با آن نمی کند، و کانال خروجی اشتباه. آن سومی کمتر شناخته شده است و بیشترین وقت را می گیرد.

یک برنامه خط فرمان دو کانال خروجی جدا دارد و یک کد خروج. اگر شما فقط کانال اول را بخوانید، یک ابزار خراب و یک نتیجه خالی برایتان دقیقا یک شکل دارند. مثال واقعی از همین سرور، همان روزی که این درس نوشته شد: دستور پرس و جوی پایگاه داده وردپرس را اجرا کردیم و صفر بایت روی خروجی استاندارد داد. اگر همان جا نتیجه می گرفتیم «هیچ ردیفی نیست»، اشتباه بود. کد خروج ۱ بود و روی کانال خطا نوشته بود که اصلا نتوانسته به پایگاه داده وصل شود.

پس قانون این بخش: نتیجه خالی، شاهد نبودن چیزی نیست. قبل از اینکه به یک خروجی خالی اعتماد کنید، کد خروج را نگاه کنید و کانال خطا را جدا بخوانید.

همین اشتباه شکل ساده تری هم دارد که برای همه پیش می آید: ابزار جستجوی شما چیزی پیدا نمی کند و شما نتیجه می گیرید که آن چیز وجود ندارد. روی همین سایت، برچسب robots صفحه اصلی با کوتیشن تکی چاپ می شود. اگر با کوتیشن دوتایی دنبالش بگردید، صفر نتیجه می گیرید و می گویید برچسب نیست. برچسب هست. الگوی جستجوی شما اشتباه بود، و ابزار هم دقیقا همین را گفت: «چیزی که خواستی پیدا نشد.» بقیه اش را شما اضافه کردید.

نصف کردن: کوتاه ترین راه رسیدن به آن یک خط

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

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

سه شکل عملی این کار را در روز خودتان می بینید. روی کد: نصف تابع ها را کامنت کنید یا زودتر return بگذارید. روی داده: فایل ورودی هزار ردیفی را به پانصد ردیف ببرید و ببینید خطا می ماند یا نه، تا به کوچک ترین ورودی برسید که هنوز خطا می دهد؛ آن ورودی خودش نصف جواب است. روی زمان: اگر دیروز کار می کرد و امروز نه، بین دو نسخه بگردید نه بین هزار خط. گیت برای همین یک دستور به اسم git bisect دارد که خودش نصف می کند و شما فقط بعد از هر قدم می گویید این نسخه سالم بود یا خراب.

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

هر بار فقط یک چیز را عوض کنید، و بنویسید چه چیزی را امتحان کردید

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

روش درست شکل ثابتی دارد. یک فرضیه بسازید که بشود غلط بودنش را ثابت کرد: نه «فکر می کنم مشکل از کش است» بلکه «اگر مشکل از کش باشد، با پاک کردنش نتیجه عوض می شود.» بعد ارزان ترین آزمایشی را انتخاب کنید که این فرضیه را رد یا تایید کند، فقط همان یک چیز را عوض کنید، و نتیجه را ببینید. اگر فرضیه غلط بود، برگردانیدش سر جای اول. این برگرداندن را مبتدی ها انجام نمی دهند و بعد از یک ساعت، کد پر است از تغییرهای بی ربطی که خودشان باگ تازه می سازند.

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

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

چاپ کردن یا دیباگر؟ و روی سرور زنده چه کار کنیم؟

دو ابزار اصلی دارید و بحث «کدام بهتر است» بی معنی است، چون کار متفاوتی می کنند.

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

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

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

سه چیز که هیچ وقت نباید در لاگ بنویسید هم همین جا گفته شود: رمز، توکن، و اطلاعات شخصی کاربر. لاگ فایلی است که چند نفر می خوانند و مدت ها می ماند.