مقدمه ای بر اصول فرانت


نویسنده: هُمام قاسمی

در پروژه های بزرگ وب و نرم افزارهای تحت وب مدرن، ساخت ظاهر زیبا، کاربرپسند و کاربردپذیر، جز لاینفک دل مشغولی های صاحبان پروژه و مدیران فنی است.
معمولا در توسعه رابط کاربری (frontend development) بخشی که بسیار بر روی آن تاکید می شود، بخشهایی است که با زبان جاوااسکریپت نوشته می شود، چرا که جاوااسکریپت:

  • یک زبان برنامه نویسی است؛
  • قابل تست و پیش بینی است؛
  • و روش ها و پترن های مشخصی برای آن وجود دارد؛

و اگرچه امکانات، ابزار و روشهای اشکال گیری (دیباگ) آن نسبت به سایر زبان ها کم است، ناممکن نیست ولی بخشی که بیشتر مغفول مانده بخش مربوط به HTML و CSS است. چراکه:

  • این دو زبان کاملا به یکدیگر وابسته هستند؛
  • روش مشخص و معینی برای تست آن ها در دست نیست (اگرچه برخی روش ها موجود است ولی معمولا هیچکدام آن ها نمی تواند تمام یا بخشی از مشکلات را به شکل مطلوب برطرف نماید)؛
  • علاوه بر اینکه این دو، زبان برنامه نویسی نیستند و صرفا زبان های علامت گذاری (Markup Language) هستند، حتی در کدهای بشدت ورم کرده (Bloated) و درهم (Spaghetti) نیز معمولا به خوبی اجرا می شوند ونتیجه خروجی آن ها مخصوصا در پروژه های کوچک قابل قبول هستند.

در پروژه های بزرگ مانند وب سایت های چند زبانه، نرم افزارهای تحت وب، وب سایت های واکنشگرا (Responsive) و امثال آن ها به 3 دلیل باید توجه خاصی به استایلها و کدهای HTML داشت:

  • امکان اضافه کردن صفحات یا ماژول های جدید در کمترین زمان
  • امکان تغییر تمام یا بخشی از طرح با توجه به نیازهای سمت تجاری پروژه
  • امکان ردیابی اشکالات و رفع سریع آن ها

به همین دلایل استفاده از پیش پردازنده هایی مانند SCSS، LESS و غیره بسیار متداول شده اند که در حین رفع برخی مشکلات باعث ایجاد پیچیدگی ها و معضلات جدیدی شده اند که به برخی از آنها خواهم پرداخت.

در این جنگل تو در توی منابع و تکنولوژیهای توسعه رابط کاربری، بحث های داغ بسیاری در مورد جنبه ها و ابعاد مختلف این زمینه کاری مطرح است، از جنگهای صلیبی خونین بین فریم ورک ها گرفته تا گفتگوهای فلسفی پرحرارت و تعصب در مورد روش نام گذاری کلاس ها، یا دعواهای خیابانی بر سر اینکه استفاده از ID بهتر است یا Class یا اینکه از نام تگ ها بیشتر استفاده کنیم یا همه جا کلاس گذاری کنیم.

در این مقاله سعی در ارایه راه حل و یا راه تسهیل موارد زیر دارم:

  • برای شروع نوشتن یک پروژه بزرگ از کجا باید شروع کنم (یا شروع کنیم)
    • مواردی که در پروسه طراحی باید بخاطر داشت ودر طرح اعمال کرد
    • ایجاد ارتباط با طراحان بویژه طراحان کم یا بدون تجربه در طراحی برای وب و ابزار های جدید
    • مروری بر روش تحلیل طرح برای شروع استایل نویسی
  • ابزار مناسب برای کار
    • پیش پردازنده
    • پروسه های ساخت و ترجمه (Build – Compile) و پس از آن (پیشوند گذاری، حداقل سازی، UnCSS)
  • شناخت، انتخاب و استفاده از ساختار و روش مناسب
    • نیازها وپیش نیازهای نرم افزار نهایی (ابزار و مرورگر هدف، سرعت و بهینه بودن، زیبایی در مقابل کاربرد پذیر بودن و ...) و تاثیر آنها در روش پیش برد کار
    • استفاده و مدیریت تصاویر و علایم (SVG, Image Sprite, Font Icon)
    • فریم ورک ها
    • انتخاب یا تعریف قوانینی برای نوشتن کد (مخصوصا در کار تیمی)
    • انتخاب ساختار مناسب برای فایل های پارشال(بخش بخش) HTML وSCSS/LESS
  • بهترین معماری ممکن
    • متدولوژی های متداول، معرفی، مقایسه و انتخاب (OOCSS, SMACCSS, BEM, …)
    • فوت(حقه) های بسیار بسیار ساده، پیش پا افتاده ولی کار راه انداز
    • Shame File یا بخشی که آرزو می کنیم کسی آن را نبیند
  • باز-نویسی، ب ا ز ن و ی س ی، بــــاز نویـــســـــی تا بازنویسی

