چگونه طراحان كدنويسي را ياد بگيرند؟ ‌Git ،HTML/CSS، قواعد مهندسي - بخش دوم

در قسمت اول، Paul اصول ترمینال را توضیح داد، چند میانبر موثر را برای شروع كارتان و نحوه انتخاب یك ویرایشگر كد را به اشتراك گذاشت. در این قسمت او كار خود را با موضوعات كنترل نسخه Git، HTML و CSS، كدهای معنا یا Semantic و مقدمه‌ای خلاصه به چند قانون مهندسی كلیدواژه ادامه می‌دهد.

Tomes، به معنای واقعی درمورد كنترل نسخه، مقاله نوشته است. با این اوصاف، من با به اشتراك گذاشتن توضیحی مختصر و یك محتوای مقدمه‌ای دیگر جهت برانگیختن اشتهایتان برای تحقیق بیشتر شروع می‌كنم.

كنترل نسخه (برای اینكه با تاریخچه نسخه اشتباه گرفته نشود) اصولا روشی برای مردم جهت همكاری و تعامل در محیط خودشان بر روی یك پروژه با یك منبع اصلی شامل حقایق (معمولا به اسم شاخه "اصلی" شناخته می‌شود) است.

من حداقل مواردی را كه باید بدانید جهت دانلود یك پروژه، ایجاد تغییر، و فرستادن آن به مستر یا سرور ذكر خواهم كرد.

انواع زیادی نر‌م‌افزارهای كنترل نسخه و تعداد زیادی برای مدیریت و هاست كردن كدهای منبع خودتان وجود دارد.  Git وGitHub یكی از معمول‌ترین جفت‌هایی است كه استفاده می‌شود، مثال‌های من به GitHub ارجاع داده می‌شوند اما این قواعد درمورد بسیاری از دیگر مدیریت‌كننده‌های كد منبع نیز صدق می‌كنند. 

اولین همكاری و تعامل‌تان

قبل از انجام قدم‌های زیر، شما باید چند كار را انجام دهید:

1. یك حساب كاربری GitHub

2. نصب Node و  NPM بر روی كامپیوترتان

3. داشتن تحمل بالایی در برابر درد و آستانه تحمل كمی برای درخواست كمك

قدم 1: Fork یا فراخوان سیستمی (گرفتن كپی از كد بر روی حساب گیت‌هاب‌تان)

