10 نکته که در نهایت درباره پروژه‌های JavaScript یاد خواهید گرفت
ﺯﻣﺎﻥ ﻣﻄﺎﻟﻌﻪ: 10 دقیقه

10 نکته که در نهایت درباره پروژه‌های JavaScript یاد خواهید گرفت

JavaScript یک ماجراجویی است. من پس از تقریبا یک دهه توسعه آماتور و حرفه‌ای در صنایع متنوع، مطمئنم که همه با این مسئله موافقت می‌کنند.

پروژه‌های frontend به ما برنامه‌نویسان انتخاب‌های زیادی در زمینه انعطاف، و فضای زیادی برای خلاقیت می‌دهند. اما در عوض مقداری دانش، برنامه‌ریزی و مسئولیت پذیری می‌طلبند. من با بررسی پروژه‌های مختلفی در jQuery، require.js، Angular، React، ExtJS و حتی بسیاری موارد دیگر که به یاد نمی‌آورم، چیزهایی دیده‌ام که در frontend سال 2018 غیر قابل تصور هستند. اما همیشه برخی الگوهای رایج وجود دارند که کار کردن حتی بر روی ناهماهنگ‌ترین پروژه‌ها را ممکن می‌کنند. در اینجا، ۱۰ مورد از حیاتی‌ترین آن‌ها را خواهید یافت. این موارد را از روی تجربه شخصی خود نوشته‌ام، اما مطمئنم که بسیاری از توسعه دهندگان با تجربه با آن‌ها موافقت خواهند کرد. این اساس‌ها،‌ پایه ثابتی برای یک پروژه در هر فریم‌وورکی، هر متدولوژي‌ای و هر اندازه تیمی می‌سازند، و باعث کاهش زحمت مورد نیاز از سمت توسعه دهندگان می‌شوند.

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

1. تقسیم کرده، و پیروز شوید

اکثر ما این قانون را دست کم می‌گیریم. CommonJS، Webpack و Node قابلیت جداسازی کد به چندین فایل را می‌دهند، اما اصلا چرا باید به این مسئله اهمیت دهیم؟

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

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

2. همه چیز را به شدت واضح کنید

تمام متغیرها، توابع و تمام فایل‌ها را به گونه‌ای نامگذاری کنید، که انگار در حال نامگذاری فرزند خود هستید. ممکن است امروز ۰.۳ ثانیه زمان صرف کنید تا یک متغیر را «x» نامگذاری کنید، اما یک ماه دیگر باید ۲ روز وقت صرف کنید تا ببینید که چه معنایی دارد، و سپس هم ۴ روز دیگر برای بازسازی آن. فکر کنید، و از نام‌های طولانی نترسید.

3. از اعداد و رشته‌های جادویی پرهیز کنید

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

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

4. با تو در تویی مبارزه کنید

اگر کد شما ۱۲۰ کاراکتر عرض دارد، ۵۰۰ خط طول دارد یا بیانیه if شما سه مرحله فرونشینی دارد، در حد ممکن سعی کنید که آن را تقسیم بندی کنید.

شما می‌توانید پیچیدگی شرطی را با تقسیم کردن کد در بیانیه if و جداسازی توابع، Promiseها یا Observable ها برطرف کنید. اگر از تعداد زیادی فراخوانی ناهمگام استفاده می‌کنید، async / await هم می‌تواند به طور قابل توجهی کد شما را ساده‌سازی کند.

5. به طور سختگیرانه پیکربندی کنید

اگر برنامه شما از متغیرهای global، ادپوینت‌های API، feature toggleها یا... استفاده می‌کند، آن‌ها را در یک فایل پیکربندی جداگانه قرار دهید.

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

6. فریم‌وورک‌ها برای کمک به شما آماده‌اند