برای شروع نوشتن یک پروژه بزرگ از کجا باید شروع کنم (یا شروع کنیم)

این که از شروع یک پروژه یا ایده با آن باشیم حالتی ایده آل برای نوشتن کد مرتب و خوانا با خروجی مطلوب است. بسیاری از مشکلاتی که در هنگام کد نویسی رخ می دهد و یک توسعه دهنده باید سعی در حل آن داشته باشد از زمان شروع ایده پردازی و طراحی کار سرچشمه می گیرد:

  • کاربر هدف، ابزار مورد استفاده و کانال ارتباطی او برای دسترسی به سایت/نرم افزار مشخص نیست،
  • ارتباط نادرست بین طراح و توسعه دهنده مخصوصا اگر یک یا هردو طرف کم تجربه باشند،
  • تحلیل نادرست طرح و انتخاب اشتباه نقطه شروع،

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

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

قطعا زمانی که نیاز به حالت ریسپانسیو یک نرم افزار/وب سایت احساس می شود،توسعه دهنده رویکرد متفاوت با زمانی که دو خروجی متفاوت برای موبایل و دسکتاپ در نظر گرفته شده خواهد داشت. یا اگر پروژه ما بتواند از حدود 5 تا 8 درصد از مخاطبان که از اکسپلورر زیر 10 استفاده می کنند صرفنظر کرده یا آنها را به مرورگر جدیدتری سوق دهد می توان از راحتی کار با فلکس باکس لذت برد. اگر کاربری(Accessibility) برای پروژه مهم است پس باید ملاحظات مربوط به آن را در هنگام کد نویسی در نظر داشت و اگر مخاطبان پروژه از مرورگرهایی استفاده می کنند که از جاوااسکریپت پشتیبانی نمی کنند (یا آن را محدود کرده اند)، بدون شک به سراغ استفاده از فریم ورک های جدید جاوا اسکریپت نباید رفت یا اگر هم به آنها نیاز است باید فکری برای برآورده کردن نیازهای این دسته از کاربران در سر داشت.

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

برای جلوگیری از ناراحتی های بعدی قبل از قبول پروژه یا هنگام طراحی پروژه همیشه باید سعی کرد در کنار طراح بود، البته که نباید طراح را محدود ومعذب کرد ولی باید مفاهیم زیر را حتی به صورت تیتر وار به او گوشزد کرده و مرتب آنها را مانند مانترا (ذکر) تکرار نمود:

  • طراحی براساس گرید،
  • تفاوت های طراحی های محتوا محور (Content Driven Design) و کاربرد محور(Application Driven Design)،
  • تفاوت های تفکر و طراحی های Mobile First و Desktop First،
  • مفهوم مزایا و محدودیت های فریم ورک ها،
  • امکانات و محدودیت های انیمیشن ها،
  • مزایا، معایب و محدودیت های استفاده از فونت آیکون ها، SVG، و پسوندهای متفاوت فایل های گرافیکی و تفاوت هایشان،
  • مشخص کردن مرزهای باید و نباید (سیستم رنگ بندی، واحدهای اندازه گیری، نوع و تعداد طرح برای اندازه ها و دیوایس های متفاوت)،
  • در صورت آشنایی دولوپر با نرم افزارهای طراحی سوق دادن طراح به سمت نرم افزاری که در آن با هم بهتر تعامل داشته باشند،
  • تشریح مفهوم داینامیک اندازه بودن در قسمتهای مختلف مانند عناوین اینپوت ها و دکمه ها یا توضیحات،
  • شناساندن مفهوم سایت های ltr, rtl , bidirectional به طراح مانند اینکه نمی توان به سادگی در اینپوت ها پلیس هلدر rtl داشت در حال که متنش باید ltr باشد مانند فیلدهای url و email،
  • و تقریبا هر چیز دیگری که به ذهن می رسد.

