بعضی پروژه‌ها برای پیدا کردن یک تکه کد، بیشتر از تغییر دادنش وقت می‌گیرن.

اگه برای تغییر یه component مجبور میشی بین پنج تا پوشه رفت‌وبرگشت کنی، معماری پروژه تمیز نیست؛ فقط فایل‌ها خوب از هم قایم شدن.

روی کاغذ همه‌چیز مرتب و تفکیک‌ شدست؛ اما برای فهمیدن یک feature باید نصف پروژه رو بگردیم.

خیلی وقت‌ها Separation of Concerns رو با جداکردن فایل‌ها بر اساس نوعشون اشتباه می‌گیریم: همه‌ی componentها یک‌جا، همه‌ی hookها یک‌جا، testها در یک پوشه و هر تابع کوچیکی هم داخل utils.

اوایل پروژه این ساختار خیلی مرتب به نظر میاد. اما بعد از مدتی برای فهمیدن رفتار یک feature باید چند جای مختلف پروژه رو بگردیم و رابطه‌هایی رو پیدا کنیم که داخل ساختار پوشه‌ها اصلاً دیده نمیشن.

اینجاست که Colocation کاربردی میشه.

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

مثلاً اگه یک utility فقط داخل ProductCard استفاده میشه، منتقل‌کردنش به utils عمومی پروژه باعث reusable شدنش نمیشه؛ فقط مالکیتش رو مبهم می‌کنه. بعداً ProductCard حذف میشه ولی اون utility و testهاش باقی می‌مونن، چون کسی مطمئن نیست جای دیگه‌ای استفاده میشن یا نه.

تا وقتی مصرف‌کننده‌ی دومِ واقعی وجود نداره، اون utility بهتره کنار همون feature بمونه. وقتی واقعاً shared شد و قرارداد مشخصی پیدا کرد، انتقالش به یک بخش عمومی معنی پیدا می‌کنه.

برای تصمیم‌گیری میشه سه سؤال ساده پرسید:

۱. اگه این feature حذف بشه، این فایل هنوز کاربردی داره؟

۲. الان چند مصرف‌کننده‌ی واقعی داره، نه احتمالی؟

۳. برای تغییر این رفتار باید بین چند پوشه جابه‌جا بشم؟

اگه فایل فقط به یک feature وابسته‌ست، احتمالاً جاش همون نزدیکی‌هاست؛ چه test باشه، چه style، hook، query یا utility.

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

هدف از ساختار پروژه فقط مرتب‌کردن فایل‌ها نیست. ساختار خوب باید مالکیت و وابستگی‌ها رو واضح کنه تا تغییر، حذف و refactor کردن کد هزینه‌ی کمتری داشته باشه.

مقاله‌ی Kent C. Dodds:
https://kentcdodds.com/blog/colocation

@DevTwitter | <Reza Safari/>