در مواقع زیادی می‌بینید که فریم‌وورک‌ها به علت این که یک نفر آن‌ها را می‌شناسد یا معروف هستند، مورد استفاده قرار می‌گیرند.

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

  • React: این مورد وقتی که به یک کنترل کامل بر روی معماری و ساخت وب‌اپلیکیشن‌هایی که با استفاده از کامپوننت‌ها ساخته شده‌اند نیاز دارید، بهترین مورد است. توسعه اکوسیستم React زمان می‌برد و نیازمند مقدار زیادی برنامه‌ریزی قبل از شروع است.
  • Angular / VueJS / Ember: این موارد وقتی که به یک وب‌اپلیکیشن نیاز دارید که سریعا ساخته شود و قابل اعتماد باشد، بهترین مورد است. این فریم‌وورک‌ها کار زیادی برای شما انجام می‌دهند. همچنین ساختار محدود آن‌ها نسبت به دنیای آزاد React، از بروز خطاهای زیادی جلوگیری می‌کنند.
  • jQuery / lodash یا موارد مشابه: وقتی که می‌خواهید یک وب‌اپلیکیشن سریعا ساخته شود و می‌توانید از خیر چند کیلوبایت بگذرید، این‌ها انتخاب‌های خوبی هستند. این موارد با توجه به این که شما را قادر می‌سازند تا یک کد غیر قابل نگهداری بنویسید، می‌توانند زمان توسعه را به طور قابل توجهی کاهش دهند، اما نیازمند احتیاط هستند. از این موارد به عنوان کمک کننده استفاده کنید، نه به عنوان پایه.
  • Vanilla / بدون هیچ‌گونه فریم‌وورک: هم برای صفحه‌های وب و هم برای وب‌اپلیکیشن‌ها، که در آن‌ها می‌توانید زمان زیادی را به توسعه و برنامه‌ریزی اختصاص دهید. JavaScript خالص وقتی که پروژه شما یک کار آزمایشی را انجام می‌دهد، انتخاب خوبی است. این مورد اگر به همراه trasnpilerها استفاده شود، می‌تواند جایگزین خوبی برای jQuery باشد.

این لیست را فقط به عنوان یک پیشنهاد در نظر داشته باشید. در انتخاب فریم‌وورک مورد نظر عجله نکنید و بهترین مورد را برای پروژه خود انتخاب کنید.

7. اگر پروژه شما یک نمونه اولیه نیست، برای آن test بنویسید

اگر پروژه شما یک نمونه اولیه نیست، یک testها مانند unit test، smoke test یا End-to-end test بنویسید. با افزایش پیچیدگی کد، نگهداری و کنترل آن بسیار سخت‌تر خواهد شد، که testها این مسئله را برای شما آسان‌تر خواهند کرد. با انجام این کار، در آینده و وقتی که با یک باگ رو به رو می‌شوید، از خود تشکر خواهید کرد؛ زیرا اگر این کار را انجام نمی‌دادید، هیچ وقت نمی‌دانستید که چه چیزهایی در پس‌زمینه با شکست مواجه شدند.

برای نوشتن تست در جاوااسکریپت میتوانید دوره Unit Test در جاوااسکریپت را مشاهده کنید

8. از کنترل نسخه (Version Control) استفاده کنید

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

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

برای یادگیری گیت و گیت هاب میتوانید دوره آموزش گیت و گیت هاب را مشاهده کنید

9. به طور پاسخگو state را مدیریت کنید

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

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

  • از آنجایی که React یک اکوسیستم بسیار باز است، راه حل‌های زیادی وجود دارند. Redux برای معماری Flux و Mobx برای موارد بر پایه observable مناسب هستند. هر کدام از این دو، نکات مثبت و منفی خود را دارند. مطمئن شوید که قبل از استفاده از این کتابخانه‌ها، اساس آن‌ها را یاد بگیرید.
  • Agular، Ember و VueJS راه حل‌های داخلی خود را دارند. کتابخانه‌های دیگری مانند ngRx، Akita و Vuex هم وجود دارند، اما ضروری نیستند.
  • برای هر فریم‌وورک دیگری مانند Vanilla JavaScript، می‌توانید از Redux، Mobx یا حتی راه حل به خصوص خود استفاده کنید. هدف اصلی این است که مطمئن شویم کل برنامه یک منبع مشابه دارد، که این منبع می‌تواند یک سرویس، یا یک کتابخانه باشد.

10. گرایش‌ها را زیر سوال ببرید

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

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

منبع

چه امتیازی برای این مقاله میدهید؟

خیلی بد
بد
متوسط
خوب
عالی
5 از 1 رای

/@er79ka

دیدگاه و پرسش

برای ارسال دیدگاه لازم است وارد شده یا ثبت‌نام کنید ورود یا ثبت‌نام

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

در حال دریافت نظرات از سرور، لطفا منتظر بمانید