یکی از ترفندها برای درگیر کردن طراحان، استفاده از CodePen.io است، ساختار اولیه ماژول مورد نظر را درآن قرار داده و تعدادی متغیر با نام های گویا و مشخص در ابتدای آن تعریف نمود، سپس از طراح خواسته شود که سعی کند با استفاده از آن متغیرها طرح خود را ایجاد کند، تمامی مشخصاتی مانند رنگ، سایه، متغیرهای انیمیشن همگی در این حالت قابل اصلاح هستند، در گام های بعدی متغیرها را کمتر و کمتر کرد، تا طراح عزیز به صورت ناخواسته قدری هم به کد آشنا شود. البته این پروسه یکی دوهفته ای نیست، ولی خروجی آن در چند ماه یکی شدن زبان طراح و توسعه دهنده است. هم طراح می داند تا کجا می تواند به توسعه دهنده فشار بیاورد و هم توسعه دهنده به مرور به طراح و کار او اطمینان پیدا می کند و الگوهای کاری او را می شناسد. اگرچه داشتن کمی اصطکاک در این میان کاملا طبیعی است.

اما هر طرحی، خوب باشد یا متوسط یا بد، برای پیاده شدن نیاز به تحلیل صحیح دارد. یک تحلیل صحیح باید:

  • آشنایی خوبی از ساختار نرم افزار، صفحات، ماژول ها، فایل های پارشال(HTML, Java Script, CSS)،
  • امکان پیش بینی برای کم و زیاد شدن و یا تغییر ماژول ها،
  • و امکان پیش بینی حالت های ریسپانسیو

را به دست بدهد.

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

ابزار مناسب برای انجام کار

عوامل متعددی در انتخاب ابزار کار تاثیر گذارند اما اصلی ترین آن ها:

  • توسعه دهنده،
  • پروژه و
  • کارفرما است

می بایست توجه داشت که هنگام کار با هر نرم افزار یا ابزاری همیشه امکان خرابی آن وجود دارد، پس همیشه باید ابزار جایگزین برای روز مبادا در دسترس باشد. نگارنده همیشه آخرین نسخه پرتابل سابلایم را با تمام پلاگین های معمول در گوگل درایو آماده استفاده دارد و اگرچه در محل شرکت از ویژوال استودیو و ابزارهای زیر مجموعه آن استفاده می کند، ولی همیشه نرم افزار پری پروز(PrePros) را در کنار آن نصب شده است و همیشه یک نسخه از فایل جیسان پکیجی که برای کامپایل کردن فایل ها نیاز دارد نیز روی سیستم شرکت وجود دارد.

آن که از ادیتور و IDE واجبتر است ابزار کنترل پروژه است، چرا که همیشه نسخه قابل اطمینانی از کار خود را در دسترس و امکان برگرداندن آن به نقطه ای قابل اطمینان را دارید.

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

در حال حاضر برای راحت تر و سریع تر نوشتن HTML، CSS و Java Script پیش پردازنده های گوناگونی در دسترس هستند. پیش پردازنده های جاوا اسکریپت در حال حاضر محل بحث ما نیستند، پیش پردازنده های HTML برای نوشتن کدهای استاتیک خیلی مناسب هستند ولی کد نویسی برای نرم افزار های تحت وب که عموما نیاز به نوشتن انواع متغیرها، شروط و حلقه های مورد نیاز برای فراخوانی اطلاعات از شمت سرور دارد با استفاده از این پیش پردازنده ها گاهی واقعا طاقت فرسا، یا حتی غیرممکن می شود. بنابراین شخصا از این پیش پردازنده ها کمتر استفاده می کنم.

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

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

امکان دیگری که استفاده از پیش پردازنده ها فراهم می کند، استفاده از فایلهای پارشال است. خورد کردن سورس کد به فایلهای پارشال، با افزایش سرعت دسترسی به کد و مستقل کردن کد هربخش یا ماژول از کل ساختار کد، نگهداشت پذیری(Maintainability) را به شدت افزایش می دهد. حال اگر از سورس مپ ها هم استفاده شودT برای دیباگ یک صفحه در مرورگر کافی است به قانون نوشته شده نگاه کنیم تا بدانیم در کدام فایل پارشال و در کدام خط آن باید راه حل را پیاده کنیم.

