انواع متدولوژی در سی اس اس نویسی

ما معمولاً برای اینکه کدی تمیز، خوانا و قابل نگهداری تولید کنیم، به مشکلاتی بر می‌خوریم که باید اون‌ ها رو حل کنیم. اما بهتره اول چند تا از این مشکلات رو بشناسیم :

• تکرار کردن کدهای روتین و معمول
• عدم پایپندی به درج کامنت‌ها
• استفاده از سلکتورهای بیش از حد
• نام‌گذاری ضعیف کلاس‌ها
• و ...

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

کامنت گذاری

بخش زیادی از سردرگمی‌ های توسعه‌ دهندگان در مراجعه مجدد به کد، با کامنت‌گذاری در روند توسعه قابل حل هست. CSS زبان نشانه‌ گذاری است، بنابراین طبیعی هست اگر فقط با دیدن چند خط کد، نتوانید درک کنید که چه اتفاقی دارد رخ می دهد و نتیجه‌ی این خطوط از کدها چی هست. حتماً این تجربه رو داشتید که وقتی بعد از بیش از یک سال یا حتی چند ماه، به کدهای خودتون نگاه می‌کنید نمی‌تونید درک کنید چرا یه همچین کدی نوشتید؟ این چند خط کد وظیفه‌ شون چی هست؟ معمولاً توسعه‌ دهنده‌ ها در این شرایط تو وضعیتی قرار می‌گیرند که انگار خودشون این کدها رو ننوشتند و با کدها کاملاً غریبه هستند. به همین دلیل، کامنت‌گذاری در طول روند توسعه میتونه راه حلی برای این مشکل باشه. هیچوقت این مرحله رو به بعداً واگذار نکنید. یکی از بهترین کارها اینه که تو کامنت‌ها، طرز فکر خودتون رو شرح بدید، اینکه چرا همچین راه حلی اتخاذ کردید. در آینده وقتی با خوندن کامنت‌ها، با طرز فکرتون در چند ماه پیش آشنا میشید، این کدها مجدداً براتون قابل فهم میشه.

متدولوژی BEM چیست؟

متدولوژی BEM مخفف Block Element Modifier است. BEM یک متدولوژی برای توسعه فرانت‌اند هست و میشه ازش به عنوان یک متدولوژی کامل نام برد. چیزی که توجه ما رو میتونه جلب کنه استراتژی نام‌گذاری در این متد هست. با استفاده از این استراتژی می توانیم کلاس‌ ها رو به ۳ گروه کلی تقسیم کنیم :

• بلاک (‌Block) : ریشه و پایه کامپوننت است. Block موجودیت مستقلی است که به تنهایی معنادار می باشد. با این که Block ها درون هم می آیند و با هم تعامل دارند اما از هم دیگر تاثیر نمی گیرند. نام Block می تواند حروف لاتین، اعداد و خط فاصله باشد.
• عنصر (Element) : کامپوننتی که خود درون بلاک قرار دارد. Element ها بخش هایی از Block هستند که مستقلا معنایی ندارند. هر Element به Block خود متصل است. نام Element می تواند حروف لاتین، اعداد، خط فاصله و Underscore باشد. کلاس CSS آن متشکل از نام Block به علاوه دو تا Underscore به علاوه نام Element می باشد.
• پیراینده (Modifier) : تغییر یا گسترش بلاک می باشد. Modifier برای تغییر ظاهر، رفتار و یا وضعیت استفاده می شود. نام Modifier می تواند حروف لاتین، اعداد، خط فاصله و Underscore باشد. کلاس CSS آن متشکل از نام Block یا نام Element به علاوه دو تا خط فاصله به علاوه نام Modifier می باشد.

.byline {}
.byline__name {}
.byline__title {}
.byline__picture {}
.byline--expanded {}
.byline--expanded__bio {}

متدولوژی OOCSS چیست؟

حتماً با مفهوم شئ‌ گرایی در برنامه نویسی آشنا هستید یا حداقل اسمش رو شنیدید. شئ‌ گرایی یک الگوی برنامه‌نویسی هست و برای شکستن کارهای بزرگ به چند کار کوچک استفاده می شود. وقتی این مفهوم به دنیای استایل‌ شیت‌ ها میاد بهش میگیم OOCSS. در اینجا ما کمتر با تکنیک‌ های پیاده‌ سازی سر و کار داریم و مهم طرز فکر ما نسبت به روند توسعه است. مفهوم اصلی در جداسازی ساختار عناصر، از استایل آن‌ هاست. به این ترتیب نتیجه این کپسوله سازی این هست که می توانیم بدون پیاده‌سازی مجدد عناصر، از آن‌ها در قطعات مختلف کد استفاده‌ی مجدد کنیم که باعث میشه سرعت توسعه افزایش پیدا کنه و حجم کد تولیدی کاهش داشته باشد. OOCSS یک الگو ( پارادایم ) برنامه نویسی است. OOCSS مخفف Object Oriented CSS است، در واقع همان مفهوم برنامه نویسی Object Oriented را دارد ( Spaghetti CSS در مقابل OOCSS ). در OOCSS تمرکز بر روی کامپوننت های منعطف، ماژولار و قابل تعویض است که تنها یک کار را انجام می دهند. در واقع در OOCSS کامپوننت ها تنها یک وظیفه دارند و از یکدیگر مستقل هستند.

