نکاتی برای ایجاد سریعتر پروژه های جلویی بهتر – قسمت 1

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

سپس ما می خواهیم اولین پروژه خود را به تنهایی انجام دهیم (یا دوم یا سوم …) و این احساس به شما دست می دهد … و اکنون؟ چکار کنم؟ از کجا آغاز کنم؟

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

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

1) برنامه ریزی

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

این چیزی است که شما می خوانید. رها کنید تا VS Code در یک لحظه باز شود.

شروع به برنامه ریزی می کنیم. و برای آن، طرحی را که می‌خواهیم بسازیم، باز می‌کنیم.

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

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

با باز بودن طرح، به نکات زیر توجه خواهید کرد:

الف) آیا راهنمای سبک وجود دارد؟

در اینجا زمان ساخت راهنمای سبک CSS ما است. بیایید به چیدمان نگاه کنیم و از خود بپرسیم: از چه رنگ هایی استفاده می شود؟ چه فونت هایی استفاده می شود (خانواده، اندازه، وزن)؟

من معمولاً این کار را با ایجاد ویژگی های سفارشی در CSS (CSS Custom Properties) انجام می دهم که معمولاً آن را متغیرهای CSS می نامیم.

در قسمت Custom Properties تمام رنگ های پروژه، font-family، font-weight و font-size را تعریف می کنم. بنابراین، برخی از انواع تغییرات را می توان در راهنمای سبک پروژه، بدون نیاز به دسترسی به هر نمونه از آن ویژگی، ایجاد کرد.

نتیجه چیزی شبیه به این است:

:root{
--color-main: #FF0000;
--color-secondary: #00FF00;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

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

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

:root{
--color-main: #FFFF00;
--color-secondary: #00FFFF;

--ff-arial: 'Arial', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 32px
}

به این ترتیب، هر جا که ویژگی های سفارشی “color-main” و “color-secondary” را قرار دهم، تغییرات تکرار می شود.

ب) تراز چیست؟ آیا خط شبکه وجود دارد؟

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

در اینجا یک نمونه از یک وب سایت نادرست است. من حاشیه های جانبی را ایجاد کردم تا بتوانیم ببینیم که چگونه هیچ الگوی در تراز وجود ندارد.

ببینید با یک تراز دقیق تر چقدر بهتر به نظر می رسد:

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

برای انجام این کار از ظروف استفاده می کنیم. ما این کلمه را می شنویم، آن را در کدهای دوره می بینیم، اما اغلب به هدف این ظرف فکر نمی کنیم.

نقش ظرف این است که … حاوی محتوای خاصی باشد.

خوب، باشه، من تعریف کمتر واضحی به شما می دهم.

ظرف وظیفه تعیین حداکثر عرض عناصر داخل آن را بر عهده دارد. اگر دو محتوای مجزا با عرض یکسان داشته باشیم و با مرکز تراز شده باشند، می‌توانیم (تقریبا) مطمئن باشیم که این محتواها تراز هستند. می‌گویم «تقریبا» زیرا می‌توانیم با قرار دادن بالشتک روی ظرف، این تراز را بشکنیم، به عنوان مثال، ترازهایی را که ظرف سعی می‌کرد ایجاد کند به هم بزنیم.

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

“خوب، کایو، اما اگر عرض های مختلفی داشته باشم چه می شود؟”

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

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

در آن مثال caio-chella – پروژه ای که در طول چالش Alura’s Challenge Front-End ایجاد شد که در مارس 2023 انجام شد) – من آن را به صورت زیر ساختار دادم:

:root{
--container-width: 86.5%;
}

.container{
   width: var(--container-width);
   margin-inline: auto;
}

به این ترتیب عرض یکسانی را برای همه کانتینرهایم ایجاد کردم و در کلاس کانتینر این عرض را اعمال می کنم، علاوه بر اینکه آن را با ویژگی margin-inline در مرکز تراز می کنم.

اگر می خواهید پروژه را بررسی کنید، به github من مراجعه کنید: https://github.com/marcelluscaio/Codechella_AluraChallenge/tree/main

ج) آیا عناصر گرافیکی تکراری وجود دارد؟

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

خیلی عجیب است اگر یک دکمه در قسمت اول سایت مستطیل و آبی و یکی دیگر در انتهای آن گرد و صورتی باشد، اینطور نیست؟ بنابراین، معمولاً طراحی یک وب سایت دارای عناصر مشابهی است.

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

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

این تمایز کمتر از منطق پشت آن اهمیت دارد، زیاد به آن وابسته نشوید.

فرض کنید دیده اید که دکمه های سایت شما همگی دارای پس زمینه قرمز و رنگ متن سبز هستند. چه کار میکنی؟

طراح خود را اخراج کنید!