از زمانی که پیش پردازنده ها به دنیای توسعه سمت کاربر معرفی شدند، یکی از بزرگترین نقاط قوت آنها قابلیت استفاده از متغیرها در هنگام استایل نویسی بود، با این کار علاوه بر حفظ یکپارچگی کد، اصلاح و تغییر در آن بسیار ساده می شود، بعنوان مثال در نسخه جدید از پنل کاربری اخبار رسمی تصمیم تیم طراحی بر تغییر فونت شد، مشخصا فونت جدید که از خانواده سنز است با فونت قدیمی که اساس سریف دارد از نظر اندازه یکسان نیست و نیاز به تغییراتی در اندازه یا وزن فونت در نقاط مختلف دارد، علاوه براین در نسخه جدید تمامی رنگهای اصلی پنل قرار بود که تغییر کند، اگر بنا بر بالا و پایین رفتن بین چندین هزار خط و بررسی قانون به قانون بود جدای از هزینه بر بودن، همان Pure CSS کافی بود. ولی چون در همه جای کد از متغیرها برای رنگ و فونت استفاده شده بود و این دو مورد بطور کامل با میکسین ها کنترل می شدند(حتی در بسیاری از نقاط مانند هدرها که پیش بینی تغییر می شد برای وزن فونت هم متغیر ها مشخص شده بودند)، صرفا با انجام تغییرات در فایل پارشال تنظیمات این مورد در کمتر ازنصف روز انجام شد. البته نه برای فقط یک پنل بلکه نصف روز برای تغییرات رنگ در برندینگ همه سایتها و بک آفیس ها که بیشترین زمان آن هم برای بلاگ وردپرسی هزینه شد، چرا که کماکان خارج از پروسه کاری و کنترل پروژه بود.

هر بخش از فایلهای پیش پردازنده که تمام می شود این فایلها باید به CSS ترجمه شوند. ولی برای اینکه خروجی ما در تمام مرورگرهای هدف قابل استفاده باشد، باید بسته به آنها برای برخی موارد مانند انیمیشن ها یا ترنسفورم ها و مخصوصا فلکس ها باید از پیشوندهای مخصوص موتور هر مرورگر استفاده کرد. دانستن و استفاده بروز از این پیشوندها برای هیچ توسعه دهنده ای لازم نیست، چرا که می توان این کار را با استفاده از ابزارهایی به راحتی انجام داد، پر طرفدارترین این ابزارها CSS Autoprefixer است. پس از پیشوند گذاری، مرحله خلاصه و کوچک سازی است. در این مرحله تا حد امکان قوانینی که مشخصات یکسان دارند با هم دسته بندی می شوند، سپس تمامی فاصله ها، نقطه ویرگول های آخرین اعلان در هر مجموعه قانون(Rule-Set)، اینتر های آخر خطوط و کامنت ها حذف شده و یک فایل تک خطی به دست می دهد. آخرین مرحله قسمتی است که باید در آن دقت بیشتری کرد. به این مر حله اصطلاحا UnCSS گفته می شود برای این منظور فایل های HTML بررسی می شود و تمامی قوانین استفاده نشده در آن ها از فایلهای CSS خروجی حذف می شود. خطر این مرحله در اینجاست که گاهی برخی از قوانین که در CSS هستند، قوانین هستند که بعدا با استفاده از جاوااسکریپت به فایلهای HTML اضافه می شوند، که این مورد بخصوص در مورد فایلهای جاوااسکریپت اکسترنال مشکل ساز خواهد بود، البته در توضیحاتی که در مورد پلاگین UnCSS داده شده ذکر شده که این فایل ها اشکال ساز نمی شوند ولی تجربه ثابت کرده گاهی مشکلاتی پیدا می شوند، برای همین منظور عموما بعد از استفاده از ابزارهای مانند پلاگین UnCSS نود یک بار هم خروجی توسط یکی از افراد تیم که بر کل پروژه مسلط است باید بررسی و فایلهای HTML، CSSو Java Script با هم مقایسه شوند. مرحله UnCss کردن دستی معمولا درست قبل از انجام آخرین تست ها بر روی نسخه قبل از انتشار انجام می شود.

شناخت، انتخاب و استفاده از ساختار و روش مناسب

