‏ساختار پوشه‌ها: پیدا کردن یا جا دادن؟

Sterling Freeman تو این مقاله می‌گه هر ساختار پوشه، چه برای کد چه برای یادداشت، به دو سؤال جواب می‌ده: «X رو کجا پیدا کنم؟» (navigation) و «X رو موقع ساختن کجا بذارم؟» (classification). به گفته‌ش اسم‌هایی که به پیدا کردن کمک می‌کنن لزوماً به جا دادن کمک نمی‌کنن. پژوهش George Furnas و همکاراش تو ۱۹۸۷ به اسم vocabulary problem نشون داد وقتی دو نفر مستقل یه چیز رو اسم‌گذاری می‌کنن، کمتر از ۲۰٪ مواقع روی یه اسم توافق دارن.

برای سنجیدن هر کدوم هم روش هست: tree testing (یعنی یه نفر از بالای درخت شروع می‌کنه و زمان و گیرهاش ثبت می‌شه) برای پیدا کردن، و card sorting (یعنی آدم‌ها فایل‌ها رو تو پوشه‌ها دسته‌بندی می‌کنن و دیده می‌شه به یه جواب می‌رسن یا نه) برای جا دادن.

ساختار نقش‌محور مثل forms/، modals/ و layout/ برای همه، حتی طراح و مدیر محصول، قابل فهمه. ولی به گفته‌ی نویسنده، مشکل رو فقط عقب می‌ندازه: یه فرم داخل یه modal باید کجا بره؟ نشونه‌ش پوشه‌ی همه‌کاره‌ای مثل shared/ یا utils/ هست که اگه حواست نباشه بیشتر کدبیس رو می‌گیره. این ساختار جهت وابستگی‌ها رو هم کنترل نمی‌کنه. پیشنهاد نویسنده یه ساختار لایه‌ای به اسم CE Pattern با سه لایه‌ست:

components/
├── core/      # Untouched vendor components (e.g. shadcn, private registry)
├── elements/  # Enriched UI vocabulary
└── patterns/  # Composed, purpose-specific combinations

لایه‌ی core کد دست‌نخورده‌ی vendor هست. elements یه منبع می‌گیره و همون تعداد یا بیشتر export می‌ده، مثلاً یه Button از shadcn که ButtonPrimary و ButtonGhost و ButtonLoading رو بیرون می‌ده. patterns دو یا چند منبع می‌گیره و کمتر export می‌ده، مثل SearchBar که از Input و Button و Label ساخته شده. یعنی دسته‌بندی با شمردن مشخص می‌شه نه با سلیقه، و وابستگی‌ها فقط رو به پایین می‌رن.

هزینه‌ش اینه که اسم elements/ در نگاه اول کمتر از forms/ حرف می‌زنه. ولی نویسنده معتقده اشتباه تو پیدا کردن یه بار هزینه داره، در حالی که اشتباه تو جا دادن کم‌کم تبدیل به قاعده می‌شه و بعداً refactor کردنش گرون‌تره. برای تیم‌های کوچیک و چندتخصصی، نقش‌محور قابل دفاعه؛ ولی هر جا کتابخونه‌ی کامپوننت مشترک هست یا تیم داره بزرگ می‌شه، لایه‌ای بهتر جواب می‌ده. به گفته‌ش AI هم این تصمیم رو جای تو نمی‌گیره.

نکات کلیدی:

• طبق پژوهش Furnas (۱۹۸۷)، دو نفر کمتر از ۲۰٪ مواقع روی یه اسم توافق دارن
• ساختار نقش‌محور پیدا کردن رو راحت می‌کنه ولی پوشه‌ی shared/ رو پر می‌کنه
• تو CE Pattern، elements یه ورودی و همون تعداد یا بیشتر خروجی داره و patterns دو یا چند ورودی و خروجی کمتر
• وابستگی‌ها فقط از patterns به لایه‌های پایین‌تر می‌رن، نه برعکس
• CE Pattern به شکل یه agent skill عمومی منتشر شده