پوشه و فایل به‌عنوان معماری

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

چرا؟ چون نام، قاعده را در خودش حمل می‌کند. مقایسه کن:

• اسناد — چیزی نمی‌گوید. هر فایلی می‌تواند داخلش باشد، پس همه‌چیز داخلش می‌رود، پس بی‌فایده می‌شود.
• قراردادهای-امضانشده — یک شرط در خودش دارد. وقتی قراردادی امضا شد، باید از آن بیرون برود. نام، خودش دارد به تو می‌گوید چه کار کنی.

این تفاوت کوچکی نیست. نام دوم یک سیستم است؛ نام اول یک انبار.

سه قاعده‌ی عملی برای نام‌گذاری:

• وضعیت را در نام بیاور، نه موضوع را. «در انتظار پاسخ» بهتر از «ایمیل‌ها» است، چون می‌گوید قدم بعدی چیست.
• عدد بگذار اگر ترتیب دارد. ۰۱-ورودی و ۰۲-درجریان هم مرتب می‌مانند و هم ترتیبِ کار را نشان می‌دهند.
• یک پیشوند برای فایل‌های سیستمی. مثلاً _قانون.md. آن _ می‌گوید «این محتوا نیست، این خودِ سیستم است» — و همیشه بالای فهرست می‌ماند.

یک ساختار واقعی این شکل است — و به هر شاخه نگاه کن که چه نقشی دارد، نه چه اسمی:

دو تصمیم در این ساختار هست که ارزش دیدن دارند:

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

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

دو راه برای برقرارکردن نظم هست:

• قاعده‌ی سخت — چیزی جلویت را بگیرد. مثل نرم‌افزاری که اجازه نمی‌دهد فرم را بدون پر کردن یک فیلد ذخیره کنی.
• قرارداد — قاعده‌ای که همه می‌دانند و رعایت می‌کنند، ولی هیچ‌چیز به‌زور اعمالش نمی‌کند. مثل «نام فایل با تاریخ شروع می‌شود».

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

ولی یک شرط دارد: قرارداد باید نوشته شده باشد. قراردادی که فقط در سرِ توست، تا اولین هفته‌ی شلوغ زنده می‌ماند. جایش _قانون.md است — و فصل ۶.۴ تمامش درباره‌ی نوشتنِ همین است.

و کجا قرارداد کافی نیست؟ آن‌جا که اشتباهش گران است. اگر رعایت‌نکردنِ یک قرارداد می‌تواند داده را از بین ببرد، آن‌جا دیگر قرارداد نمی‌خواهی — محافظت می‌خواهی (فصل ۵.۱).

این بخش همان چیزی است که این فصل را از یک درسِ نظم‌وترتیب جدا می‌کند.

ایجنت پوشه‌ی کارت را می‌بیند و نام فایل‌ها را می‌خواند (فصل ۳.۲.۱). پس نام‌گذاری خوب، برای او هم راهنماست — و نام‌گذاری بد، او را هم گم می‌کند. چهار چیز که تفاوت واقعی می‌سازند:

• نام باید محتوا را پیش‌بینی کند. اگر فایلی _وضعیت.md نام دارد، ایجنت می‌تواند حدس بزند برای فهمیدن «کجا بودیم» باید آن را بخواند — بدون اینکه تو بگویی.
• یک‌دستی مهم‌تر از زیبایی است. اگر نصف فایل‌ها با تاریخ شروع می‌شوند و نصفشان نه، هیچ الگویی وجود ندارد که تشخیص داده شود.
• فایل سیستمی را از محتوا جدا کن. همان پیشوند _. یعنی «این را برای فهمیدنِ سیستم بخوان، نه به‌عنوان داده».
• و از خودش بپرس. ساختارت را نشانش بده و بگو «از این ساختار چه می‌فهمی؟ کدام پوشه برایت مبهم است؟» اگر او گم شد، ساختار مشکل دارد — نه او.

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