هنگامی که یک صفحه تحت وب را می بینیم تا زمانی که تراکنشی با آن صفحه نداشته باشیم چه صفحه پر باشد از انواع انیمیشن ها و ترنزیشن های مختلف و چه نباشد آن چه از نظر ظاهری برای ما تفاوت دارد، سرعت بارگذاری صفحه، تصاویر و نحوه بارگذاری است، مواردی از قبیل عدم نمایش فونت تا قبل از لود شدن آن یا استفاده از فونت های پیش فرض و سپس تغییر آن (که باعث پرش صفحه می شود)( Flash of Unstyled Text/Flash of Invisible Text) هم مشخصا باعث جلب توجه می شود. اینجاست که بایست ملاحظات کاربرد پذیری و تجربه کاربری را درنظر گرفت و دید که آیا از نظر پروژه سرعت بارگذاری صفحه ارزش بیشتری دارد یا انیمشین ها، سایه ها، فونت های فانتزی و ... . البته روش هایی هم برای بهبود این وضعیت وجود دارد مانند استفاده از Critical CSS یا بارگذاری استایل حاوی انیمیشن ها بعد از بارگذاری کل صفحه یا استفاده از جاوا اسکریپت برای اجرای انیمیشن ها. در مورد نوع انیمیشن ها، علاوه بر حجم، استفاده از منابع سیستم و همچنین کیفیت نمایش در صفحات موبایل هم مطرح است.

برای ساخت انیمیشن رعایت موارد زیر کمک بسیاری به سبکی حجم و نرمی اجرای انیمیشن می کند:

  • استفاده از ترانسفرم ها به جای استفاده از صفات ساختاری مانند پوزیشن ها، مارجین ها و پدینگ ها،
  • استفاده کمتر از توابع زمانی خیلی پیچیده،
  • استفاده از انیمشین صرفا برای تغییر اوپسیتی و ترانسفرم،

زمانی که طراحی یک پروژه آغاز می شود برای انتخاب سیستمی برای نمایش آیکون ها، لوگوها و علائم باید:

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

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

  • Image Sprite
  • Font Icon
  • SVG Sprite
  • Pure CSS Icons

از بالا به پایین به ترتیب حجم استفاده، چهار تکنیک اصلی برای ساخت آیکون و نمادهای داخل یک سایت/نرم افزار هستند. نکته بسیار مهم در انتخاب و استفاده از هرکدام از این سیستم ها این است که پس از بررسی و بالا و پایین و انتخاب هرکدام از این سیستم ها برای یک پروژه تا سرحد امکان باید از گریز زدن به سایر سیستم ها خودداری کرد، این کار باعث بهم ریختن یکپارچگی کد و سختی اصلاح و بروز رسانی کد می شود. حتی دیده شده که برخی از توسعه دهنده ها برای استفاده از چند آیکون محدود به جای ساخت آن آیکون در سیستم مورد استفاده خود، یک مجموعه فونت آیکون کامل مانند فونت اوسام یا گلیفیکون را در پروژه ای که مثلا از ایمیج اسپرایت یا SVG استفاده می کرده وارد کرده اند.

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

اولین بحث در این مورد سنگینی کد فریم ورک هاست، این مورد تا حد زیادی در قالب استفاده از فریم ورک های ماژولار برطرف شده است چرا که صرفا ماژول های مورد نیاز استفاده می شود نه تمام فریم ورک.

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

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

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

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

در تیم های بزرگ، معمولا برای جلوگیری از این اشکالات سرپرست تیم قوانینی را وضع می کند که هر کسی که در تیم هست یا جدید به آن وارد می شود موظف به رعایت آن است. این قاعده حتی هنگامی که توسعه دهنده بصورت انفرادی یا آزادکار (Free Lance) فعالیت می کند هم می تواند بسیار مفید باشد چرا که برطبق قانون و قاعده ای خاص حرکت کردن در ابتدا شاید هزینه بر باشد ولی به مرور می تواند علاوه بر پوشش دادن بسیاری از هزینه های خود صرفه جویی های بزرگی هم به ارمغان بیاورد.

انتخاب فریم ورک معمولا کاری است که در تیم ها یا براساس خرد جمعی انجام می شود یا سلیقه مدیر تیم که در اینجا موضوعیت ندارد، چراکه به قولی قانون بد بهتر از بی قانونی است. ولی در سایر موارد عموما انتخاب خیلی سخت نیست. بعضی از قوانین که در تیمها رعایت می شوند شاید درنگاه اول مضحک یا بیش از حد سخت گیرانه به نظر برسند، ولی در نهایت بسیار کمک خواهند کرد مثلا:

  • روش و قانونی برای نام گذاری ها،
  • ترتیب نوشتن تمامی اعلان(Declaration) های یک سلکتور در یک مجموعه قانون(Rule-Set) برمبنای حروف الفبا یا نوع کاربرد آنها، مثلا اول اعلانات مربوط دیسپلی، بعد اعلانات مربوط به اندازه، پوزیشن، رنگ، پس زمینه، فونت و در آخر اوپسیتی و انیمیشن و ....، در انتها هم درصورت نیاز زد ایندکس،
  • روش استفاده از ایندنتیشن و فاصله بین سلکتورها مثلا از تب استفاده شود یا از اسپیس، یا بین رول های مرتبط یک خط فاصله باشد وبین رولهای غیر مرتبط دو خط،
  • قوانینی برای کامنت گذاری در کد،
  • حداکثر میزان مجاز برای اسپسیفیسیتی،

