راستی‌آزمایی وقتی کد بلد نیستی

در فصل ۴.۴ دیدیم سه حالت شکست بی‌صدا هستند. یعنی اگر فعالانه نگردی، پیدایشان نمی‌کنی.

و مشکل عمیق‌تری هم هست: خروجیِ مرتب، حسِ درستی می‌دهد. جدولِ منظم و لحنِ مطمئن باعث می‌شوند مغز آدم بررسی را رها کند — همان چیزی که در فصل ۰.۲ گفتیم، «خواندن با حالتِ تحسین به‌جای حالتِ بازبینی».

پس قاعده‌ی این فصل: خروجی را با «چقدر خوب به نظر می‌رسد» نسنج. با «چه چیزی را باید درست انجام می‌داد و آیا داد» بسنج.

و خبر خوب: هیچ‌یک از چهار روش این فصل، کد خواندن لازم ندارد. همه‌شان روی خروجی کار می‌کنند، نه روی راهی که به آن رسیده.

قوی‌ترین روش، و ساده‌ترین. یک نمونه بردار که جوابش را از قبل می‌دانی — چون خودت دستی حسابش کرده‌ای، یا از دفعه‌ی قبل داری‌اش.

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

و این دقیقاً همان چیزی است که در فصل ۲.۴.۳ برای تعریف «تمام شد» ساختیم. اگر آن spec را نوشته باشی، این آزمون از قبل آماده است.

معیار یک نمونه‌ی خوب — و منبع رسمی هم همین را می‌گوید: معیار موفقیت باید مشخص و قابل‌اندازه‌گیری باشد، نه «عملکرد خوب». پس:

• ❌ «گزارش درستی بدهد»
• ✅ «برای فایل هفته‌ی گذشته، سه عدد ۱۲،۰۰۰ و ۸،۴۰۰ و ۹،۶۰۰ را بدهد و آن دو ردیف تاریخ‌خراب را هم فهرست کند»

و از همان منبع، یک قاعده‌ی مهم: آزمون‌ها را طوری بساز که کارِ واقعی را بازتاب دهند — و حالت‌های لبه را از قلم نینداز. که موضوع بخش بعدی است.

یک ابزار که روی داده‌ی معمولی کار می‌کند، لزوماً روی داده‌ی غیرمعمولی کار نمی‌کند. و داده‌ی واقعی همیشه غیرمعمولی می‌شود.

پنج حالت لبه که همیشه ارزش امتحان دارند:

• خالی — فایلی بدون هیچ ردیف. چه می‌کند؟ خطای مفید می‌دهد یا عددِ صفرِ بی‌سروصدا؟
• تکراری — دو ردیف یکسان. حسابشان می‌کند یا یکی می‌گیرد؟ و کدام درست است؟
• ناقص — ردیفی با خانه‌ی خالی. همان چیزی که در فایل نمونه‌ی این دوره هست.
• خیلی بزرگ — ده برابر داده‌ی معمول. مرزهای فصل ۴.۱.۳.
• نامعتبر — چیزی که اصلاً از جنسِ مورد انتظار نیست. مثل همان ردیفِ از‌جا‌دررفته‌ی فصل ۴.۲.۴.

منبع رسمی هم فهرست مشابهی می‌دهد و یکی را اضافه می‌کند که ارزش گفتن دارد: حالت‌های مبهم — جایی که حتی دو آدم هم به یک نتیجه نمی‌رسند. برای آن‌ها جوابِ درست این است که ابزار بگوید مبهم است، نه اینکه یک طرف را انتخاب کند. همان چیزی که در فصل ۰.۲ از آن دو ردیفِ مشکوک خواستیم.

به‌خاطر بسپار فایل نمونه‌ها/داده/فروش-۱۴۰۵.csv این دوره عمداً هر پنج حالت را دارد. برای امتحان‌کردنِ هر ابزاری که می‌سازی، لازم نیست داده‌ی خراب بسازی — همان فایل را بده.

روش سوم غیرمستقیم است ولی عجیب مؤثر: بخواه توضیح بدهد چه کار کرده.

چرا کار می‌کند؟ چون توضیح‌دادن، فرض‌ها را بیرون می‌کشد. جمله‌هایی مثل «مرجوعی‌ها را کم کردم» یا «ردیف‌های بدون تاریخ را کنار گذاشتم» — هر کدام یک تصمیم است که تو نگفته بودی و او گرفته.

سه شکل که خوب جواب می‌دهند:

• «این عدد را چطور حساب کردی؟ کدام ردیف‌ها را شمردی؟»
• «چه فرض‌هایی گذاشتی که من نگفته بودم؟»
• «اگر بخواهم به این عدد اعتماد کنم، چه چیزی را باید خودم چک کنم؟»

و مهم: خودِ توضیح را هم باور نکن. توضیح، جاهایی را که باید بگردی نشانت می‌دهد — راستی‌آزمایی نمی‌کند. اگر گفت «مرجوعی‌ها را کم کردم»، برو ببین واقعاً کم شده‌اند.

ساده‌ترین روش، و آن که همه از قلم می‌اندازند.

شمردن. اگر ورودی ۸۰۰ ردیف داشت، خروجی چند ردیف را حساب کرده؟ اگر ۷۹۰ بود، ده ردیف کجا رفتند؟ این یک سؤال است و بیشتر خطاهای بی‌صدا را می‌گیرد.

عددهایی که همیشه ارزش شمردن دارند: تعداد ردیف ورودی و خروجی · تعداد موردهایی که خواسته بودی (فصل ۴.۴.۴) · تعداد ردیف‌های کنارگذاشته‌شده.

نمونه‌گیری. نمی‌توانی ۸۰۰ ردیف را چک کنی — ولی می‌توانی پنج تا را. و انتخابشان مهم است:

• اولی و آخری — مرزها معمولاً جای خطا هستند.
• بزرگ‌ترین و کوچک‌ترین — اگر عددی درگیر است.
• و یکی تصادفی از وسط.

پنج نمونه از ۸۰۰ ردیف، دو دقیقه وقت می‌گیرد و بیشترِ خطاهای سیستماتیک را نشان می‌دهد — چون خطای سیستماتیک در همه‌ی ردیف‌ها هست، نه در یکی.

این را نگه دار — تا آخر دوره لازمش داری، و در ماژول ۸ برای هر اتوماسیونی که می‌سازی به کارش می‌بری.

1. بشمار. ورودی چند بود، خروجی چند؟ چند مورد خواسته بودم، چند تا آمد؟
2. پنج نمونه چک کن. اولی، آخری، بزرگ‌ترین، کوچک‌ترین، یکی تصادفی.
3. روی نمونه‌ی معلوم امتحان کن. اگر داری‌اش.
4. حالت‌های لبه را بده. حداقل «خالی» و «ناقص».
5. بپرس چه فرض‌هایی گذاشته — و آن فرض‌ها را چک کن.
6. بپرس عددها را چطور حساب کرده — با ابزار یا خودش؟ (فصل ۴.۱.۱)
7. برای فارسی: یکسان‌سازی شده؟ (فصل ۴.۲.۴)

و یک نکته‌ی مقیاس: عمق راستی‌آزمایی باید به پیامد بستگی داشته باشد. برای یادداشت شخصی، مورد ۱ کافی است. برای چیزی که به مشتری می‌رسد یا رویش تصمیم گرفته می‌شود، هر هفت مورد.

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