یک سیستم واقعی را باز می‌کنیم

مسئله از یک واقعیتِ M1 شروع می‌شود: ایجنت بین session‌ها هیچ‌چیز یادش نمی‌ماند (فصل ۱.۴.۱). پس هر بار که کاری شروع می‌شد، باید همه‌چیز از نو توضیح داده می‌شد: این پروژه چیست، قبلاً چه تصمیم‌هایی گرفته شد، کجا ماند.

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

• فایل بزرگ شد و کسی نخواندش.
• حافظه‌ی پایدار و وضعیتِ امروز قاطی شدند، پس هیچ‌کدام قابل اعتماد نماندند (همان چیزی که فصل ۶.۳.۳ درباره‌اش هشدار داد).
• و بدترش: هر کسی که کار می‌کرد، خودش هم حافظه را عوض می‌کرد — پس هیچ‌جا معلوم نبود کدام جمله معتبر است.

و همین سومی، تصمیم معماریِ اصلی را ساخت: کسی که کار می‌کند، اجازه‌ی نوشتن در حافظه را ندارد.

سیستم دو اتاق دارد، و مرزشان جدی است:

و حالا تصمیم‌های طراحی که در این تصویر پنهان‌اند:

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

آزمون «این فایل کِی عوض می‌شود؟» (فصل ۶.۳.۴) را روی هر فایل اجرا کن و ببین چطور جواب می‌دهد:

• یادداشت‌های موضوعی — یک فایل برای هر موضوع (هر پروژه، هر سیستم، هر شخص). عوض می‌شود وقتی چیزی درباره‌ی آن موضوع تغییر کند. این «حقیقتِ فعلی» است — نه تاریخچه.
• _تغییرات.md — تاریخچه. عوض می‌شود هر بار که چیزی در حافظه نوشته شود. اینکه این از یادداشت‌ها جدا است عمدی است: یادداشت باید خوانا بماند، و تاریخچه یادداشت را شلوغ می‌کند.
• _ورودی.md — همان ورودیِ فصل ۶.۶: جایی که چیزهای ثبت‌نشده می‌افتند تا بعداً پردازش شوند. ثبت در آن ارزان است، عمداً.
• _وضعیت.md (در اتاق کار) — کجا بودیم. عوض می‌شود هر بار که کار می‌شود.
• _گزارش‌ها/ — یک فایل برای هر کارِ تمام‌شده. اضافه می‌شود، هیچ‌وقت عوض نمی‌شود. این صندوقِ پستیِ بین دو اتاق است.

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

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

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

این بخش صادقانه‌ترین بخش فصل است، و مفیدترینش.

چه چیزی کار کرد:

• مرزِ نوشتن. تک‌تصمیمی که بیشترین ارزش را داشت. حافظه قابل اعتماد ماند، چون یک راه ورود داشت.
• جداکردن وضعیت از حافظه. کارِ نیمه‌کاره قابل ادامه شد بدون اینکه حافظه‌ی پایدار را آلوده کند.
• یک فایل، یک موضوع. باعث شد بشود فقط همان تکه‌ی مربوط را خواند — که هم ارزان‌تر است و هم دقیق‌تر (فصل ۲.۷.۲).

و چه چیزی کار نکرد — سه شکست واقعی:

1. گزارش‌نوشتن، آخرین قدم بود؛ پس حذف شد. این بدترینشان بود. چون گزارش انتهای کار بود، وقتی کار تمام می‌شد دیگر انگیزه‌ای نمانده بود. یک بار نُه روز کار پشت سر هم گزارش نشد و هیچ‌چیز متوجهش نشد — چون سیستم راهی برای دیدنِ نبودن نداشت. حل: یک بررسی که کارهای گزارش‌نشده را پیدا می‌کند و اول هر کار نشانشان می‌دهد. یعنی همان درس فصل ۶.۴.۴ — قانونی که رعایت نمی‌شد به بررسی تبدیل شد، نه به تأکید بیشتر.
2. حافظه فقط اضافه می‌شد. هیچ‌وقت چیزی حذف نمی‌شد، پس یادداشت‌ها کم‌کم پر از چیزهای منقضی شدند — دقیقاً همان ضدالگوی فصل ۶.۳. این هنوز کامل حل نشده است؛ فقط یک مرورِ دوره‌ای اضافه شد.
3. ورودی سریع‌تر از پردازش پر می‌شد. ثبت ارزان بود (که خوب است)، ولی پردازش وقتِ ثابت نداشت (که بد است) — و نتیجه‌اش انبوهی شد که خودش دلیلِ سراغ‌نرفتن شد. همان گیرِ شماره‌ی یکِ فصل ۶.۶.۴، عیناً.

و الگوی مشترکِ این سه: هر سه‌شان جاهایی بودند که سیستم به یادآوریِ انسان تکیه کرده بود. هر جا که سیستم گفت «یادت باشد که…»، دیر یا زود شکست. هر جا که به یک بررسی یا یک ساختار تبدیل شد، دوام آورد.

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

و یک صداقتِ لازم: آن «بررسیِ کارهای گزارش‌نشده» که در بخش قبل گفتیم، یک برنامه‌ی کوچک است — و این نقض این فصل نیست، بلکه دقیقاً همان الگویی است که فصل ۶.۱.۳ وعده داد:

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

اگر از اول با کد شروع شده بود، هیچ‌کدام از این سه شکست پیدا نمی‌شد — چون زیر پیچیدگیِ کد پنهان می‌ماندند.