اسپسیفیسیتی، همیشه در هنگام نوشتن کد مانند شمشیر دولبه است. توسعه دهنده اگر می خواهد مجبور به استفاده از !important و ID نشود باید مراقب این فاکتور باشد.

راه های متفاوتی برای استفاده و سواستفاده از اسپسیفیسیتی وجود دارد که در انتهای مقاله آدرس برخی از آن ها درج شده.

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

باید در تیم قوانین و دستور نگارشی کاملا مشخصی برای کامنت گذاری باشدزیرا در غیر این صورت وقت زیادی برای پرسیدن هدف کامنت از نویسنده آن تلف می گردد. زمانی که از پیش پردازنده ها استفاده می شود باید دقت نمود که کامنت هایی که از نگارش CSS استفاده می کنند(/**/) در استایل خروجی وجود خواهند داشت، که می توان از آنها برای امضا و امثال آن استفاده کرد و کامنت های خود پیش پردازنده در خروجی دیده نمی شوند، که برای دولوپمنت کارایی بیشتری دارند.

زمانی که فایلهای پارشال ساخته می شود، اگر طرح بخوبی تحلیل شده باشد، ساختار فایلی براحتی خود را پیدا کرده و مانند قطعات یک پازل کنار هم چیده می شوند. برای بیشتر نرم افزارهای تحت وب می توان از ساختار ماژولی برای ساخت پارشال ها استفاده کرد. البته که در بیشتر حالات آن چیزی که در CSS خالص بعنوان ماژول نام برده می شود، با آن تعریفی که در کل نرم افزار از ماژول است تفاوت دارد. چرا که در ساخت یک ماژول کاربردی (فانکشنال) که یک کاربرد یا وظیفه خاص در نرم افزار دارد(مانند ماژول ویجت ساید بار دریک وب سایت ورد پرسی، یا ماژول نوتیفیکیشن در یک نرم افزار تحت وب) گاهی از چند ماژول متفاوت CSS استفاده شده است.

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

هر چه تعداد فایلهای پارشال بیشتر باشد، بطور کلی میزان پیچیدگی هر فایل کم می شود و بالعکس هر چه فایل ها کمتر باشد میزان پیچیدگی و تعداد خط های هر فایل بیشتر می شود. البته معمولا این موضوع تاثیر زیادی در خروجی نهایی کار نخواهد داشت. این قانون در فایلهای پارشال HTML بیشتر صدق می کند، برای مثال، صفحه ای که بسته به نقش کاربر بین 3 تا 7 تب مختلف، بریدکرامب و محتوای هر تب را نمایش می دهد، می توان در یک فایل ساخت، که فایلی بزرگ با پیچیدگی و تعداد خط بالا به دست می دهد ولی اگر برای هرکدام از بخش های برید کرامب، تبها و محتوای تب ها یک فایل ساخته شده و همه آن فایلها در یک فایل لی اوت فراخوانی شوند، حداقل 10 فایل وجود خواهد داشت. البته باید توجه داشت که این امر هیچ تاثیری در بارگذاری صفحه سمت کاربر نخواهد داشت چرا که این فایل های پارشال برای ساخت صفحه توسط سرور استفاده می شود و خروجی نهایی به صورت یه صفحه به کاربر ارسال می شود، بنابراین نه درخواست اضافه ای بین کاربر و سرور رد و بدل می شود و نه پردازشی سمت کاربر نیاز است (البته مثل همیشه معمولا) ولی باید در نظر داشت که وقتی یک قالب تب در حال ساخت است، معمولا ساختار داخل تب ها هم یکسان یا دستکم شبیه به هم هستند و در صورت نیاز به تغییری کوچک در همه تبها، باید در 7-8 فایل مختلف این تغییر را اعمال نمود، نه در یک فایل، که این هزینه بر است. به علاوه تعداد فایل زیاد احتمال ایجاد اشتباه را هنگام اعمال تغییرات، بالا می برد. پس باید در مورد خورد کردن فایل های اصلی به فایل های پارشال دقت زیادی داشت و اثرات هزینه ای آن را در کل پروژه در نظر داشت، تحلیل و تفسیر این موضوع هم به مرور زمان و کسب تجربه راحت تر شده و نتایج بهتری در پیش بینی ها و بررسی ها به دست می دهد.

  • بهترین معماری ممکن

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