بر روی گیت‌هاب، (repository (repo را در سوال fork ( فورک= ایجاد یك كپی از كدهای اكانت‌تان، در تصویر زیر، خط‌های آبی، نارنجی، قرمز و سبز نشان‌دهنده fork هستند) بگیرید.

با ساختن شاخه‌هایی از سرور، این امكان فراهم می‌شود كه چندین نفر بر روی قسمت‌های مختلفی از پروژه همكاری كنند و كارهایشان را با یك‌دیگر ادغام كنند.

شما می‌توانید این كار را با رفتن به repo در GitHub و سپس كلیك برروی دكمه "Fork"، كه اكنون در بالای گوشه سمت راست repo قرار دارد، انجام دهید. این "‌origin" فورك شما بر روی حساب كاربری گیت‌هاب خواهد بود.

به عنوان مثال،با رفتن به https://github.com/yourGitHubUsername/liferay.design باید fork شما Liferay.Design repo را نشان دهد.

این fork گیت‌هاب victorvalle است

قدم 2: clone كردن (دانلود كردن كد به كامپیوترتان)

در ترمینال‌تان، به جایی كه می‌خواهید كد را در آن ذخیره كنید بروید. به شخصه یك فولدر /github در فولدر /user خودم دارم – این كار دسته‌بندی و نظم بخشیدن به آن را برایم راحت‌تر می‌كند. اگر می‌خواهید این كار را انجام دهید، باید به ترتیب پیش رو عمل كنید – پس از تایپ این دستور‌ها در پنجره ترمینال‌تان، كلید ↵ را فشار دهید تا اجرا شود:

cd ~/             ## you'll usually start in your root directory, but just in case
 you don't this will take you there
mkdir github      ## this creates a "github" folder — on OSX it will now be
 located at users/your-username/github
cd github         ## this command navigates you inside the github folder

اكنون كه در فولدر /github هستید، شما repo را clone (دانلود یك كپی از كد به كامپیوتر) كنید.

clone https://github.com/yourGitHubUsername/liferay.design

زمانی كه این دستور را وارد كردید، چند فعالیت تقریبا مشابه به صورت زیر در ترمینال خواهید دید:

Cloning into 'liferay.design'...
remote: Enumerating objects: 380, done.
remote: Total 380 (delta 0), reused 0 (delta 0), pack-reused 380
Receiving objects: 100% (380/380), 789.24 KiB | 2.78 MiB/s, done.
Resolving deltas: 100% (189/189), done.

قدم 3: نصب (آن را بر روی ماشین خود راه‌اندازی كنید)

به فولدر /project بروید. در این مورد، ما cd liferay.design را وارد خواهیم كرد. بیشتر پروژه‌ها شامل یك فایل README.md در فولدر /root هستند، اینجا اصولا نقطه شروع برای نصب و اجرای پروژه است. برای مقصود ما، برای نصب، npm install را وارد كنید. زمانی كه نصب شد، npm run dev را وارد كنید.

تبریك می‌گویم! اكنون سایت را در كامپیوتر خود در اختیار دارید – اصولا پروژه‌ها به شما می‌گویند كه در كجا اجرا می‌شود. در این مورد، مرورگر را باز كنید و به localhost:7777 بروید.

قدم 4: Commit (چند تغییر ایجاد كنید و آن‌ها را ذخیره كنید)

Commit كلكسیونی از تغییراتی كه شما ایجاد می‌كنید است؛ من شنیده‌ام كه آن را مانند ذخیره پیشرفت و مرحله در بازی توصیف می‌كنند. درمورد این كه commit به چه صورت باید ساختاربندی شود، نظرهای زیادی وجود دارد: نظر من این است كه زمانی كه به یك مورد دست یافتید باید یك commit بسازید، و اگر خواستید commit را حذف كنید، به طور كامل به پروژه (بر اساس منطق) آسیب نمی‌زند.

اگر شما نظرتان تغییر كرد و به repo نمی‌روید، محل مناسب دیگر تب “Issues” است. در اینجا است كه می‌توانید ببینید در پروژه باید چه كارهایی انجام دهید.

اگر برای ایجاد تغییرات ایده‌های دیگری نیز دارید، پیش بروید و آن‌ها را ایجاد كنید. زمانی كه فایل‌(ها) را ذخیره كردید، از قدم‌های زیر جهت ساخت یك commit استفاده كنید:

git status                                        
 ## this will print out a list of files that you've made changes in
git add path/to/folder/or/file.ext                 
## this will add the file or folder to the commit
git commit -m 'Summarize the changes you've made'  
## this command creates a commit and a commit message

نكته: بهترین توصیه‌ای كه من درمورد commit دیده‌ام از Chris Breams در مقاله "چگونه یك پیغام گیت commit بنویسیم" بوده است. یك خط موضوع commit گیت مناسب باید همیشه بتواند جمله پیش رو را كامل كند: "اگر اجرا شود، این commit [خط موضوع شما در اینجا قرار می‌گیرد] انجام خواهد داد." یا “[If applied, this commit will [your subject line here.”  برای اطلاعات بیشتر مقاله "چرا باید commitهای اتومیك در گیت بسازم؟" از Clarice Bouwer را بخوانید.

قدم 5: Push (فرستادن تغییرات‌تان به origin خودتان)

زمانی كه شما تغییراتی بر روی كامپیوترتان اعمال می‌كنید، قبل از اینكه بتوان آن‌ها را با شاخه اصلی سرور ادغام كرد (به پروژه اضافه كرد)، باید از كامپیوتر خودتان آن را به repo از راه دور خود منتقل كنید. برای انجام این كار، git push origin را در خط دستوری خود وارد كنید.

قدم 6: درخواست Pull یا Pull Request (درخواست كنید تغییرات را با Upstream ادغام شود)

اكنون كه تغییرات شما از انگشتانتان به كامپیوترتان و سپس به repository از راه دورتان منتقل شده است – زمان این رسیده است كه بخواهید تغییرات شما از طریق یك Pull Request یا PR با پروژه ادغام شود.

ساده‌ترین روش برای انجام این كار این است كه شما به صفحه repo خودتان در گیت‌هاب بروید. در بالای پنجره فایل پیغام كوچكی خواهد بود كه می‌گوید “This branch is X commits ahead repo-name:branch” و سپس گزینه‌های  “Pull Request” و “Compare” دیده می‌شود.

در اینجا كلیك بر روی گزینه “Pull Request” شما را به صفحه‌ای می‌برد كه می‌توانید تغییرات را مقایسه كنید و سپس گزینه‌ای به نام “Create Pull Request” شما را به یك صفحه “Open a Pull Request”، جایی كه در آن یك عنوان و نظر و توضیحات را به آن اضافه می‌كنید، خواهد برد. خلاصه‌نویسی اما اشاره به جزئیات به اندازه كافی در بخش توضیحات و نظر، به مسئولین پروژه كمك می‌كند تغییرات پیشنهادی شما را درك كنند.

ابزارهای CLI مانند Node GH (همچنین گیت‌هاب اخیرا یك نسخه بتا از ابزار CLI خود عرضه كرده است.) وجود دارند كه به شما امكان آغاز و مدیریت Pull Requestها در ترمینال را می‌دهد. در این مرحله شما ممكن است ترجیح دهید از اینترفیس‌های وب استفاده كنید، و این كار عالی است! من نیز همین كار را انجام می‌دهم.

گزینه‌های ‘Pull Request’ و ‘Compare’ زمانی كه fork شما از repoی upstream جدا می‌شود، ظاهر می‌شود.

قدم اضافه : Remote (لینك كردن تمام repoها)

در این مرحله، ما سه مرجع repository داریم:

1. upstream: repoی اصلی كه آن را پیگیری می‌كنید، معمولا repoیی است كه آن را fork كرده‌اید

2. origin: اسم پیش‌فرض ریموتی كه clone كرده‌اید

3. local: كدی كه اكنون بر روی كامپیوترتان قرار دارد

تا اینحا شما شماره دو و شماره سه را دارید – اما شماره یك مهم است زیرا منبع اولیه است. موازی قرار دادن این موارد در كنار هم به تمیز باقی ماندن تاریخچه repo كمك می‌كند. این امر به مسئولین پروژه كمك می‌كند چرا كه مشكلاتی كه طی ادغام هنگامی كه pull request PRها را می‌فرستید، رخ می‌دهد را حذف (و یا به حداقل) می‌رساند و به شما كمك می‌كند آخرین كدها را داشته باشید و repositoryهای local و origin را به‌روز نگهدارید.

یك ریموت Upstream تنظیم كنید

برای ردگیری یك ریموت upstream، باید در ترمینال خود موارد زیر را وارد كنید:

git remote add upstream https://github.com/liferay-design/liferay.design

اكنون، بررسی كنید ببینید چه ریموت‌هایی در دسترس دارید – اگر  git remote -v را در ترمینال خود وارد كنید، باید چیزی بدین صورت مشاهده كنید

origin و upstream معمول‌ترین برچسب‌ها برای ریموت‌ها هستند – "origin" فورك شما است و " upstream" منبع.

origin   https://github.com/yourGitHubUsername/liferay.design (fetch)
origin    https://github.com/yourGitHubUsername/liferay.design (push)
upstream  https://github.com/liferay-design/liferay.design (fetch)
upstream  https://github.com/liferay-design/liferay.design (push)

این كار به شما این امكان را می‌دهد تا به سرعت به آخرین نسخه از آن‌چه كه upstream است، دست یابید. اگر شما مدت‌ها است كه در یك repo كار نكرده‌اید و هیچ تغییر localی ندارید كه برای حفظ آن تمایلی داشته باشید، این دستوری است كه من از آن استفاده می‌كنم:

git pull upstream master && git reset --hard upstream/master

بخش كمك گیت‌هاب منبعی عالی در این باره بوده است و سوال‌های زیاد دیگری كه ممكن است برایتان پیش بیاید را پاسخ می‌دهد. 

 HTML و CSS :نوشتن كدهای معنادار

در وب، منبع بی پایانی از منابع برای یادگیری HTML و CSS وجود دارد. برای مقصود این مقاله، من چیزی را كه بر اساس اشتباهاتی كه مرتكب شدم چگونه اولین بار شروع به نوشتن HTML و CSS كردم، به اشتراك می‌گذارم. 

HTML و CSS چه هستند؟

قبل از اینكه پیش برویم، بیایید HTML و CSS را تعریف كنیم. 

HTML مخفف زبان نشانه‌گذاری هایپرتكست یا HyperText Markup Language است.

Hypertext:

"Hypertext متنی است كه بر روی نمایش كامپیوتر یا computer display یا سایر دستگاه‌های الكترونیك دارای مرجع (هایپرلینك) به متن دیگری كه خواننده می‌تواند سریعا به آن دسترسی یابد، نمایش داده می‌شود"

“Hypertexr” در ویكی‌پدیا

زبان نشانه‌‌گذاری:

"سیستمی برای حاشیه‌نویسی اطلاعات به روشی كه به صورت نحوی از متن قابل تمایز است."

"زبان نشانه‌گذاری" در ویكی‌پدیا

در صورتی كه شما نیز نمی‌دانید بسیاری از كلمات بالا به چه معنی هستند؛ اگر به صورت خلاصه توضیح دهم، HTML تركیبی از مرجع‌ها (لینك‌‌ها) بین اطلاعات وب، و تگ‌هایی كه از آن‌ها جهت ساختار دادن به این اطلاعات استفاده می‌كنید، است.

 یك تگ HTML5 برای تقریبا هر عنصر پایه‌ای وجود دارد؛ در غیر این صورت شما همیشه می‌توانید از یك div استفاده كنید!

برای یك مقدمه‌ی كامل به HTML و CSS من مقاله‌های مقدمه‌ای به HTML و قدم‌های اولیه CSS كه هر دو بر روی اطلاعات وب Mozilla Developer MDN قرار دارند را توصیه می‌كنم. این مقالات به همراه سایر مقالات خوب دیگری مانند CSS Tricks، 24 Ways و بی‌شمار مقاله دیگر، شامل تقریبا هرچه كه به آن برای ارجاع به HTML/CSS نیاز خواهید داشت، است.

دو قسمت اصلي براي اطلاعات HTML وجود دارد: <head> و <body> . قسمت <head> شامل مواردي – متاداده‌ها و لينك‌هايي كه جهت انتقال استايل‌شيت‌ها و متون استفاده مي‌شوند – است كه توسط مرورگر نمايش داده نمي‌شود، و قسمت <body> شامل محتواي واقعي كه توسط مرورگر رندر مي‌شود مي‌باشد. جهت رندر كردن محتوا، مرورگر HTML را مي‌خواند، و لايه‌اي پايه‌اي بر اساس استايل‌ها، بسته بر انواع تگ‌هايي كه استفاده شده است، فراهم مي‌كند، لايه‌هاي اضافه‌ي استايل‌ كه خود وبسايت آن را فراهم مي‌كند را مي‌افزايد (استايل‌ها مشمول/ارجاع به <head> دارند يا inline هستند)، و اين چيزي است كه در نهايت مي‌بينيم. (نكته: معمولا لايه اضافه جاوااسكريپت نيز وجود دارد اما خارج از حيطه اين مقاله است.)

 CSS مخفف Style Sheet‌های آبشاری یا Cascading Style Sheets است؛ كه از آن برای گسترش و توسعه HTML از طریق ساده‌سازی آن به كمك ایجاد ظاهر و احساسی شخصی سازی شده استفاده می‌شود. یك Style Sheet اطلاعاتی است كه بر اساس قانون‌گذاری بر پایه تگ‌ها، كلاس‌ها، آی‌دی‌ها و سایر انتخاب كننده‌ها به HTML می‌گوید عناصر باید به چه صورتی باشند (و به چه صورتی قرار بگیرند). Cascading به روشی جهت مشخص كردن این امر كه كدام قوانین در یك شیت و صفحه در جدال اجتناب‌ناپذیر بین قوانین اولویت دارند، گفته می‌شود.

" Cascading به این معنی است كه استایل‌ها می‌توانند از یك Style Sheet به دیگری تغییر كنند (یا آبشاری باشند)، و چندین Style Sheet را برای استفاده بر روی یك اطلاعات HTML فعال كند."

Cascade – Max Design

در عوض، یادگیری اصول انتخاب كننده‌ها، وراثت، مدل جعبه‌ای و از همه مهم‌تر، نحوه دیباگ كردن كد CSSتان (راهنمایی: شما به ابزارهای توسعه‌دهندگان مرورگر نیاز خواهید داشت) بسیار حیاتی‌تر است.

درمود حفظ كردن نحوها براي ويژگي‌هاي پس‌زمينه يا background و فراموش كردن نحوه دقيق هم‌تراز كردن موارد در Flexbox نگران نباشيد؛ گوگل و Stack Overflow زماني كه پاي مقادير و ويژگي‌هاي CSS در ميان باشد از دوستان شما هستند.

بعضی از ویرایشگرهای كد حتی درون خودشان تكمیل كننده خودكار یا autocomplete دارند و شما حتی نیاز ندارید به عنوان مثال در وب تمامی ویژگی‌های ممكن یك محدوده را بیابید.

یكی از ویژگی‌های جدید مورد علاقه‌ من در Firefox 70 نشانگر قوانین CSS غیرفعال است. این مساله ساعت‌ها زمانی كه صرف یافتن جواب سوال چرا یك استایل پیاده نمی‌شود را برایتان ذخیره می‌كند. 

این روزها همه چیز در دسترس بچه‌ها است!

كدهای معنادار یا Semantic

بیایید با كدهای معنادار شروع كنیم. معنا به مفهوم كلمات اشاره دارد، كدهای معنادار به این ایده باز می‌گردد كه برای هر نشانه‌ای در هر زبانی، معنایی وجود دارد.

كدهای معنادار مزیت‌های زیادی به شما می‌دهند:

1. استایل‌های پیش‌فرض

به عنوان مثال استفاده از یك تگ عنوان <h1> برای عنوان اطلاعات‌تان باعث می‌شود نسبت به محتوای سایر اطلاعات، درست مانند ویژگی یك عنوان، برجسته‌تر باشد.

2. محتوای در دسترس

كد شما به صورت پیش‌فرض در دسترس خواهد بود كه به این معنا است، با screen reader کار می‌کند و راهبری با کیبورد راحت‌تر خواهد بود.

3. مزایای سئو

خواندن نشانه‌گذاری معنادار برای ماشین‌ها و كامپیوتر راحت‌تر است، كه باعث می‌شود بیشتر در دسترس موتورهای جست و جو قرار گیرد.

4. مزایای عملكردی

HTML تمیز پایه سایتی با عملكرد بالا است. و HTML تمیز احتمالا به یك CSS تمیزتر منجر می‌شود كه به معنی استفاده كلی از كدهای كمتر است و باعث می‌شود سایت یا اپ شما سریع‌تر باشد.

نكته: برای نگاهی عمیق‌تر به كدهای معنادار و HTML، من به شدت خواندن مقاله "كدهای معنادار ساختاری: اهمیت عناصر قسمت‌بندی HTML5" از Heydon Pickering را توصیه می‌كنم.

قوانین مهندسی و پارادیم‌ها: اصول

انتزاع یا مفهوم

هزاران‌ برنامه، تانژانت و سطوح وجود دارد كه می‌توان در سطح مفاهیم انتزاعی آن‌ها را جست و جو و كشف كرد. 

مفهوم یك پارادیم مهندسی پایه‌ای با تنوع گسترده‌ای از برنامه‌ها است. ما این مساله را در سه قسمت پیاده‌سازی می‌كنیم: token‌ها، مولفه‌ها و قاعده Don’t Repeat Yourself.

token‌ها

اگر یك ابزار طراحی مدرن را مدت زمانی استفاده كرده باشید، احتمالا با ایده token رو به رو شده‌اید. حتی فوتوشاپ و ایلاستریتورها نیز این ایده مجموعه متمركز از استایل‌های به اشتراك‌گذاری شده را دارند. اگر با مفهوم متغیرهای CSS یا SASS آشنا باشید پس از قبل با token‌ها آشنایی دارید.

يك لايه مفهومي به همراه توكن‌ها براي اختصاص دادن يك اسم – به عنوان مثال $blue-00 را مي‌توان به يك مقدار hex (يا مقدار HSL يا هرچيز ديگري كه خودتان بخواهيد) ارجاع داد –  به رنگ‌ها به عنوان مثال #0B5FFF است. اكنون به جاي استفاده از مقادير hex در استايل‌شيت‌تان شما از مقادير token خود استفاده مي‌كنيد – اينگونه اگر تصميم گرفتيد كه blue-00 در واقع #0B36CE است، پس تنها بايد آن را در يك محل تغيير دهيد. اين مفهوم خوبي است.

اگر شما همین پارادیم مفهوم را قبول كنید و لایه‌ای جلوتر بروید، می‌توانید token‌ها را رمزنگاری كنید و یك متغیر را به یك مقدار عملكردی نسبت دهید. این‌كار مخصوصا زمانی كه یك سیستم قدرتمند دارید و می‌خواهید قالب‌های مختلف را درون سیستم داشته باشید، مفید است. یك مثال كاربردی از این موضوع مرتبط كردن متغییری مانند $primary-color و نگاشتی به $blue-00 است؛ اكنون می‌توانید نشانه‌گذاری بسازید و در عوض به جای رجوع به آبی به یك متغییر عملكردی رجوع می كنید. اگر زمانی خواستید از همان نشانه‌گذاری استفاده كنید اما با استایل یا قالبی متفاوت، پس شما تنها باید $primary-color را به یك رنگ جدید نگاشت كنید و نشانه‌گذاری شما لزومی ندارد اصلا تغییر كند! به این می‌گویند جادو!

مولفه‌ها

در سه چهار سال گذشته، تفكر مولفه‌ها و مولفه‌سازی بیشتر به طراحان مرتبط شده و در دسترس‌شان قرار گرفته است. مفهوم نمادها (با پیشروی Macromedia/Adobe Fireworks، سپس توسعه داده شده توسط Sketch و درنهایت ارتقاء سطح آن توسط Figma و Framer) اكنون به صورت گسترده‌تری در بیشتر ابزارهای طراحی (Adobe XD, InVission Studio, Webflow و بسیاری دیگر) در دسترس است. 

مولفه‌سازی، حتی بیشتر از token‌ها، می‌تواند شكل چیزی را از ظاهر آن متمایز سازید كه به بهبود هر دوی اشكال و عملكرد كمك می‌كند.

یكی از مثال‌های به یاد ماندنی‌تر و اولیه پروژه‌ی اشیاء رسانه Nicole Sullivan است. در نگاه اول شما ممكن است متوجه نشوید كه یك صفحه كامل لزوما از یك مولفه تشكیل شده و به روش‌های مختلف رندر شده است. به این صورت، ما می‌توانیم از همان نشانه‌گذاری و شكل ثابت مجددا استفاده كرده، آن را اندكی با استفاده از گزینه‌ها و یا پارامترها و استایل‌‌ها تغییر دهیم و گستره‌ای از مقادیر یا عملكردها را فراهم كنیم.

Don’t Repeat Yourself

DRY یا Don’t Repeat Yourself یكی از قوانین مورد علاقه من است – ساختن چیزهایی كه می‌توان از آن‌ها مجددا بارها و بارها استفاده كرد یكی از پیروزی‌های كوچكی است كه حین كدنویسی می‌توانید از آن بهره‌مند شوید.

درحالي كه شما اكثرا نمي‌توانيد (و به طرز بحث برانگيزي نبايد) تلاش كنيد از قانون DRY در 100% مواقع و همه موارد استفاده كنيد، حداقل اطلاع از اين قانون مفيد است، تا هنگام كار، بتوانيد اين مساله را در نظر بگيريد كه هرچه را كه بر روي آن كار مي‌كنيد، مي‌توانيد به نحوي بسازيد تا بتوان از آن مجددا استفاده كرد.

یك نكته درمورد قانون سه: یك استنباط از قانون DRY قانون سه – مخصوصا زمانی كه از چیزی مجددا برای سه بار استفاده (كپی/پیست) می‌كنید – وجود دارد كه شما باید آن را مجددا به صورت یك مولفه با قابلیت استفاده مجدد، بازنویسی كنید. مانند Pirate’s Code، این كار بیشتر شبیه یك دستورالعمل است تا یك قانون سخت و سریع، و می‌توان بین یك مولفه و مولفه دیگر و از پروژه‌ای به پروژه‌ی دیگر متغیر باشد.

CSS و سبك‌گذاری روش‌شناسی‌ها: Atomic در مقابل BEM

 روش‌های زیادی برای نظم بخشی و نوشتن كدهای CSS وجود دارد - Atomic و  BEM یكی از این بسیار شیوه‌هایی است كه احتمالا با آن‌ها برخورد خواهید داشت شما مجبور نیستید تنها یك روش را "انتخاب" كنید یا دقیقا و مو به مو از آن‌ها پیروی كنید. بیشتر تیم‌هایی كه با آن‌ها كار كرده‌ام معمولا تركیب به خصوص و منحصر به فرد خود را بر اساس پروژه یا تكنولوژی دارند. آشنایی با آن‌ها مفید است تا با گذر زمان شما بتوانید یاد بگیرید كه كدام رویكرد را بسته به موقعیت برگزینید.

تمامی این رویكردها فراتر از “CSS” و سبك‌گذاری به تنهایی هستند و معمولا می‌توانند بر روی ابزاری كه از آن بهره می‌برید، نحوه منظم كردن فایل‌هایتان و احتمالا نشانه‌گذاری نیز اثر بگذارند.

 Atomic CSS

برای این كه با طراحی وب Atomic اشتباه گرفته نشود - Atomic (احتمالا بهتر است به عنوان "عملكردی" یاد شود)CSS روشی است كه مخصوصا به استفاده از كلاس‌های كوچك و یك كاره برای تعریف تابع‌ها و عملكردهای بصری كمك می‌كند. چند مجموعه قابل ذكر:

1. كلاس Atomic از Steve Carlson

2.  Tachyons از Adam Morse

3. Tailwind CSS از Adam Wathan

چیزی كه درمورد این روش دوست دارم این است كه شما به سرعت می‌توانید موارد قالب و استایل را تغییر دهید – یكی از اشكلاتی كه دارد این است كه نشانه‌گذاری‌هایتان ممكن است به سرعت به هم ریخته شوند.

جهت مطالعه‌ی مقدمه‌ای كامل به Atomic CSS مقاله John Polecek درمورد میانبرهای CSS را بخوانید.

BEM

فلسفه BEM نسبت به بسیاری از فریم‌ورك‌های مدرن جاوااسكریپت مانند Angular،React و Vue پیشرو است.

"(BEM (Block, Element, Modifier یا بلوك، عنصر و تغییر دهنده، مولفه‌ای بر پایه رویكردی به توسعه وب است."

BEM:QuickStart

اصولا هرچیزی كه بتوان از آن مجددا استفاده كرد یك بلوك است. بلوك‌ها از عناصر ساخته شده‌اند، چیزی كه خارج یك بلوك و سایر بلوك‌ها نمی‌تواند از آن استفاده كرد. تغییردهنده‌ها مواردی هستند كه وضعیت چیزی را یا ظاهر و رفتار آن را توصیف می‌كنند.

به شخصه من از تئوری و فلسفه BEM خوشم می‌آید. چیزی كه مورد پسند من نیست نحوه نام‌گذاری موارد است. نام‌گذاری آن‌ها زیرخط، نشان یا خط ربط دارد و گاهی بسیار تكراری و غیر ضروری می‌شود. ( menu, .menu__item و غیره)

برای مطالعه بیشتر: BEM برای مبتدی‌ها نوشته شده توسط Inna Belaya 

(Next(.Js

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

1. برنامه نویسی بر محور اشیاء و عملكرد

2. زبان‌ها و فریم‌ورك‌های سطح بالاتر

Typescript، Ruby، React وVue موارد دیگری هستند كه زمانی كه فهم قوی از  HTML و  CSS دارید، باید بر روی آن‌ها مسلط شوید.

3. زبان‌های جستاری و استفاده از داده

یادگیری GraphQL،  MySQL،Rest API ها توانایی كدنویسی شما را به سطح بالاتری می‌برد.

نتیجه گیری: طراحانی كه كدنویسی می‌كنند ! = مهندسین نرم‌افزار

امیدوارم این مقاله به شما نشان داده باشد كه یادگیری كدنویسی به آن اندازه‌ای كه ممكن است در گذشته تصور كرده باشید دشوار نباشد. ممكن است زمان زیادی بگیرد، اما تعداد منابع در دسترس بر روی اینترنت بسیار خیره كننده بود و كاهش نمی‌یابند – بلكه كاملا برعكس در حال افزایش هستند!

یك نكته قابل توجهی كه می‌خواهم بر روی آن تاكید كنم این است كه "كدنویسی" همان "مهندسی نرم‌افزار" نیست – توانایی fork كردن یك repo و كپی/پیست كردن كد از Stack Overflow ممكن است مسیری بسیار دراز پیش رویتان بگذارد درحالی كه بیشتر مهندسین نرم‌افزاری كه من می‌شناسم این مسیر را طی كرده‌اند – شما باید مهارت جدید خود را با خرد و فروتنی به كار ببرید. به ازای هرچیزی كه اكنون می‌توانید به آن دسترسی بیابید، موارد بسیار بیشتری وجود دارد كه از آن‌ها بی‌خبر هستید. درحالی كه ممكن است فكر كنید كه تسلط بر روی یك ویژگی یا استایل راحت است زیرا فرآیندهای مهندسی، وابستگی و تابعیت‌ها، و روش‌های بسیاری وجود دارد كه احتمالا حتی نمی‌دانید كه آن‌ها را نمی‌دانید.

تمامی این موارد برای گفتن این است كه فراموش نكنید همه‌ی ما هنوز هم طراح هستیم. هدف و عملكرد اولیه‌ی همه ما اضافه كردن ارزش تجاری از طریق زاویه دید درك مشتریان یا مشكلات كاربری و هماهنگ‌سازی آن‌ها با دانش و الگوهای طراحی، روش‌ها، و فرایندها است. بله، یك "طراحی كه كدنویسی می‌كند" می‌تواند بسیار مفید باشد و توانایی شما در اضافه كردن این مقادیر و ارزش‌ها را گسترش می‌دهد اما هنوز نیز باید اجازه بدهیم مهندسین تصمیم‌های مهندسی را بگیرند.

آیا چیزی را از قلم انداخته‌ایم؟

احتمال زیادی دارد كه ما در این پست چیزی را مبهم، گنگ و یا منسوخ شده ذكر كرده باشیم و من از داشتن فرصتی جهت بهبود آن خرسند می‌شوم! لطفا نظر خود را زیر این پست ذكر كنید.

منبع