شوخی! وقتی این الگو را متوجه شدیم، می توانیم کلاسی ایجاد کنیم که این ویژگی ها را جمع آوری کند:

:root{
--color-main: #ff0000;
--color-secondary: #00ff00;

}

.button{
background-color: var(--color-main);

color: var(--color-secondary)
}

همچنین می‌توانید ویژگی‌های مشترک دیگری را که دکمه‌ها دارند، مانند padding، border-radius و text-align مشاهده کنید.

یکی دیگر از عناصر یک وب سایت که تمایل به استانداردسازی بالایی دارد، تایپوگرافی است.

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

:root{
--ff-calistoga: 'Calistoga', cursive;
--ff-raleway: 'Raleway', sans-serif;

--fw-1: 400;
--fw-2: 700;

--fs-1: 16px;
--fs-2: 24px;
--fs-3: 48px;

}

.title{
font-family: var(--ff-raleway);
font-weight: var(--fw-2);
font-size: var(--fs-3);
line-height: 1.2;
}

.title--small{
font-size: var(--fs-2)
}

.text{
font-family: var(--ff-calistoga);
font-weight: var(--fw-1);
font-size: var(--fs-1);
line-height: 1.5;
}

.text--bold{
font-weight: var(--fw-2);
}

و سپس در HTML خود می توانید کاری مانند:

<h1 class="title">Título</h1>
<h2 class="title title--small">Título menor</h2>
<p class="text">Texto</p>
<p class="text text--bold">Texto em negrito</p>

د) عرض صفحه نمایش مورد استفاده در چیدمان چقدر بوده است؟

بارها به طرح‌بندی نگاه می‌کنیم و سعی می‌کنیم آن را روی صفحه‌مان تکرار کنیم: «آیا طراح 30 پیکسل صفحه‌نمایش را روی صفحه قرار داده است؟ من می‌خواهم همان را در اینجا در صفحه‌ام قرار دهم و دقیقاً به همان شکل خواهد بود.

ببینید، به نقطه‌ای می‌رسید که نمی‌توانید آنچه را که در طرح‌بندی می‌بینید، صادقانه بازتولید کنید. “اما من دقیقا همان اندازه گیری هایی را که آنجا بود انجام دادم! ببین، کایو، به همین دلیل است که من از جلو خوشم نمی آید!».

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

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

توسعه سایت یک فیلم است، ترکیبی از همه این عکس ها / صحنه ها.

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

یک جهش بزرگ در طرز فکر یک توسعه‌دهنده خوب این است که دیگر به عکس نگاه نکند (“روی صفحه نمایش من کار می‌کند!”) و شروع به نگرانی در مورد فیلم (“وقتی صفحه نمایش کوچکتر/بزرگتر از صفحه نمایش است چگونه رفتار خواهد کرد؟ چیست؟” تجربه کاربری محصولی که من ایجاد می کنم؟»).

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

به یاد داشته باشید، ابزار توسعه بهترین دوست شماست.

ه) Mobile-first ou Desktop-first؟

نکته دیگری که باید در نظر گرفت این است: کدام پارادایم را در پروژه اتخاذ کنیم، اول موبایل یا دسکتاپ؟ اگر نمی دانید در مورد چه چیزی صحبت می کنم، این دو پارادایم هستند که نحوه شروع پروژه خود را مشخص می کنند: “mobile-first” (موبایل اول) ابتدا نسخه موبایل را توسعه می دهد و “desktop-first” ( ابتدا کامپیوتر) با نسخه دسکتاپ شروع می شود.

بهتر است به این مفاهیم عادت کنید. =)

اما بالاخره از کجا باید شروع کرد، برای توسعه موبایل یا دسکتاپ؟

اگر صدای کوچکی در درون سر شما شبیه هرمیون است، مشتاق پاسخ دادن است و فریاد می زند: «این بستگی دارد! بستگی داره!” شما در راه ارشد شدن هستید! 500 امتیاز به گریفیندور!

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

اگر برای یک صفحه نمایش 370 پیکسل شروع به توسعه کنید، به عنوان مثال، وقتی با صفحه نمایش های بزرگتر، مثلاً 1200 پیکسل سازگار می شوید، از حداقل عرض 1200 پیکسل استفاده خواهید کرد.

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

مرتب نگه داشتن پرس و جوهای رسانه ای خود بسیار مهم است تا هنگام شکار حشرات نگران نباشید.

نتیجه

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

اما ما به سختی شروع به نوشتن کد کردیم. هفته آینده نکات بیشتری را برای قوی تر کردن پروژه شما ارائه خواهم کرد.

اینجا در نظرات به من بگویید: کدام نکته را بیشتر دوست داشتید و کدام را از دست دادید؟