اگر تا به حال فایل فیگمای پروژه ایرانی را باز کرده باشید و با لایه‌هایی مثل Final Button Copy (2) یا Div Block 274 مواجه شده باشید، دقیقاً می‌دانید از چه دردی حرف می‌زنم.

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

اما مشکل فقط اعصاب‌خردی نیست؛ نام‌گذاری بد هزینه دارد. سرعت تیم را می‌گیرد، باعث می‌شود محصول نهایی پر از ناهماهنگی باشد و آنبورد کردن یک طراح یا توسعه‌دهنده جدید را به عذاب تبدیل می‌کند.

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

بیایید یک بار برای همیشه این مشکل را حل کنیم.

[my_toc]

چرا نام‌گذاری‌های فعلی ما معمولاً افتضاح است؟

قبل از ارائه راه‌حل، بیایید ببینیم اصلاً چرا نام‌ها اینقدر بد از آب درمی‌آیند:

۱. نام‌گذاری بر اساس ظاهر، نه کاربرد

dokme-sabz-bozorg-ba-saye

این خیلی وسوسه‌انگیز است که چیزی که می‌بینیم را توصیف کنیم. اما اگر فردا رنگ برند از سبز به آبی تغییر کند چه؟ اگر بخواهیم همین دکمه را بدون سایه استفاده کنیم چه؟ آن وقت مجبوریم اسم کامپوننت را در صد جا عوض کنیم و این یعنی فاجعه.

قانون اول: نام کامپوننت باید کاربردش را بگوید، نه شکل و شمایلش را.

۲. نام‌گذاری بر اساس جایگاه

HomePage-Header-LoginButton

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

قانون دوم: کامپوننت‌ها باید مستقل از مکان و قابل استفاده مجدد باشند.

۳. نام‌های بی‌هویت و گنگ

Card-2, Wrapper, Main-Div

این اسم‌ها هیچ اطلاعاتی به ما نمی‌دهند. Card-2 چه فرقی با Card-1 دارد؟ Wrapper قرار است چه چیزی را در بر بگیرد؟ این نام‌ها همکار شما (و حتی خودتان در چند ماه آینده) را مجبور می‌کند برای فهمیدن ماهیت یک المان، کل ساختار را بررسی کند.

راه‌حل نهایی: قانون سه‌بخشی «جنس / مدل / حالت»

یک سیستم خوب باید مثل آدرس دادن، از کل به جزء باشد: قابل پیش‌بینی، مقیاس‌پذیر و معنادار. این سیستم ساده و قدرتمند را امتحان کنید:

جنس / مدل / حالت

این ساختار در فیگما با اسلش (/) پیاده‌سازی می‌شود و به طور خودکار کامپوننت‌های شما را به Variants یا «متغیرها» تبدیل می‌کند که کار با آن‌ها بی‌نهایت راحت است.

بخش اول: جنس (Block)

اینکه این کامپوننت چیست. اصل و اساس آن. نامی ساده، فارسی و قابل فهم. (البته در صورت تمایل میتوانید فارسی بنویسید. توصیه خود من انگلیسی نوشتن است)

• دکمه - Button
• کارت - Card
• ورودی (برای Input Field ها) - Input
• آیکون - Icon
• مودال - Modal

در پنل لایه‌های فیگما: نام کامپوننت اصلی شما این شکلی می‌شود: دکمه. _(Button/)

بخش دوم: مدل (Variant/Modifier)

اینکه این کامپوننت چه مدلی از آن جنس اصلی است. این مدل می‌تواند کاربرد، اندازه یا یک استایل خاص باشد.

• کاربرد: اصلی (Primary)، ثانویه (Secondary)، خطر (Destructive)
• اندازه: Small, Medium, Large (کوچک، متوسط، بزرگ)
• استایل: Outline, Ghost, Link (توخالی، لینک، متنی)

در پنل لایه‌های فیگما (با اسلش جدا کنید):

• Button/Primary/Medium
• Button/Secondary/Small
• Card/Featured

• دکمه/اصلی/بزرگ
• دکمه/ثانویه/متوسط
• کارت/محصول
• ورودی/جستجو

مزیت بزرگ در فیگما: وقتی این کار را می‌کنید، فیگما به طور خودکار یک Component Set می‌سازد و در پنل سمت راست به شما گزینه‌هایی مثل «نوع: اصلی/ثانویه» و «اندازه: بزرگ/کوچک» می‌دهد. جادویی!