در ادامه تعدادی از مطرح ترین این الگو ها بر حسب ترتیب زمانی معرفی شدن نام برده شده اند.

  • OCSSO (Separate Structure and Skin, Separate Container and Content, Build HTML from Component Library)
  • SMACCSS (Base, Layout, Module, State, Theme)
  • BEM (Base, Element, Modifier)
  • ITCSS (Settings, Tools, Generic, Elements, Objects, Components, Trumps)
  • Suit CSS
  • Atomic Css

این الگوها که می توان گفت به تدریج یکدیگر را کامل کرده اند، نکات مشرک زیادی دارند که مهمترین آن ها عبارتند از:

  • تا حد امکان کد نویسی باید بصورت لایه ای باشد، بطور خلاصه یعنی بخشهای مربوط به ساختار، محتوا، پوسته ظاهری و ... باید مجزا و مستقل از هم وجود داشته باشند،
  • تا حد امکان باید از تکرار خودداری کرد و باصطلاح کد DRY باشد،
  • از دستورالعمل های رایج و تجربه شده در CSS مانند استفاده کمتر از آی دی یا عدم انتخاب مستقیم المنت استفاده شود،
  • جداسازی اهداف خیلی مهم است.

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

استفاده از کلاس های جراحی (Surgical Classes):

کلاس هایی که نام آن ها گویای هدف آن ها است:

.no-margin, .no-padding, .half-global-padding, .half-global-margin, …

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

کد نویسی برای حالت های دوسمتی(Bi-Directional):

زمانی که از فلوت استفاده می شود ترکیب دو حالت راست به چپ و بالعکس معمولا نیاز به استایل های جدا گانه دارد تا با حداقل تغییرات بتوان از همان HTML ها استفاده نمود ولی اگر بتوان بر سیستم فلکس باکس بخوبی مسلط شد، می توان دید که صرف کمی وقت و انرژی بیشتر می توان فقز با یک استایل و با تغییرات فوق العاده کم در HTML از یک استایل عمومی و بدون نیاز به اورراید برای هر دو سمت استفاده نمود. برای توضیح می توان یک جدول را مثل آورد که اگر چه ربطی به فلکس باکس ندارد ولی گویای منظور می باشد. هنگامی که جدولی در یک فایل چپ به راست قرار می گیرد متون از سمت چپ الاین شده و اولین td در هر ردیف نیز سمت چپ قرار دارد و هنگامی که این جدول در یک فایل راست به چپ قرار می گیرد بدون هیچ تغییری به صورت پیش فرض دقیقا برعکس این حالت است، همین در مورد فلکس باکس هم صادق است و می توان با هوشمندی از این امکان برای حداقل کردن اوررایدها استفاده نمود.

استفاده فراوان از سودوها:

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

جستجو و بررسی:

همیشه قبل از استفاده از هر چیزی در صورتی که حتی ذره ای در مورد آن شک وجود داشته باشد و یا تابحال از آن استفاده نشده باشد بدون هیچ خجالتی باید به سراغ منابع آنلاین رفت.

بهترن این گزینه ها هم برای همه شناخته شده اند.

Css-tricks.com - Smashingmagazine.com - Sitepoint.com – Mdn.com , …

در هر پروژه ای همیشه همه چیز مطابق میل پیش نمی رود. بنابراین گاهی توسعه دهنده مجبور می شود کارهایی انجام دهد که خلاف میل و عادت است و هیچ گاه هم نمی پسندد کسی متوجه آن شود، معمولا این کارها را در جایی قرار می دهد که 1- در انتهای همه فایل ها قرار داشته باشد که برای اورراید کردن سایر فایل ها مناسب باشد، 2- زیاد در معرض دید نباشد و معمولا نام آن را فایل شرم(Shame file) می گذارند. یکی از حقه های خیلی خوب تغییر نام این فایل به Misc-modules است که کاملا هم مرتبط و از هر جهت بهتر از نام شرم است. علل بسیاری باعث ایجاد این فایل می شود گاهی نیاز به استفاده از پلاگین هایی است که از استایل های خودش استفاده می کند و همیشه زمان برای بازنویسی این پلاگین ها یا حتی استایل آن ها مطابق میل و سلیقه یا نیاز پروژه نیست، بنابراین تنها کاری می توان کرد اورراید کردن استایل آنهاست، یا هنگامی که طراح ، طرحی را اجرا می کند که با هیچ کدام از ماژول های از پیش ساخته نمی توان آن را ساخت و تنها در یک بخش یا صفحه خاص دیده می شود، جایی است که باید دست به دامان این فایل شد، هرچه این فایل کوچکتر باشد بهتر و میزان شرمندگی توسعه دهنده هم کمتر است.

