Clean Code
مقدمه
اگر اصول Clean Code را در توسعه فرانتاند رعایت نکنیم، با چالشهای جدی و متعددی روبرو خواهیم شد. این چالشها میتوانند شامل کد پیچیده و غیرقابل خواندن، دشواری در نگهداری و بهروزرسانی، افزایش زمان و هزینهی رفع اشکال، و مشکلات در همکاری تیمی باشند. در نتیجه، پروژهها با تأخیر مواجه شده، کیفیت محصول نهایی کاهش یافته و هزینههای توسعه به طور قابل توجهی افزایش مییابد. همچنین، عدم رعایت این اصول میتواند منجر به ایجاد بدهی فنی شود که در طول زمان انباشته شده و مدیریت پروژه را دشوارتر میکند.
برای جلوگیری از این مشکلات، رعایت اصول Clean Code در فرانتاند ضروری است. این اصول به ایجاد کدی خوانا، قابل نگهداری و قابل توسعه کمک میکنند که برای تیمهای توسعه بسیار حیاتی است. با پیروی از این اصول، توسعهدهندگان میتوانند کدی بنویسند که به راحتی توسط سایر اعضای تیم قابل درک و ویرایش باشد. این امر باعث کاهش زمان و هزینههای مربوط به رفع اشکال، بهبود و توسعه پروژه در آینده میشود. همچنین، کد تمیز به بهبود عملکرد و کارایی برنامه کمک میکند، زیرا ساختار بهینه و منطقی کد، اجرای سریعتر و کارآمدتر را تضمین میکند.
- نوشتن کد تمیز چه مزایایی دارد؟
- از چه اصول و از چه تکنیکهایی برای دستیابی به کد تمیز میتوان استفاده کرد؟
- کد تمیز به طور خاص در فرانتاند دارای چه ویژگیهایی است؟
یادگیری
Clean Code
شاید برای شما هم پیش آمده باشد که بعد از چند ماه به پروژهای که خودتان آن را توسعه دادهاید سر بزنید و احساس کنید تقریباً هیچچیز از آن متوجه نمیشوید. زمانی که بر روی پروژهای کوچک، به صورت انفرادی کار میکنید شاید هیچوقت به اهمیت کد تمیز پی نبرید؛ اما اگر همین پروژه، در آینده احتیاج به توسعه داشته باشید یا اگر به همراه یک تیم بر روی آن کار کنید، بدونِ داشتنِ کد تمیز، محکوم به شکست خواهید بود.
برای آشنایی بیشتر با این مفهوم میتوانید از لینکهای زیر استفاده کنید:
Code Smells
یکی از راههای افزایش کیفیت کد، پیدا کردن نشانههای کد کثیف و بازنویسی آنهاست. به این نشانهها Code Smell میگوییم.
برای آشنایی بیشتر با این مفهوم میتوانید از لینک زیر استفاده کنید:
S.O.L.I.D
یکی از مهمترین مجموعه اصول در برنامهنویسی، اصول پنجگانهٔ SOLID میباشد که عبارت است از:
- Single Responsibility
- Open for Extension/Closed for Modification
- Liskov Substitution
- Interface Segregation
- Dependency Inversion
برای آشنایی بیشتر با این مفهوم میتوانید از لینکهای زیر استفاده کنید:
- Medium - S.O.L.I.D in TypeScript
- Medium - SOLID Principles in TypeScript
- Medium - Brutally SOLID Typescript
Refactoring Techniques
با گذشت زمان و کسب تجربه توسط توسعهدهندگان، مجموعهای از تکنیکها برای تمیزسازی کد فراهم شده که تقریباً برای تمام نیازهای شما راهحل دارد. پیشنهاد میکنیم فعلاً به صورت روزنامهوار توضیحات هر تکنیک را مطالعه کنید و فقط زمانی که به آن احتیاج پیدا کردید، آن را به طور کامل بخوانید.
برای آشنایی بیشتر با این مفهوم میتوانید از لینک زیر استفاده کنید:
Open-Source
README.md
فایل
README.md
معرفینامۀ پروژۀ شماست.
تمام مواردی که یک کاربر بیرونی احتیاج دارد در مورد پروژه بداند
باید در این فایل آورده شوند یا حداقل به جایی که در مورد آنها توضیح داده شده است،
اشاره شود.
پیشنهاد میکنیم موارد زیر را حتماً در این فایل بیاورید:
- نام پروژه
- لوگو شخص، تیم یا شرکت
- لینک به سایت اصلی پروژه
- وضعیت CI/CD، بالا بودن سرورها، پاسشدن تستها و موارد مشابه
- توضیحی چند خطی و کوتاه در مورد کاربرد پروژه
- اهداف پروژه و نیازهایی که میتواند برطرف کند
- پیشنیازهای استفاده از پروژه
- لینک دانلود فایل نهایی/اجرایی پروژه
- باگهای احتمالی و مواردی که کاربر باید به آنها توجه کند
- قابلیتهای فعلی و نحوۀ استفاده از آنها
- مستندات کامل یا لینک به جایی که آنها را قرار دادهاید
- برنامههای آینده و قابلیتهایی که میخواهید به پروژه اضافه کنید
- شرایط پشتیبانی و نحوۀ ثبت درخواست
- توضیح اجمالی، دعوت به مشارکت و لینک به
CONTRIBUTING.md
- لینک به صفحات پروژه در شبکههای اجتماعی
- معرفی اجمالی توسعهدهندگان پروژه و لینک به صفحات مرتبط آنها در شبکههای اجتماعی
CONTRIBUTING.md
در دنیای
Open-Source
، آدمهای زیادی پیدا میشوند که به طور رایگان بخواهند به شما کمک کنند؛
بنابراین شما باید با فراهمکردن فایل
CONTRIBUTING.md
مناسب، آنها را در این راه یاری کنید.
پیشنهاد میکنیم موارد زیر را حتماً در این فایل بیاورید:
- پیشنهاد برای چککردن لیست Issue های فعلی و جلوگیری از ثبت Issue تکراری
- لیست قابلیتهایی که دوست دارید توسط دیگران به پروژه اضافه شوند
- لیست قابلیتهایی که دوست ندارید به پروژه اضافه شوند
- لیست باگهایی که دوست دارید توسط دیگران حل شوند
- لیست باگهایی که از وجود آنها باخبرید اما قصد برطرفکردن آنها را ندارید
- مراحل ثبت باگ، درخواست امکانات جدید، ارتبا ط با توسعهدهندگان و موارد مشابه
- پیشنیازهای راهاندازی پروژه بر روی سیستم شخص
- نحوۀ Clone کردن و راهاندازی پروژه به صورت خط به خط با بیشترین جزئیات ممکن
- قوانین کدنویسی که در پروژه رعایت میکنید
- قواعد نوشتن Commit Message
IDE
استفاده از Text Editor هایی مانند VS Code فقط برای پروژههای کوچک مناسب است. برای پروژههای بزرگ، مخصوصاً پروژههایی که به صورت تیمی آنها را توسعه میدهید، حتماً از WebStorm استفاده کنید.
ESLint
برای فعالکردن تنظیمات ESLint از لینک زیر استفاده کنید:
Prettier
برای فعالکردن تنظیمات Prettier از لینک زیر استفاده کنید:
Stylelint
معمولاً هر شخص زمانی که کد CSS مینویسد، برای آن قواعدی در نظر میگیرد؛ بهعنوان مثال ترتیب و اولویت Property های مختلف یا استفاده از یک فرمت رنگ خاص. اما زمانی که به صورت تیمی بر روی پروژهای کار میکنید، بهتر است این قواعد به صورت عمومی اعمال شوند تا کدی که در نهایت نوشته میشود برای همه قابلفهم و در یک چارچوب باشد. Stylelint ابزاری است که به ما امکان تعریف چنین قواعدی را میدهد.
برای آشنایی بیشتر با StyleLint از لینکهای زیر استفاده کنید:
General
Download Size
گاهی اوقات مشاهده میشود که بعضی از توسعهدهندگان از فایلهای حجیمی در پروژۀ خود استفاده میکنند که نهتنها مزیت خاصی ندارند، بکله باعث کند شدن سایت میشوند و حجم زیادی از اینترنت کاربر را اشغال میکنند.
پیشنهاد میکنیم برای ک اهش حجم عکسها از سایت
Squoosh
استفاده کنید.
همچنین به طور کلی حجم فایلهای
svg
از فرمتهای دیگر کمتر است،
بنابراین سعی کنید تا جای ممکن از این فرمت استفاده کنید.
در صورتی که عکس شما به صورت
Raster
بود و امکان استفاده از
svg
را نداشتید، پیشنهاد ما فرمت
webp
میباشد.
به طور کلی توصیه میکنیم تا جای ممکن از ویدئو استفاده نکنید.
Comment
زمانی که در حال توسعۀ پروژه هستید، ممکن است بخواهید بهطور موقت قسمتی از کد را کامنت کنید؛
این مورد به تنهایی مشکلی ندارد اما زمانی که خواستید کد را بر روی نسخۀ
master
یا main
ببرید،
حتماً کامنتهای اضافی را پاک کنید.
همچنین به طور کلی زمانی که مجبور شدید برای توضیح قسمتی از کد، از کامنت استفاده کنید،
احتمالاً کدی که نوشتید تمیز نیست؛ سعی کنید همیشه کدی بنویسید که بدونِ نیاز به توضیحات، قابلفهم باشد.
Unicode Characters
بعضاً مشاهده میشود که توسعهدهندگان برای نمایش اعداد فارسی از ک اراکترهای
۰۱۲۳۴۵۶۷۸۹
استفاده میکنند؛
ما پیشنهاد میکنیم بههیچوجه چنین کاری نکنید؛
در عوض از فونتی استفاده کنید که کاراکترهای
0123456789
را به شکل درست نمایش دهد.
CSS
Reset
مرورگرهای مختلف، استایلهای پیشفرض متفاوتی برای المانهای مختلف دارند که این موضوع باعث بروز مشکلات متعددی در روند توسعه میشود؛ بهعنوان مثال ممکن است ظاهر سایت شما در یک مرورگر خاص دقیقاً همانطور باشد که میخواهید اما در یک مرورگر دیگر کاملاً بههمریخته باشد.
برای حل این مشکل Reset های متعددی وجود دارد اما ما در اینجا از سادهترین آنها استفاده میکنیم:
*,
*::before,
*::after {
box-sizing: border-box;
margin: 0;
padding: 0;
}
BEM
یکی از معروفترین و محبوبترین متدولوژیهای موجود که در نامگذاری المانها استفاده میشود، BEM است. با استفاده از این متدولوژی میتوانید صرفاً با نگاهکردن به اسم یک المان، ساختاری که در آن قرار دارد را متوجه شوید. همچنین از آنجایی که برای هر المان از یک کلاس مشخص استفاده میکنید، به مشکلات مربوط به Specificity برنخواهید خورد.
استفاده از
BEM
در
SCSS
بسیار راحت است:
.card {
&__header {
&__icon {
// ...
}
&__title {
// ...
}
}
&--primay {
// ...
}
}
برای آشنایی بیشتر با این مفهوم میتوانید از لینکهای زیر استفاده کنید:
Color Syntax
در CSS به طور کلی از 4 روش مختلف میتوان رنگ یک المان را تعیین کرد که در ادامه به مقایسۀ آنها میپردازیم.
Names
شاید به نظر برسد بهترین راه برای مشخصکردن یک رنگ، استفاده از اسم آن است.
برای رنگهایی که به طور معمول با آنها سروکار داریم و اسم آنها را میدانیم،
این قضیه صادق است؛
اما
CSS
دارای بیش از 100 رنگ است که تعداد زیادی از آنها برای توسعهدهندگان،
به خصوص کسانی که زبان مادری آنها انگلیسی نیست،
ناآشنا هستند.
از طرفی حتی در مورد رنگهایی که اسم آنها را میدانیم،
نمیتوانیم به طور دقیق میزان پُررنگ یا کمرنگبودن آنها را تشخیص دهیم.
بهعنوان مثال تفاوت رنگهای
pink
و
lightpink
در چیست؟
یا کدامیک از رنگهای
hotpink
و
deeppink
پُررنگتر است؟
البته این نوع رنگها کاملاً هم بلااستفاده نیستند، بلکه بعضاً برای زمانی که صرفاً بهدنبال تستکردن پروژه یا شناسایی باگ هستید، بهترین گزینهاند.
HEX
این فرمت از سه عدد در مبنای 16 تشکیل شده است؛ آیا برای اثبات نابهینهبودن این فرمت احتیاج به توضیح بیشتری هست؟ جدای از آنکه تشخیص یک عدد مبنای 16 و محاسبه ذهنی برای تبدیل آن به مبنای 10 کاری دشوار است، این فرمت دارای مشکل بزرگ دیگری است که در قسمت RGB به آن اشاره میکنیم.