ساخت و خودارزیابی

spec داری. حالا بساز — و این بار هیچ قدمِ تازه‌ای یاد نمی‌گیری؛ فقط همه‌ی چیزهایی که بلدی را پشت سر هم می‌گذاری. مسیر همان است:

1. زمین را امن کن. پوشه‌ی کار، نسخه‌ی پشتیبان، و یک ثبت اولیه (فصل ۵.۲.۴). ده ثانیه.
2. اول طرح بخواه، بعد اجرا (فصل ۳.۱.۲). spec را بده و بگو «قبل از اینکه چیزی بسازی، بگو چطور می‌خواهی انجامش بدهی.»
3. تکه‌تکه بساز و بین تکه‌ها نگاه کن (فصل ۲.۵.۲). نه یک درخواستِ بزرگ.
4. راستی‌آزمایی کن — با همان روشی که در spec نوشتی، نه با نگاه‌کردن به خروجی (M4).
5. مقصد را وصل کن (فصل ۸.۵) و یک بار واقعی اجرا کن.
6. و فایل توضیح بنویس (فصل ۸.۸.۱)، همین حالا نه بعداً.

و اگر جایی گیر کردی: از خودِ ایجنت بپرس (فصل ۲.۸.۳)، یا session را ببند و تازه شروع کن (فصل ۱.۳.۵). این دو تا، هشتاد درصدِ گیرها را باز می‌کنند.

به‌خاطر بسپار اگر وسط کار احساس کردی داری چیز تازه‌ای یاد می‌گیری، احتمالاً پروژه‌ات بزرگ‌تر از حدِ لازم است. پروژه‌ی پایانی قرار است تثبیت کند، نه گسترش بدهد. آن چیزِ تازه را در بک‌لاگ بنویس برای اتوماسیون بعدی.

حالا خودت بسنج. این چک‌لیست کلِ دوره را در ده سؤال جمع می‌کند:

1. سه شرطِ spec برقرارند؟ (هر سه، نه دو تا.)
2. با یک ورودی واقعی — نه نمونه — اجرا شده؟
3. خروجی را راستی‌آزمایی کردی، با روشی غیر از نگاه‌کردن؟
4. یک ورودی عجیب امتحان شد و رفتارش معلوم است؟ (فصل ۸.۷.۱)
5. خروجی به مقصد واقعی می‌رود؟ (نه به یک فایل آزمایشی.)
6. اگر خراب شود، می‌فهمی؟ (فصل ۸.۷.۳)
7. فایل توضیح دارد که فردا هم قابل فهم باشد؟
8. داده‌ی حساسی جایی نمی‌رود که نباید؟ (فصل ۵.۳)
9. کلیدی در جای غلط نیست؟ (فصل ۷.۵.۳)
10. و می‌توانی توضیح بدهی چرا کار می‌کند؟

اگر بندهای ۱ تا ۷ تیک خوردند، پروژه‌ات تمام است. بندهای ۸ و ۹ شرطِ لازم‌اند نه امتیاز — بدون آن‌ها تمام نیست، هرچقدر هم خوب کار کند. و بند ۱۰ موضوع دو بخش بعد است.

احتمال زیادی هست که پروژه‌ات همه‌ی آنچه می‌خواستی را نکند. مثلاً:

• هشتاد درصدِ موارد را درست انجام می‌دهد و بقیه را باید دستی بکنی.
• یا کار می‌کند ولی هنوز خودکار نیست.
• یا فقط روی یک نوع ورودی جواب می‌دهد.

به‌خاطر بسپار اتوماسیونی که هشتاد درصدِ کار را می‌کند، هشتاد درصدِ وقت را برمی‌گرداند. این شکستِ ناقص نیست؛ نتیجه‌ی کامل است. و آن بیست درصدِ باقی‌مانده معمولاً همان‌جایی است که قضاوت لازم دارد — یعنی همان‌جایی که M5 گفت باید دستِ تو بماند.

و اشتباهی که اینجا رایج است: دنبال صددرصد رفتن. آن بیست درصدِ آخر معمولاً به‌اندازه‌ی هشتاد درصد اول کار می‌برد — و اغلب ارزشش را ندارد. تصمیمِ درست این است: بنویس چه چیزی پوشش داده نمی‌شود (در همان فایل توضیح، بندِ «چه چیزی را نمی‌کند»)، و برو سراغ اتوماسیون بعدی.

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

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

در پنج خط توضیح بده چرا پروژه‌ات کار می‌کند. نه اینکه چه می‌کند — چرا. یعنی:

• چه چیزی به ایجنت داده می‌شود و چرا همان و نه بیشتر؟
• کجای کار قضاوت لازم دارد و چه کسی انجامش می‌دهد؟
• از کجا می‌دانی خروجی درست است؟
• اگر فردا خراب شود، اولین جایی که نگاه می‌کنی کجاست؟
• و چه چیزی را عمداً نساختی؟

و دلیلِ این آزمون، همان چیزی است که کلِ دوره رویش ساخته شده:

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

و اگر در نوشتنِ آن پنج خط جایی گیر کردی، همان‌جا نقطه‌ی ضعفِ پروژه است — نه ضعفِ توضیح دادنت. برگرد و همان تکه را بفهم.