بخش سوم: حالت (State)

وضعیت‌های مختلف یک کامپوننت در زمان تعامل کاربر با آن.

• پیش‌فرض (Default)
• هاور (Hover)
• فشرده (Active/Pressed)
• غیرفعال (Disabled)
• فوکوس (Focus)

در پنل لایه‌های فیگما:

• Button/Primary/Medium/Default
• Button/Primary/Medium/Hover
• Button/Primary/Medium/Disabled

• دکمه/اصلی/بزرگ/پیش‌فرض
• دکمه/اصلی/بزرگ/هاور
• ورودی/متن/فعال/خطا (یک مثال ترکیبی و پیشرفته)

با این سیستم، تمام کامپوننت‌های شما به شکلی کاملاً منظم و قابل جستجو دسته‌بندی می‌شوند.

تعریف ساختارها و نوع‌ها: با تیم خود (طراحان و توسعه‌دهندگان) جلسه بگذارید و بر سر یک لیست استاندارد از نام‌های پایه (Block) و انواع آن‌ها (Variant) به توافق برسید. مثلاً تصمیم بگیرید که اندازه‌ها sm, md, lg باشند یا Small, Medium, Large.

از فیگما تا کد: این سیستم چطور به توسعه‌دهنده کمک می‌کند؟

زیبایی این سیستم اینجا مشخص می‌شود. این نام‌گذاری مستقیماً به یک کدنویسی تمیز (مثلاً با متدولوژی BEM) ترجمه می‌شود.

مثال: طراح در فیگما کامپوننت کارت/محصول/ویژه را طراحی کرده است. توسعه‌دهنده دقیقاً می‌داند که باید چه کدی بنویسد:

HTML

<div class="card card--product card--featured">
  <img src="..." class="card__image">
  <div class="card__body">
    <h3 class="card__title">نام محصول</h3>
    ...
  </div>
</div>

این زبان مشترک، از ساعت‌ها بحث و تفسیر اضافی بین تیم طراحی و فنی جلوگیری می‌کند.

نقشه راه پیاده‌سازی در تیم شما

1. یک نگاه صادقانه به فایل فیگماتون بندازید: کامپوننت‌های فعلی را بررسی کنید. مشکلات کجاست؟ یک لیست از آشفتگی‌ها تهیه کنید.
2. روی نام‌ها توافق کنید: با تیم طراحی و فنی جلسه بگذارید. برای «جنس» و «مدل» کامپوننت‌های اصلی (دکمه، ورودی، کارت و...) یک واژه‌نامه مشترک بسازید. مثلاً توافق کنید که برای اندازه از «بزرگ، متوسط، کوچک» استفاده کنید یا lg, md, sm.
3. مستندش کنید: این قوانین را در یک صفحه Notion یا حتی در یک صفحه جداگانه در خود فیگما بنویسید تا همیشه جلوی چشم همه باشد.
4. کم‌کم شروع کنید: لازم نیست کل پروژه را یک‌شبه تغییر دهید. از این به بعد، تمام کامپوننت‌های جدید را با این سیستم بسازید و هر بار که با یک کامپوننت قدیمی کار داشتید، آن را اصلاح (Refactor) کنید.

حرف آخر: این فقط نام‌گذاری نیست، فرهنگ‌سازی است

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

یک سیستم نام‌گذاری درست و حسابی:

• سرعت را بالا می‌برد: دیگر کسی برای پیدا کردن یک دکمه ساده، کل فایل را زیر و رو نمی‌کند.
• ارتباط را شفاف می‌کند: طراح و توسعه‌دهنده با یک زبان مشترک حرف می‌زنند.
• نگهداری را ساده می‌کند: تغییر یک استایل در آینده، با کمترین دردسر انجام می‌شود.
• تیم را حرفه‌ای‌تر می‌کند: نشان می‌دهد که شما برای نظم و کیفیت کارتان ارزش قائلید.

پس دفعه بعد که خواستید اسم یک کامپوننت را CTA Button Final FINAL بگذارید، چند ثانیه فکر کنید. به این سیستم پایبند باشید و به آینده خودتان (و هم‌تیمی‌هایتان) یک لطف بزرگ بکنید.