اما بازنویسی،

بازنویسی کاری زمان بر، آزار دهنده، شرم بار و در عین حال الزامی است. هیچ کسی نمی تواند ادعا کند که برای استایلی که نوشته نیاز به بازنویسی ندارد. هرچه پروژه بزرگتر وسیع تر و دارای بخشهای مجزای بیشتری باشد، نیاز به بازنویسی بیشتر احساس می شود.

معمولا در پروژه ها پس از بررسی و تحلیل اولیه طرح، تعداد زیادی از متغیر ها و میکسین های مورد نیاز را نوشته می شود ، تعدادی میکسین و فانکشن هم که بطور کلی در همه پروژه ها مشترک هستند(مانند کلیرفیکس ها یا فانکشن های تبدیل واحدها و ...)، سپس فایل های پارشال ساخته شده و نوشتن استایل های اصلی شروع می شود. هر جایی که نیاز به پلاگین خارجی باشد در فایل اصلی استایل بدون هیچ تغییری اضافه می شود، پس از اتمام کل ساختار پروژه، همه صفحه ها، ماژول ها و بخش های نرم افزار یک بار با دقت بررسی می شود، تمام ریزه کاری های باقی مانده مرور شده و لیست می شود، در اینجا هنگامی که ریزه کاری ها را انجام می شود، تعدادی کلاس های کمکی(جراحی، دقیق) به استایل ها اضافه می شود، سپس شروع به استفاده از آنها کرده و تا حد امکان فایل های HTML از استایلهای درون HTML(Inline) پاک می شوند.

در این مرحله بار دیگر سعی بر مشخص کردن ماژول ها و قوانین تکراری است که در صورت امکان تبدیل به ماژول و در غیر این صورت تبدیل به کلاس کمکی شوند.

در انتها جدا سازی اهداف به خوبی انجام شده و بار دیگر نیز استایل ها و فایل های HTML بررسی شده تا در صورتی که چیزی برای خلاصه کردن پیدا شد یا اشتباهی که در ظاهر کار تاثیری ندارد ولی هنگامی که فایل باز می شود، گیج کننده باشد، اصلاح گردد.

معمولا بعد از این مورد تا مدتی تغییری روی پروژه انجام نمی شود و پس از 1-2 ماه می توان به سراغ آن رفت. البته باز هم موارد زیادی برای اصلاح به چشم می خورد. حال اگر کار تیمی است، می توان بجای ایجاد فاصله زمانی بین بازنویسی ها، از افراد دیگر تیم برای بازنگری پروژه استفاده کرد.

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

بعلاوه یک توسعه دهنده خوب همیشه باید قانون پیشاهنگی در کد را رعایت کند. یعنی هر بار دست در بخشی از کد می برد، اگر هر اشکال یا امکانی برای بهتر کردن کد وجود دارد از آن نگذشته و آن را انجام دهد وهمیشه کد را تمیزتر از آنچه بوده ترک کند.

لینکها و منابع:

http://www.slideshare.net/stubbornella/object-oriented-css/

https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

http://www.slideshare.net/stubbornella/css-bloat

https://www.sitepoint.com/css-architectures-scalable-and-modular-approaches/

https://smacss.com/

https://css-tricks.com/bem-101/

http://acss.io/

http://www.creativebloq.com/css3/atomic-css-11619006

https://www.lucidchart.com/techblog/2014/01/31/atomic-css-tool-set/

http://www.creativebloq.com/web-design/manage-large-css-projects-itcss-101517528

https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

http://www.creativebloq.com/web-design/manage-large-scale-web-projects-new-css-architecture-itcss-41514731

https://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/

https://www.sitepoint.com/atomic-oobemitscss/

https://www.safaribooksonline.com/library/view/developing-large-web/9781449380090/ch04.html

https://speakerdeck.com/csswizardry/css-for-software-engineers-for-css-developers

http://csswizardry.com/2015/03/immutable-css/

http://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/

https://css-tricks.com/strategies-keeping-css-specificity-low/

http://csswizardry.com/2014/10/the-specificity-graph/

https://github.com/giakki/uncss