.media {}
.media .img {}
.media .img img {}
.media .imgExt {}
.bd {}

متدولوژی SMACSS چیست؟

متدولوژی SMACSS ( تلفظ Smacks ) مخفف Scalable and Modular Architecture است. SMACSS یکی از روش های دیگر نوشتن CSS است. در این شیوه سطوحی معرفی شده اند که CSS باید در آن سطوح نوشته شود. به عبارتی دیگر SMACSS مجموعه‌ای از گاید‌لاین‌ ها هست که به ما کمک می‌کند تا کد بهتری در CSS تولید کنیم. SMACSS نه ابزار توسعه است و نه قوانین سختگیرانه‌ ای که باعث هراس توسعه‌ دهنده‌ ها باشد، بلکه راهنمای منعطفی هست که در نظر گرفتنش دید بهتری در زمینه توسعه کدهای فرانت‌اند بهمون میده. هدف SMACSS تولید کدهایی است که خوانایی بالاتری داشته باشند، قابل توسعه و نگهداشت باشند و امکان استفاده مجدد از آن‌ها وجود داشته باشد.

اگر بخواهیم نگاه کلی‌ ای به آن چیزی که SMACSS به ما پیشنهاد میده داشته باشیم، بهتره با ساختار بندی پروژه شروع کنیم. SMACSS هسته پروژه را در ۵ دسته بندی کلی قرار داده و با تعاریف و مثال‌ هایی از قطعه کدهای کاربردی، سعی داره تا مفاهیم لازم رو به مخاطبین انتقال بده. این ۵ دسته به قرار زیر هستند :

• قوانین Base : این قوانین شامل تعریفات اولیه هستند، به عنوان مثال تعریف فونت و سایز متن برای پروژه، پیش‌ فرض‌ هایی که برای فرم‌ها در نظر گرفته می شود، رنگ لینک‌ ها و هاور لینک‌ ها و قوانین پایه‌ای دیگر. حتی فریمورک‌ های CSS Reset را هم می توانیم جزء این دسته‌بندی در نظر بگیریم.
• قوانین Layout : برای بخش‌ بندی صفحه به اجزای کوچک تر در نظر گرفته می شود. تعریف مختصات و مکان نمایش هدر و فوتر از این دست از قوانین هستند. Layout ها مکانی هستند که ماژول‌ ها در آن‌ ها قرار می‌گیرند. سیستم‌گرید‌ هایی مثل 960 و Susy هم در این دسته از قوانین طبقه‌بندی می‌شوند.
• قوانین Module : شامل تعریف بخش‌ هایی از طراحی هستند که احتمال استفاده مجدد آن‌ ها وجود دارد. لیست‌ محصولات، اسلایدر‌ها، فرم ورود و ثبت نام و غیره نمونه‌ هایی از ماژول‌ های پروژه هستند.
• قوانین State : راهی هستند برای تشریح چگونگی نمایش Module ها و Layout ها در یک State خاص. به عنوان مثال فرض کنید یک دکمه رو به عنوان ماژول طراحی کرده‌اید. این دکمه می‌تواند در وضعیت فعال و یا غیر فعال نمایش داده شود، می‌تواند دکمه حذف کالا و یا اضافه کردن کالا به سبد خرید باشد.
• قوانین Theme : برای تمام پروژه‌ ها لازم و ضروری نیست، بلکه بسته به ماهیت پروژه می‌توان از آن استفاده کرد. Theme موجود در سرویس‌ های Gmail و یا Yahoo Mail را در نظر بگیرید. شما به عنوان یک کاربر می توانید با اعمال تنظیمات خاص، قالب جدیدی برای صفحه ایمیل خود اعمال کنید. این نقطه‌ ای است که قوانین Theme به کمک توسعه‌ دهندگان می‌آیند. در واقع قوانین Theme می‌تواند تمام کدهای بخش‌ های فوق را باز نویسی کند.

در کنار تعریف ساختار فوق، می توان از قوانین نام‌ گذاری‌ ای که SMACSS پیشنهاد کرده نیز پیروی کرد. به عنوان مثال استفاده از پیشوند‌ هایی مانند -l و یا -grid برای Layout ها از این دست از قوانین هستند. توسعه دهندگان بسته به قوانینی که در نظر می‌گیرند می‌توانند مستند سازی خاص خود را داشته باشند.

نکته : علاوه بر متدولوژی هایی که در این مقاله اشاره کردیم، متدولوژی های دیگری نیز در سی اس اس نویسی وجود دارند که کم تر از آن ها استفاده می شود و از اهمیت کم تری برخوردار هستند که این متدولوژی ها عبارت اند از : Systematic CSS ، SUIT CSS ، ITCSS ، Atomic CSS و ...