این روزها افق نور خورشید جاوااسکریپت بی پایانه! برای رسیدن به سرمرزهای این افق هر برنامه‌نویسی علاوه بر دانش عمومی در حوزه‌ی Node.js باید در مورد ترندها، شیوه‌ها و تکنولوژی‌های بروز در این حوزه آگاه باشه و بدونه در کدوم پروژه از چه متدهایی برای بهبود کل فرآیند استفاده کنه. با هم در دو قسمت در مورد 19 روش و مهارتی که میتونه برای ما به عنوان یک Developer حوزه Node.js ارزش‌آفرینی کنه صحبت میکنیم. با خوندن این مطلب اصلا دچار ترس و اضطراب نشید، کمتر برنامه‌نویسی وجود داره که توی همه‌ی این موارد حرفه‌ای باشه و حرف زیادی برای گفتن داشته باشه. این مباحث بیشتر یک نقشه‌ی راه و یک طرح کلی برای کشیدن نقشه‌ی یادگیری و ارتقا شخصی برنامه‌نویس‌های Node.js است.
از لذت‌های اصلی جاوااسکرپیت Type Less و یا بدون نوع بودن اونه. اما تحقیقات نشون میده که کدنویسی بدون مشخص کردن نوع متغیرها میتونه که تعداد خطاها رو افزایش بده (منبع). مخصوصا با افزایش اندازه‌ی پروژه و پیچیدگی نرم‌افزار بدون نوع بودن همه چیز میتونه پیچیدگی‌های بیشتر برای بررسی خطاها به وجود بیاره. این موضوع به این معنی نیست که از فردا راه بیافتیم و تمام نوع‌های پروژه‌مون رو مشخص کنیم، بلکه میتونیم با استفاده از ارزیابی‌کردن (validate) مدل‌ها و ورودی‌هامون از کلی حجم خطایی که ممکنه رخ بده، کم کنیم. یک راه ساده بر این کار هم استفاده از typechecker ای که فیسبوکه (گیتهاب پروژه). در نهایت یکی از بهترین راه‌ها استفاده از syntax همراه با نوع Typescript استفاده کنیم. استفاده از Typescript یکی از ترندهای حوزه Node.js و جاوااسکریپت در سالهای اخیر بوده. حتی میتونید فریمورک‌های سمت Front رو هم مثل Vue با Typescript امتحان کنید. حتی شاید وسوسه شدید که از امکاناتی شبیه Interface و abstract کلاسها هم استفاده کنید. مثال‌ها:
هر چقدر هم که برنامه‌نویس خبره‌ای باشیم باز هم ممکن موقع برنامه‌نویس چیزی رو فراموش کنیم و یک باگ برای آینده پروژه‌مون کنار بزاریم. Linterها مثل ناهار مجانی می‌مونند، چند دقیقه صرف نصب‌شون می کنیم و میتونند ما رو از یک عالمه خطا در طول عمر برنامه نجات بدن. از فراموش کردن یک semi colon ساده تا مشخص کردن promiseهای resolve نشده از جمله کارهایی هست که خطایاب‌ها برامون انجام میدن. اگر اهل برنامه‌نویسی سی شارپ با Visual Studio باشید حتما با Resharper آشنا هستید. یک مقدار CPU و RAM میدید ولی عوضش سرعت برنامه‌نویسی و خطایابی خیلی بهتری دارید. چند مثال از کارهایی که Linter انجام میدن:
این روزها توی اکوسیستم نرم‌افزاری همه از مایکروسرویس‌ها حرف میزنند و MVC هم مهمترین الگوی طراحی این روزها نرم‌افزار شده. مشکل کار کجاست؟ خیلی بعیده که بتونیم تمام نیازهایی شبیه منطق پروژه، نقش‌ها، لایه مدیریت دیتا و مابقی نیازهای نرم‌افزارهامون رو توی قالب دو تا کلاس Controller و Model ذخیره کنیم. تازه کسی صحبت از این نمیکنه هر کدوم از مایکروسرویس‌ها رو به صورت مستقل چه جوری مدیریت و طراحی کنیم. این نقل قول از عمو باب رو هم اضافه کنم که:
MVC is a delivery mechanism, not an application architecture
به نظر میاد که نباید ترسی از استفاده از Patternهای پیچیده‌تر و معماری‌های مقیاس‌پذیرتر داشته باشیم. مخصوصا با افزایش اندازه‌ی پروژه انتخاب یک معماری صحیح‌تر خودش رو بیشتر نشون میده. میتونید برای ادامه‌ی این مبحث مثال‌های زیر رو دنبال کنید:
وقتی که از معماری غیرهمزمان استفاده میکنیم مهمترین اتفاق اینه که درخواستها context خودشون رو از دست میدن و در طول چرخه درخواست-پاسخ همه‌ی متغیرهای درخواست حفظ نمیشن. مشکل اینجاست که برنامه‌نویس‌های دوست دارن که تمام اطلاعات طول یک درخواست رو به صورت پیوسته log کنند که بعدا بتونند اشکالات و گلوگاه‌های سیستم رو به راحتی شناسایی کنند. مکانیسم‌هایی برای تزریق کدها به این فرآیند وجود داره که تمام نیازهای ما رو از دنبال کردن متغیرهای یک Context در طول چرخه‌ی عمرش پوشش بده. در ادامه چند مثال برای ارتقای Tracing توی Node.js لیست شده:
خیلی از شرکت‌ها توی گذشته یک یا چندین سرور فیزیکی در محل شرکت یا دیتاسنتر داشتند و تمام عملیات مرتبط با سرور رو خودشون انجام میدادن. این روزها معماری FasS یا Function as a service یکی از ترندهای اصلی دنیا نرم‌افزار هست. شما با استفاده از این معماری قرار نیست که دوباره همه چیز رو خودتون پیاده‌سازی کنید یا تمام چیزهایی رو که لازم دارید نصب، config و نگهداری کنید. تنها بر اساس سرویس‌هایی که احتیاج دارید و مقدار مصرفتون، هزینه میکنید و به راحتی هر موقع که خواستید تقاضای امکانات سخت‌افزاری بیشتری از ارائه‌دهنده‌ی خدمات FasS میکنید. آشنایی با معماری Server less و استفاده از صحیح از اون شما رو میتونه یک مرحله بالاتر از برنامه‌نویس‌های دیگه قرار بده.
اگر خارج از ایران زندگی میکنید، حتما سر به خدمات شرکت‌هایی مثل آمازون، گوگل و مایکروسافت توی این زمینه بزنید. اگر ایران زندگی میکنید برای شروع میتونید به ابر فندق یا سرویس‌های شرکت آرمان مراجعه کنید.
برای مطالعه بیشتر:
همیشه برنامه‌نویس‌هایی وجود دارند که شبیه گذشته کد میزنند. علاوه بر واجب بودن یادگیری JS 6 باید یک نگاه‌هایی هم به نسل‌های دیگه جاوااسکریپت مثل JS 7 و JS 8 و .. بندازید و ویژگی‌ها و امکاناتشون رو یاد بگیرید. همچنین سایت https://node.green مرجع خوبی برای این هست که بدونید از چه امکانی میتونید توی کدوم نسخه از node استفاده کنید و چه ویژگی‌ها رو هنوز بلد نیستید که میتونه کدهاتون رو ساده‌تر و تمیزتر کنه.
سالهای زیادیه که rest api سلطان بلامنازع الگوی نوشتن سرویس‌ها توی حوزه‌ی وب هست. اینکه هر موجودیتی endpoint خاص خودش رو داشته باشه و بتونیم از قیدهای http برای مدیریت درخواستها استفاده کنیم از مهمترین مزایا الگوی rest api هست. اما همه چیز rest نیست و rest هم نمیتونه همه چیز رو پشتیبانی کنه.
به دلیل ماهیت و معماری rest api و Stateless بودن اون امکان پیاده‌سازی سرویس‌هایی مثل چت‌های آنلاین با rest api امکان پذیر نیست. همچنین مشکل n + 1 دررخواست از دیگر مشکل‌های اصلی سرویس‌های مبتنی بر rest api هست. توی این سالهای گذشته دو الگوی GraphQL و grpc به شدت محبوب و پر کاربرد شدن. حتی اگر آگهی‌های استخدامی این روزهای ایران رو هم نگاه کنید، شرکت‌هایی زیادی وجود دارند که برای استخدام node.js کار مورد علاقه‌شون شرط آشنایی با GraphQL رو هم مطرح کردند. بهتر هست به این دو تکنولوژی نگاه دقیق‌تری بندازید و حداقل یک پروژه با GraphQL انجام بدید.
مطالعه بیشتر:
توی سالهای گذشته برنامه‌نویسی با وجود مایکروسرویس‌ها، معماری server less و فرانت‌های تغییرهای اساسی به خودش دیده اما توی حوزه‌ی تست نویسی ما هنوز و اغلب تنها از unit تست‌ها، integration تست‌ها و end-to-end تست‌ها استفاده میکنیم (واقعا استفاده میکنیم؟ :) ). میشه گفت این روزها تنها این تست‌ها کافی نیست، باید روش‌ها و متدهای جدیدتری هم توی این زمینه یاد بگیریم. برای شروع میتونید لینک‌های زیر رو بررسی کنید:
این روزها این قدر مشغول یادگرفتن کتابخونه‌های جدید و ترندهای برنامه‌نویسی در هنگام Develop کردن هستیم که فراموش میکنیم بخش اصلی کار وقتی هست که کدهای ما توی محیط Production قرار میگیره. میدونم که مانیتورینگ سرور رو میتونند دوستان شبکه کار به عهده بگیرند اما به عنوان برنامه‌نویس هم باید کمی با این موضوعات آشنا باشیم. مثلا بدونیم که زمان پاسخدهی هر کدوم از سرویس‌هامون به طور متوسط چند میلی ثانیه است یا اینکه برای هر رکوئست چقدر CPU و RAM استفاده میکنیم. تازه علاوه بر این‌ها باید به درستی بتونیم خطاها رو ردیابی کنیم و یا زودتر از هر کسی دیگه‌ای از اشکالات سرورمون خبردار بشیم. برای شروع میشه این مطالب رو بررسی کرد:
اگر نتونید مثل یک هکر فکر کنید و ابزارهای حمله‌ی اون‌ها رو بلد باشید، هیچ وقت نمی‌تونید یک استراتژی مناسب برای دفاع در نظر بگیرید. توی سال 2019 انجام یک کار کافی نیست، باید بلد بشید چه طوری از نرم‌افزارتون و داده‌های مشتری‌هاتون محافظت کنید و در صورت مورد حمله واقع شدن خسارت رو به حداقل برسونید. به هشدارهای امنیتی هم توجه کنید و همیشه حواستون به Patchهای امنیتی ابزارهاتون باشه. همچنین فراموش نکنید امنیت چیزی نیست که در انتهای پروژه به کدهاتون اضافه کنید، بلکه چیزیه که از همون روز اول باید یک نقشه‌ی مناسب براش داشته باشید.
برای مرور بیشتر:
این نوشته ترجمه‌ی آزادی از این مطلب در مدیومه. سعی میکنم خیلی زود قسمت دومش رو مثل همین ترجمه‌ی آزاد منتشر کنم.
