https://virgool.io/feed/@beardydeveloper اگه خدا بخواد برنامه نویس فرانت اند fa 2026-04-15 01:32:56 https://files.virgool.io/upload/users/81176/avatar/jjPieF.png?height=120&width=120 https://virgool.io/@beardydeveloper https://virgool.io/javacup/%D9%85%D8%AF%D9%84-%D8%A2%D8%A8%D8%B4%D8%A7%D8%B1%DB%8Cwaterfall-%D9%88-%DA%86%D8%A7%D8%A8%DA%A9agile-%D8%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-ldirdghrnejc از اونجایی که متد های توسعه این روزا خیلی هارو سردر گم کردن و تو اکثر آگهی ها اون پایین مایینا نوشتن "آشنا با اجایل"، تصمیم گرفتم یه مقاله مختصر بنویسم و این اصطلاحات رو براتون باز کنم تا بهتر درکشون کنید.اصلا متدی که میگیم چی هست ؟منظور فرایند یا چرخه حیات تولید نرم افزار هست. هر تیمی بسته به شرایط، منابع، جغرافیا و کلی دلیل دیگه به روش خاصی برای توسعه محصولات خودش انتخاب میکنه.برای مثال تیمی که منابع مالی محدودی داره در مقایسه با تیمی که منابع مالی زیادی داره روش متفاوتی رو پیش میگیره تا بتونه محدودیت هارو نادیده بگیره.یا تیمی که تو شهر ظلم آباد از کشور ناکجا آباد داره کار میکنه مسلما روش متفاوتی در مقایسه با تیمی که تو نیویورک کار میکنه داره.بطور کلی به این روش ها، فرایند یا متد یا مدل های توسعه گفته میشه.چند تا مدل توسعه وجود داره ؟مدل و فرایند تا دلتون بخواد داریم ( اصلا کی به کیه خودمون هم میتونیم یه متد بصورت کاملا دیمی خلق کنیم و با همون پیش بریم :) ولی یه سری از این متد ها و فرایند ها هستن که خیلی معروف هستن و تیم های زیادی باهاشون کار میکنن. مثل scrum, kanban, agile, scrumban, lean, XP, waterfall, PMBOK و ... .اگه بخوایم همه این متد های توسعه رو بچپونیم تو مقاله فکر نکنم کسی حوصله کنه و تا ته اسکرول کنه :)از این گذشته تو کشور خودمون ایران هم همه این متد ها مرسوم نیستن و معروف ترین ها همین متد های مرتبط با اجایل و مدل آبشاری هستن که قراره این موارد رو بررسی کنیم در ادامه. آبشاری (WaterFall)مدل آبشاری که بهش linear-sequential هم گفته میشه، میشه گفت قدیمی ترین و اولین مدل فرایندی معرفی شده هست. تو این مدل توسعه، همه چیز بصورت یک جریان خطی رو به پایین وجود داره (مثل یه آبشار). یعنی چی ؟این مدل شامل چند فاز توسعه مختلف هست که هر کدوم تو یه بخشی از این مسیر به اصطلاح آبشار قرار دارن و فرایند طوری هست که هر فاز باید تموم بشه تا به فاز بعدی برسیم. هیچ ارتباطی هم بین این فاز ها وجود نداره این وسط.به عکس زیر توجه کنید :مراحل و فاز های مدل آبشاریهمونطور که تو عکس هم میبینید، ما از فاز بررسی نیازمندی ها باید شروع کنیم و به ترتیب بیایم و برسیم به آخر خط تا بتونیم محصول خودمون رو ارائه بدیم. دقت کنید که این مراحل یکبار ۰ تا ۱۰۰ برنامه ریزی میشن و تا رسیدن به محصول نهایی قابل بازبینی نیستن.برای مثال اگر شما برنامه نویس سایت باشد، باید کل طرح ui سایت رو که از فاز طراحی به دستتون رسیده کدنویسی کنید و تحویل فاز بعدی بدید.حالا با توجه به این تعریف بریم ببینیم این مدل چه مزایا و چه معایبی داره :مزایای مدل آبشاریساده و قابل فهم: این مدل بیشتر بخاطر سادگی و عدم پیچیدگی که داره انقدر محبوب شده و هنوزم که هنوزه خیلی جاها ازش استفاده میکنن. منظور از سادگی اینه که ما هیچ مفهوم و اصطلاح و نقش سازمانی پیچیده ای نداریم و همه چیز مشخص و قابل فهم هست.سرعت بالا در پروژه های کوچک: این مدل اصلا خوراک پروژه های کوچیکی هست که نیازمندی های اون ها کم و قابل ارزیابیه( مثلا یه سایت معمولی لیندینگ طور ).عدم تداخل فاز ها: همونطور که بالاتر هم گفتم تو این مدل فاز ها هیچ تداخل و همجوشی با هم دیگه ندارن و هر فاز فقط در مرحله خودش انجام میگیره و.مشخص بودن بازه و ملزومات فاز ها: از اونجایی که فاز ها با همدیگه تداخلی ندارن و باعث بروز مشکل توی فاز های دیگه نمیشن، تقریبا میشه زمان دقیق شروع و پایان هر فاز رو تخمین زد و تعیین کرد که چه کار هایی باید داخلش انجام بشه ( با توجه به کار هایی که تو فاز قبلیش انجام شده ).مدیریت ساده: از اونجایی که این مدل قابل درک برای تمام اعضای تیم هست، مدیریت فاز ها و وظایف کار راحت تری هست.معایب مدل آبشاریعدم وجود demo های متعدد برای مشتری: یکی از بزرگترین ایراداتی که این مدل داره اینه که تا وقتی به فاز آخر نرسیم، عملا هیچ پیش نمایشی از محصول برای ارائه به مشتری نداریم.سختی در تغییر نیازمندی ها: اگر مشتری یا هرکس دیگه ای آخر کار یا حتی حین کار خواستار تغییری باشه، اعمال این تغییرات خیلی سخته چون باید برگردیم به فاز اول و دوباره شروع به بررسی کنیم. این کار بصورت غیرمستقیم باعث بروز مشکلاتی که تمامی فاز های بعدی میشه و نیازه که اوناهم تغییر داشته باشن.دیباگ کردن طاقت فرسا: فرض کنیم ما تمام فاز هارو تموم کردیم و نسخه نهایی رو هم پابلیش کردیم و پولمونو هم گرفتیم و رفتیم باهاش بستنی بخوریم. تو همین حین مشتری زنگ میزنه و میگه فلان جای سایتم فلان مشکل رو داره؛ بی زحمت درستش کنید.اینجاست که بستنیه میپره تو گلوتون:) چرا ؟چون دیباگ کردن تو مدل آبشاری به این معنیه که برای اصلاح یه باگ کوچولو باید بریم دوباره از فاز های بالایی شروع به تغییر دادن بکنیم و پله پله بیایم پایین تا برسیم به فاز آخر و نسخه جدیدی رو ارائه بدیم.ناکارآمدی در پروژه های بزرگ و ریسک بالا: همونطور که گفتم تو این مدل هیچ چیز قطعی نیست( حتی بعد از رسیدن به نسخه نهایی، چون ممکنه تغییراتی اعمال بشه ). در نتیجه اصلا توصیه نمیشه برای پروژه هایی که نیازمندی های پیچیده ای دارن و طولانی مدت هستن از این مدل استفاده کنید.خب، این بود مفهوم و مزایا و معایب مدل آبشاری. فکر کنم دیگه براتون جا افتاده باشه کاملا. چابک (Agile)حلقه های تکرار در اجایلاولین چیزی که باید بدونید اینه که اجایل مساوی با اسکرام نیست. خیلیا به اشتباه فکر میکنن اسکرام اسم دیگه ای برای اجایل یا بالعکس هست و این کاملا غلطه.اجایل یک سری اصول و رویکرد های خاص و درواقع به نوع تفکر هست که تو اون، هدف ما تقسیم مکرر و متوالی کار به بخش های کوچیک برای ارائه های سریع و متوالی و در نتیجه جلب رضایت مشتری و پاسخ به تغییراتی هست که مشتری نیاز داره.این تقسیمات باید مدام در بازه های زمانی مشخص و یکسان تکرار بشن که اصطلاحا به این تکرار ها iteration گفته میشه.همون طور که تو عکس بالا مشاهده میکنید، ما یک نمود تصویری از یک iteration داریم که داخلش برنامه ریزی بخش کوچیکی از توسعه و نقشه راه رو وارد میکنیم و بعد از مراحل داخل عکس، اون بخش کوچیک رو عرضه میکنیم.درست مثل یه آشپز که حین پختن غذا، همه مواد غذایی رو یکجا نمیریزه تو ظرف و هر چیزی رو جداگانه آماده و رفته رفته ادغام میکنه و مدام غذا رو مزه میکنه تا مطمئن بشه توی تمامی مراحل پخت، غذا همون چیزیه که باید باشه؛تو اجایل هم ما پروژمون رو بجای اینکه بصورت یکپارچه وصفر و صدی توسعه بدیم، اون رو تو بخش های کویچک در بازه های زمانی کوتاه مدت توسعه میدیم و بعد از اتمام هر بخش، تست و بررسیش میکنیم و پیش نمایش هایی رو ارائه میدیم تا مطمئن بشیم مورد رضایت مشتری یا ذینفع پروژه هست.تکه تکه پیش بردن مسیر به روایت تصویر :)اصول اجایلارتباط نزدیک و سازنده تمامی افراد و برنامه نویس های تیم باهمدیگه.تعامل موثر و مرتب با مشتری طی فرایند توسعه برای درک بهتر نیازمندی های پروژه و درخواست های مشتری.ارائه نسخه های متعدد حین توسعه پروژه به مشتری برای درک بهتر درخواست ها و نیازمندی ها.پاسخ به تغییرات و پذیرش اونها طی فرایند توسعه.متد های اجایلیهمون طور که گفتیم اجایل فقط یه طرز تفکر هست و نه متدولوژی. اما متد هایی وجود دارن که با همین طرز تفکر زاده شدن و یه جورایی زیرمجموعه ای از اجایل هستن.از معروف ترین متد ها، میشه Scrum رو اسم برد که احتمالا اسمش رو زیاد شنیدید.این متد ها معمولا اصول و ارزش های مشترکی دارن اما یه سری تفاوت هایی هم ممکنه داشته باشن با هم.- متد scrumاسکرام یه متد خیلی کارآمد برای پرداختن به پروژه های پیچیده و دارای نیازمندی های متعدد هست.تمرکز اصلی این متد روی همکاری و تعامل اعضای تیم و ارتباط اونها با همدیگه هست. این تعامل به کمک وجود نقش های مختلف در تیم و جلسات متعددی که تو این متد وجود داره به راحتی دست یافتنی هست.قراره نقش ها و اصطلاحات و فرایند های این متد رو با هم دیگه بررسی کنیم.(یک سری از اصطلاحات، تو متد های دیگه هم وجود داره که همینجا کاملا میپردازیم بهشون) یه نگاهی به این عکس بندازید :سیستم کلی اسکراماصطلاحات:داستان کاربر(user story): تعاریف و توصیف‌هایی شفاف از ویژگی‌های مورد انتظار مشتری هست که ممکنه هم توسط مشتری و هم توسط مدیران پروژه نوشته بشه.برای مثال "امکان سفارش آنلان غذا" یک استوری برای یک پروژه فروشگاهی هست.بک لاگ محصول(product back log): بک لاگ رو میتونیم انباری از داستان ها و کار های در انتظار انجام تصور کنیم که برای تهیه لیست کار های روزمره، به این انبار سر میزنیم و موارد مورد نیاز رو با خودمون برمیداریم و میبریم(اصطلاحا pull میکنیم) و اگر کاری قابل انجام نبود دوباره برمیگردونیمش به انبار(یا push میکنیم).اسپرینت (sprint): به بازه های زمانی شخص که برای توسعه بخش های کوچک و شکسته شده در نظر گرفته میشن، اسپرینت گفته میشه. اسپرینت ها در متد اسکرام، بسته به عواملی ممکنه ۲ هفته الی ۴ هفته طول بکشن.تو این بازه ها هر کدوم از اعضای تیم مسئول انجام کاری هست که بهشون محول شده.بکلاگ اسپرینت (Sprint Backlog): به لیست کارهایی که در طول یک اسپرینت باید انجام داده بشه گفته میشه. این لیست از لیست بک لاگ محصول بیرون کشیده میشه.وظیفه(task): به هر کدوم از آیتم های موجود در بک لاگ اسپرینت که باید توسط تیم انجام بشن task گفته میشه.بُرد(Board): در تمام مراحل کار باید یک بُرد فیزیکی یا دیجیتالی داشته باشیم که اعضای تیم بتونن از وظایف خودشون و بقیه اعضای تیم مطلع باشن و روند کاری و وضعیت فعالیت های خودشون رو بصورت تصویری پیگیری کنن. ورودی های این بُرد همون بک لاگ اسپرینت هست و بعد از شروع اسپرنت همه روزه به روز رسانی میشه.این بُرد ها شامل ستون های مختلفی هستن که ممکنه متغیر باشن تو هر متد یا تیمی و حتی اسامی مختلفی داشته باشن. اما در ساده ترین حالت حداقل سه ستون زیر رو شامل میشن :منتظر انجام یا todo ،در حال انجام یا in progress، انجام شده یا done.یک نمونه boardتسک های موجود در بُرد ممکنه بسته به اولویت، ستون یا موضوعی که دارن رنگ های مختلفی داشته باشن تا بهتر دسته بندی بشن. همچنین ممکنه یک سری point بر حسب درجه سختیشون داشته باشن.اگر بخوام تصویر بالا رو توضیح بدم :-لیست to do از بک لاگ به بُرد تزریق میشه.-هر شخصی تسک خودش رو از ستون to do وارد ستون in progress یا develop میکنه و شروع به کار میکنه.-بعد از اتمام کار، کد میتونه وارد ستونی به اسم in review بشه که تو این مرحله شخص دیگه ای مسئول مرور کردن این کد ها میشه.-ستون بعدی ستون تست هست که تو این قسمت تستر شروع به تست کردن کار های انجام شده میکنه.در نهایت اگر همه چیز اوکی بود، تسک مورد نظر ادغام میشه و میره تو ستون done. جلسات برنامه ریزی(planning): جلساتی که قبل از شروع هر اسپرینت برگزار میشن و همه افراد تیم به کمک استاد اسکرام، با توجه به اولویت بندی های موجود و زمان و توان انجام، شروع به بیرون کشیدن لیستی از بک لاگ میکنن تا به اسپرینت تزریقش کنن.جلسات سرپایی(Stand up Meeting): همه روزه و معمولا قبل از شروع به کار، جلساتی به مدت ۱۵ دقیقه بین اعضای تیم برگزار میشه که درمورد کار های روز قبل، مشکلات پیش اومده و برنامه کارهای روز جاری صحبت میشه( این جلسات معمولا بصورت ایستاده برگزار میشه ).جلسه گذشته نگر(retro): بعد از اتمام هر اسپرینت، جلسه ای برگزار میشه که تو اون تمامی اعضای تیم درمورد تجربیات، آموخته ها، مشکلات و کمبود هایی که تو اسپرینت به اتمام رسیده داشتن صحبت میکنن.جلسه نسخه نمایشی(demo): این جلسه بسته به پیشنهاد ذینفع یا ذینفعان پروژه و یا درخواست مشتری، هر یک یا چند اسپرینت یک بار برای مشاهده demo یا پیش نمایش از نتیجه اسپرینت های به اتمام رسیده برگزار میشه.نقش ها:اگر شما مشتری بودید که با تیم اسکرام کار میکردصاحب محصول(product owner): به عنوان ذی نفع پروژه و نماینده مشتری، مسئولیت جمع آوری و اولویت بندی بک لاگ ها و تعیین نقشه راه رو داره. همچنین دائما با مشتری در ارتباط هست و feedback هایی رو دریافت و منتقل میکنه.استاد اسکرام(scrum master): شخصی هست که مسئولیت برنامه ریزی اسپرینت و تزریق لیست کار ها،نظارت بر پیشبرد و اتمام به موقع کار ها، اطلاع از کار اعضا و متمرکز کردن اون ها رو به عهده داره.تیم توسعه(develop team): تیمی متشکل از افرادی با تخصص های مختلف که مسئول به تحقق رساندن اهداف اسپرینت هستن. تعداد این اعضا متغیر هست اما معمولا بیشتر از ۱۰ نفر نیستن.هیچ کدوم از این اعضا نسبت به دیگری برتری و رتبه ندارن و همیشه در تعامل سازنده با همدیگه هستن.بررسی فرایند کاری :حالا که کاملا با این اصطلاحات آشنا شدید، میخوام اتفاقات یک اسپرینت رو بصورت خلاصه وار با استناد به عکس بالایی توضیح بدم :-اولین اتفاقی که باید بیفته، جلسه planning هست تا بک لاگ اسپرینت مشخص بشه.-بعد از اون board آماده میشه و تسک ها شروع به پیشروی میکنن و این کار تا انتهای اسپرینت ادامه داره.-هر روز صبح توی جلسات روزانه یا سرپایی درمورد کار های روز گذشته و برنامه روز جاری صحبت میشه.-بعد از اتمام اسپرینت، تو جلسه retro درباره تجربیات اسپرینت تموم شده صحبت میشه.-در صورت نیاز جلسه demo هم با حضور مدیران یا مشتری برگزار میشه و نتایج کار به نمایش گذاشته میشه.بعد از همه این کار ها، دوباره این حلقه از اول تکرار میشه و روز از نو و روزی از نو :):))))حالا که با متد اسکرام آشنا شدیم بریم یه نگاه کوچیکی به دوتا از متد های دیگه‌ی اجایلی داشته باشیم.- متد XPمتدولوژی XP که مخخف عبارت Extreme Programming یا برنامه نویسی مفرط هست.البته گیف بالا شوخیه:) این متد به معنی زیاد کار کردن نیست و با همون طرز تفکر اجایلی و مختص توسعه نرم افزار طراحی شده.این متد از practice های مختلفی که در تصویر بالا هم مشاهده میکنید تشکیل شده که بر نحوه انجام کار ها تاکید دارن. هر حلقه رنگی نشون دهنده گروهی از این practice ها هست که بصورت دوار انجام میگیرن.به چند تا از این practice ها در ادامه اشاره میکنم.تمرکز اصلی متد روی کاهش هزینه های توسعه و افزایش کیفیت محصول، به کمک feedback های دریافتی از طریق practice ها در هر بخشی از کار و پاسخ گویی سریع به نیازمندی های درحال تغییر هست.اگر نقشه راه محصول رو مثل یک جاده پر پیچ و خم در نظر بگیریم، متد XP مثل راننده ماشینی هست که دائما چشم هاش به جاده هست و با هر پیچی سریعا واکنش نشون میده و سریعا فرمون رو میچرخونه.همچنین تو این متد باید تصور کنید زمان نامحدودی در اختیار دارید و دائما در حال refactor کردن کدها، تست نویسی و ارتباط با مشتری و اعضای تیم باشید(مهم کیفیته).عکس زیر به خوبی فرایند کاری و ترتیب مراحل رو تو این متد نشون میده :XP diagramتفاوت متد اسکرام و XP :برخلاف اسکرام، اسپرینت ها تو این متد بین ۱ تا ۲ هفته تنظیم میشن.برخلاف اسکرام، تو این متد برنامه نویسی بصورت جفت یا pair انجام میشه.یعنی برنامه نویس ها، طراح ها و حتی تستر ها بصورت جفت و دوتایی با هم کار میکنن.(این یکی از مهم ترین practice هاست).یه نفر مسئول کد نویسی یا طراحی هست که بهش navigator گفته میشه و نفر دوم مسئول کنترل و ایده پردازی برای نفر کناری هست که بهش observer گفته میشه( البته چند وقت یکبار جای این دوتا با هم عوض میشه ).همچنین این دو نفر مسئول integration testing هم هستن که به معنی تست کردن کار های انجام شده بعد از اتمام کار هست و یکی دیگه از practice ها محسوب میشه.برعکس متد اسکرام، تو این متد اعضای تیم میتونن اسپرینت و بک لاگ اون رو در صورت نیاز تغییر بدن.تو متد اسکرام، تسک هایی که برای بک لاگ اسپرینت از بک لاگ محصول pull میشن رو خود اعضای تیم با نظارت اسکرام مستر مشخص میکنن؛ اما تو این متد این تسک ها رو مشتری با اولویت بندی که داره مشخص میکنه و تیم موظف هست که طبق همون بک لاگ پیش بره و به اهداف برسه.از ویژگی های این متد که خیلی بهش توجه میشه و جزو core practice های اون محسوب میشه، نوشتن تست ها و اجرای اونها قبل و بعد از برنامه نویسی و آزمایش کل سیستم هر چند روز یکبار هست( درکل کیفیت کد ها خیلی مهمه تو این متد و مدام باید مرور و تست بشن و یجورای منظور از "مفرط" همینه ).- متد kanbanاین متدولوژی از اجایل هم بر پایه همون تفکرات و البته فلسفه ی سیستم Just-In-Time شرکت تویوتا بنا شده. کانبان متدی هست که با روش های سخت گیرانه ای که داره باعث مدیریت بهتر گردش کار بین اعضای تیم میشه و کمک میکنه تا لیست کار های روزانه‌ی مشخص و شفافی، بدون multitasking داشته باشیم.همه این ها در کنار هم باعث افزایش بازدهی میشن و از این منظر بسیار مناسب تیم هایی هست که منابع محدودی دارن.نحوه کار و فرایند توسعه تو این متد بسیار نزدیک به متد اسکرام هست و وجوه مشترک خیلی زیادی دارن. اما تفاوت هایی هم دارن که اونها رو از هم جدا میکنه.تفاوت متد اسکرام و کانبان :بجای scrum master که تو اسکرام داشتیم، تو این متد agile coach یا مربی اجایل رو داریم که تقریبا همون نقش رهبر و استاد رو داره.سیستم pull از بک لاگ در این متد تفاوت هایی داره. تو متد اسکرام تسک های داخل برد یکجا وارد میشدن و همه شروع به کار و به عهده کردن تسک ها میکردن( اصلا خود لغت اسکرام اشاره به نوعی بازی فوتبال داره که تو اون همه یهو مثل گیف زیر حمله میکنن به توپ:) ).اما تو متد کانبان ورودی ها محدود هست و همه چیز بستگی به ظرفیت و توانایی تیم داره. برای مثال اگر تیم ما ۴ نفره باشه نهایتا باید ۵ تسک وارد برد بشه(مثلا). تو این متد وقتی یکی از تسک ها به مرحله done برسه از برد خارج میشه و به ستون قبلی خودش سیگنالی میده که موقع تزریق تسک جدید رسیده. اون ستون هم به ستون قبلی خودش سیگنال میده و اینطوری تسک جدیدی از بک لاگ تزریق میشه در لحظه.تو این متد محدودیت ویژه ای برای WIP یا کار های در حال انجام داریم. هر شخص نمیتونه بیشتر از یک محدوده ای تسک(معمولا ۲ تا) در حال انجام داشته باشه.جمع بندی یکم طولانی شد. اما شاید بتونه فقط مفاهیم خیلی پایه از این مواردی که بررسی شدن رو بهتون یاد بده. مواردی که برای یه برنامه نویس یا طراح یا تستر که میخواد تو یه تیم اجایلی کار کنه کافیه؛ اما برای کسی که میخواد یه scrum master بشه نه.این متدولوژی ها و سیستم ها برای خودشون دنیای دیگه ای هستن و کتاب های زیادی برای یادگیریشون منتشر شده. برای مثال اسکرام مستری یا coach بودن به قدری وسیعه که یک شغل حرفه ای محسوب میشه.اگر دوست دارید خیلی عمیق تر این متد ها و سیستم ها رو یاد بگیرید و تبدیل به یه master بشید، پیشنهاد میکنم سمت دوره ها و کتاب های تخصصی برید.اگر خوشتون اومد لایک یادتون نره... اگر هم ایرادی(چه گرامری چه علمی) تو مقاله دیدید خوشحال میشم درجریانم بزارید تا اصلاحش کنم. beardy developer beardy developer Mon, 02 Aug 2021 18:56:41 +0430 https://virgool.io/@beardydeveloper/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-apollo-client-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-state-manager%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-kha6ed4ytddr قبل از شروع، اگر قسمت اول رو مطالعه نکردید حتما اینکار رو بکنید و برگردید: https://virgool.io/@mohammad.mirzaei/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-apollo-client-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-state-manager%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-i76qhrt5okfd بریم سراغ قسمت دوم مقاله یا همون هندل کردن client local state هامون با آپولوی عزیز.قرار نیست به بحث های قبلی پرش داشته باشیم و یک راست میریم سراغ راه های مختلف کنترل کردن استیت های لوکالمون :1- Local only fieldsساده ترین روش برای ذخیره و دسترسی مجدد به یک استیت لوکال همین روش هست.تو این روش همه چیز شبیه یه کوئری عادی هست با این تفاوت که با قرار دادن یه directive به اسم client@ جلوی فیلد مورد نظر از کوئریمون، آپولو دیگه برای دریافت اون ریکوئستی به سرور نمیزنه و میره از کش خودش میخونه و در نتیجه همه چیز سمت فرانت هندل میشه.به عنوان مثال میخوایم استیت مربوط به dark mode اپ رو ذخیره و بعدا آپدیت کنیم. بریم سراغش:اولین کاری که باید بکنیم نوشتن کوئریمون هست :همونطور که گفتم با این directive آپولو میفهمه که این یه فیلد لوکال هست.به نظرتون الان میتونیم از این کوئری استفاده کنیم و مقدار isDarkMode رو بگیریم ؟قطعا نه.اما چرا ؟ مشکل اینه که این فیلد مقدار اولیه ای نداره و عملا اگر بخوایم بخونیمش یه undefined میخوره تو صورتمون.راه حل چیه ؟ راه حل store کردن مقدار پیش فرض این فیلد داخل cache آپولو هست تا یه مقدار اولیه ای داشته باشیم موقع لود اپمون و به این مشکل نخوریم.برای اینکار 2 تا روش داریم :یه روش اینه که مستقیما داخل InMemoryCache کانفیگ cache که به client پاس دادیم مقدار دهیش کنیم ( قرار نیست اینجا آپولو رو یاد بگیریم و اگر نمیدونید درباره چی حرف میزنم یه سری به داک آپولو بزنید ) :*تو عکس بالا typePolicies به ما اجازه دسترسی، آپدیت و تغییر فیلد هامون رو بسته به نیاز ها و شرایط مختلفی که داریم میده.هر فیلدی رو که بخوایم تغییر بدیم، باید داخل آبجکت fields که داخل آبجکتی همنام تایپی قرار داره که شامل فیلد مورد نظر و هدف ما هست اینکار رو انجام بدیم.تو مثال ما، فیلد isDarkMode داخل تایپ Query هست و از همین طریق میتونیم بهش دسترسی پیدا کنیم و کاستومایزش کنیم.* این تایپ ها جزو meta data های graphQl هستن و ربطی به آپولو ندارن. کارشون هم دسته بندی فیلد ها و یه سری کار های دیگه هست.تو مثال ما چون صرفا یه کوئری ساده بدون ست کردن متا دیتا زده شده، فیلد ما زیرمجموعه تایپ Query هستن. اما اگر کوئری ما از سمت سرور دیتا بگیره، برای دسترسی به تایپ فیلد ها میتونید به typename__ که معمولا همراه ریسپانس میاد و یه متادیتا هست مراجعه کنید. مثلا تایپ response زیر Episode هست که ازش یه لاگ گرفتم داخل کنسول : console logو اما یه روش دیگمون برای مقدار دهی هم اینه که cache instance آپولو رو rewrite کنیم و به دیتای کوئری که داریم مقدار دیفالت بدیم :در هر دو روش، حالا مقدار اولیه فیلد ما false هست و دیگه آندفایند دریافت نمیکنیم :))نکته قابل توجه اینه که میتونیم این فیلد های local only رو درکنار فیلد های سرور هم قرار بدیم و همزمان هر دورو داخل کوئریمون بخونیم. این کار هم دقیقا مثل حرکتی هست که بالاتر زدیم و تنها تفاوتی که داره اینه که فیلدی که داریم همسایه فیلد های دیگه میشه :حالا در کنار فیلد allEpisodes که از سمت سرور میاد، به isWatchable هم دسترسی داریم که سمت خودمون مقدار دهی میشه و میتونیم با کمک اون مشخص کنیم که فلان اپیزود قابل مشاهده هست یا نه.برای مقدار دهی هم میتونید از یکی از دو روش بالا ( پیشنهادم روش دوم هست ) استفاده کنید.( لازم به ذکرم که توی روش اول میتونید فیلد های لوکال رو بر اساس ریسپانس سرور مقدار دهی کنید اما بهش نمیپردازیم چون بحث تخصصی تر و حجیم تر میشه؛ در صورت تمایل یه سری به داک آپولو بزنید در این زمینه )آپدیت کردن فیلد ها اگر بخوایم dark mode رو فعال کنیم چیکار کنیم ؟ چطور میتونیم این مقدار رو به true تغییر بدیم ؟خیلی راحت؛ فقط کافیه مجددا به cache آپولو دسترسی پیدا کنیم و مقدار جدید رو جایگزین مقدار قبلی کنیم.*(در نظر داشته باشید که برای آپدیت کردن مستقیم فیلد هامون بعد از کلیک روی یک دکمه یا مورد مشابه، باید طبق روش دوم پیش بریم تا با instance در اختیارمون، هرجایی از اپ بتونیم عملیات باز نویسی و آپدیت رو انجام بدیم؛ در غیر اینصورت قادر به آپدیت کردن فیلد هامون نخواهیم بود در صورت استفاده از روش اول )*خب حالا چطوری آپدیت رو انجام بدیم؟ اینطوری :توی عکس بالا بعد از دریافت مقدار اولیه یا current data، بعد از کلیک روی دکمه مورد نظر شروع به rewrite کردن client میکنیم و مقدار قبلی رو reverse و تبدیل به true میکنیم؛ حالا باید تم دارک ما فعال بشه :)2- Reactive Variablesاین روش، روش مورد علاقه من برای ذخیره و کار با استیت های لوکال تو آپولو هست. خیلی تر و تمیز و مااااهه. بریم باهاش آشنا بشیم که شما هم عاشقش بشید :)کمی بالا تر گفتم که درصورت مقدار دهی فیلد هامون داخل typePolicies، قادر به آپدیت کردن اونها نیستیم در آینده و همیشه ثابت هستن. این اصلا خوب نیست چون عملا بدردمون نمیخورن و الکی این همه راهو اومدیم.ما به عنوان یه state manager انتظار داریم که مقادیری که ذخیره کردیم قابل تغییر باشن.اما این مشکل هم حل شدنیه. چطوری؟ با یکی دیگه از روش های store کردن آپولو به اسم reactive variable.همون طور که از اسمش پیداست، تو این روش مقادیر واکنش گرا و قابل تغییری خواهیم داشت به عنوان مقدار فیلد هایی که داخل typePolicies مقدار دهی کردیم. و بسته به اتفاقاتی که تو اپ ما میفته میتونیم تغییرشون بدیم.مثال زیر رو که تو بخش اول هم داشتیمش دوباره در نظر بگیرید :همون طور که قبلا هم گفته شد، مقدار اولیه dark mode ما false هست، اما غیر قابل تغییر و ایستا هست. یعنی نمیتونیم این false رو تبدیل به true یا هرچیز دیگه ای بکنیم تا تم ما عوض بشه ( و مجبور شدیم از روش rewrite کردن cache استفاده کنیم ).حالا با کمک reactive variable ها میتونیم این مقدار رو داینامیک و قابل تغییر در نظر بگیریم.قبل از هرچیزی برای تمیز کاری بیشتر، قراره یه فایل مجزا برای این variable ها تعبیه کنیم و همه رو اونجا نگهشون داریم ( درست مثل کاری که تو ریداکس میکردیم و برای اکشن ها و استور ها و ... فایل مجزا میساختیم ).اسم فایلتون رو store یا storage یا هرچیزی که عشقتون میکشه بزارید :) و داخلش :حالا دوباره برمیگردیم سراغ cache مون :تا اینجای کار فقط مقدار اولیه که همون false هست رو یه مدل دیگه ست کردیم. پس این reactive بودنش کجاست ؟برای آپدیت کردن، فقط کافیه هرجایی که لازم داریم ( مثلا بعد از کلیک روی یه دکمه ) مقدار جدید رو پاس بدیم به variable مورد نظرمون( حتی میتونیم مقدار قبلیش رو هم ازش بگیریم و طبق اون تغییرش بدیم ) :ایزی ایزی تامام تامام :) حالا یه ریداکس بدون نیاز به ریداکس داریم تو آپولومون ( جواد خیابانی )ساختار پروژهاین بخش از مقاله زیاد ربطی به آپولو نداره و بیشتر بحث تمیز کاری و با شخصیت بودن کد هامونه :دیاگه به کد های بالا و نحوه ارتباطشون به هم دیگه دقت کرده باشین متوجه میشین که زیادی بهم متصل هستن و اگر بخوایم طبق روال بالا پیش بریم خیلی گند بالا میاریم و کدمونو خودمون هم نمیتونیم بخونیم اگر مقیاس پروژه کمی بزرگ تر بشه.برای همین تصمیم گرفتم یه structure یا ساختار پیشنهادی بهتون ارائه بدم که اگر دوست داشتین طبق اون پیکربندی کنید فایل های مربوطه رو:فایل store.js : این فایل محل نگهداری reactive variable هامون هست تا دم دست تر باشن و جایی رو شلوغ نکنن. ( حتما اکسپورتشون کنید چون لازمشون داریم جاهای دیگه )فایل cache.js : این فایل هم فایل اصلی ما و محل کانفیگ کردن مموری و کش آپولو هست. پس کانفیگ cache رو منتقل کنید توی این فایل و حتما اکسپورتش کنید. البته یادتون نره که چون به variable های فایل بالایی نیاز دارید، میتونید همینجا اول فایل ایمپورتشون کنید و داخل cache استفادشون کنید.فایل mutations.js یا actions.js : این فایل هم مختص نگهداری فانکشن هایی هست که مسئول آپدیت کردن variable هامون هستن تا داخل کامپوننت هامون پخش و پلا نشن و منسجم و در دسترس باشن. برای استفاده از این فانکشن ها کافیه اکسپورتشون کنید و هرجایی که خواستید ایمپورت و کالشون کنید و حتی بهشون پارامتر پاس بدید و داخل اکشن دریافت کنید و ... کارای دیگه.( یادتون نره برای آپدیت کردن variable ها بهشون نیاز دارید و لازمه که از فایل store ایمپورتشون کنید )خب این هم از بخش دوم مقاله و بررسی local state های آپولو. امیدوارم بدردتون خورده باشه و تونسته باشم چیزی به دانشتون اضافه کنم.تا یه مقاله توپ دیگه مواظب خودتون و استیت هاتون باشید. ( لایک هم یادتون نره ) beardy developer beardy developer Fri, 30 Jul 2021 18:21:11 +0430 https://virgool.io/@beardydeveloper/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-apollo-client-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-state-manager%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-i76qhrt5okfd اومدم براتون از شگفتی های یه لایبرری خفن برای کار با graphQl بگم که علاوه بر فچ کردن کوئری های سمت سرورتون و کش کردن اون ها، میتونه نقش یه global state manager رو هم بازی کنه تا دیگه نیازی به ریداکس و ... برای استیت های لوکالتون هم نداشته باشید چه رسد به سرور استیت هاتون.اگر شما هم داخل پروژه‌تون با graphQl سر و کار دارید و سرورتون هم با apollo-server سر و کار داره، بهترین گزینه برای سرو کله زدنتون با کوئری ها apollo-client هست ( چقدر سرو کله )بجز آپولو از چی میتونیم استفاده کنیم ؟توی شرایط عادی و سنتی اگر بخواید دیتایی که از سرور دریافت میکنید یا استیت های local خودتون رو داخل اپلیکیشنتون بین تمام کامپوننت های یو آی share کنید و از هرجای اپ بتونید دیتای قبلی رو تغییر بدید و جایگزین قبلی ها بکنید، مجبورید دست به دامان گلوبال استیت منیجر ها بشید و گاها برای caching از ابزار های کشینگ اون ها استفاده کنید که اسم بعضیاشون رو تریلی هم نمیکشه :دیریداکس علیه السلامریداکس چیه و چطوری کار میکنه ؟ یکی از این اسم گنده ها و گولاخ ها redux هست که کمتر کسی پیدا میشه که اسمشو نشنیده باشه تاحالا.ریداکس یک store container جاوا اسکریپتی هست که وظیفه ذخیره سازی و سازمان دهی استیت های اپلیکیشن و به بیانی هندل کردن یک state management رو به عهده داره. عملکرد ریداکس کمی پیجیده هست و به المان های زیادی وابسته هست که میخوایم بررسیشون کنیم ( البته قرار نیست آموزشی ریداکس رو هم بنویسیم و با مفهوم و تعریف و کانسپت اجزای مختلفش چیه ).عکس بالا جریان کلی کارکرد ریداکس رو نشون میده که به ترتیب شامل مراحل زیر هست:۱- یک action از کامپوننت یا UI ارسال یا به اصطلاح dispatch میشه که شامل اطلاعات مربوط به بلایی هست که قراره سر state بیاد ( میتونه ذخیره سازی یا آپدیت و یا حتی خالی کردن اون باشه )۲- اگر اکشن یه اکشن عادی بود که فقط قرار بود اسم ممد رو به اصغر تغییر بده زیاد مشکل ساز نبود؛اما وقتی قراره بصورت async چیزی رو از سرور بگیره و بعد از رسیدن پاسخ اون بره سمت store تا اون پاسخ رو جایگزین اسم ممد بکنه اینجاست که middleware وارد عمل میشه و بین اکشن و reducer قرار میگیره تا منتظر فچ شدن دیتا بمونه و بعد از اون اکشن مربوطه رو به همراه دیتای گرفته شده از سرور دیسپچ کنه.۳- و اما reducer عزیز که وظیفه تغییر و normalize کردن استیت هارو به عهده داره( البته این خودمون هستیم که این کار رو انجام میدیم )۴- در نهایت state به روز دوباره به کامپوننت یا UI ما برمیگرده و آماده استفاده میشه.تا اینجای کار با یه حساب سر انگشتی اگر بخوایم عکس بالا رو داخل کد هامون پیاده بکنیم همه چیز وابسه به فایل یا دایرکتوری اکشن ها، ردیوسر ها و فایل کانفیگ store خواهد بود( به علاوه هوک های ریداکس برای گرفتن این دیتاها داخل کامپوننت هامون )حالا موارد بالا رو یادتون باشه تا بریم یه مثال واقعی از ریداکس و فچ کردن دیتای async با middleware هاش رو ببینیم.( دیتا مربوط به کوئری graphQl هست ها )CODE-1بصورت خلاصه توی middleware بالا دیتا رو از کوئری GET_USER دریافت میکنیم و بعد اون رو به اکشن های SUCCESS و ERROR پاس میدیم تا سمت ردیوسر بتونیم استیت های مربوط بهشون رو آپدیت کنیم( مثلا یه لودینگ ست کنیم یا پیغام خطا نشون بدیم و ...)درواقع استیت isLoading در ابتدا true هست و بعد از گرفتن دیتا false میشه تا بتونیم داخل کامپوننت یه لودینگی ست بکنیم :(تازه همه اینا به کنار اگر بخوایم دیتایی که از سرور گرفتیم رو cache کنیم مجبوریم از ابزار های دیگه ای مثل redux-persist استفاده کنیم و کلی کانفیگ بنویسیم براش تا بتونیم استیت های سمت سرور رو کش کنیم...ریداکس که کار میکنه :/ پس چرا apollo ?بله ریداکس کار میکنه... به خوبی هم کار میکنه و مشکلی وجود نداره.البته تا وقتی apollo-client عرض اندام نکنه که وقتی بکنه ریداکس دیگه حرفی برای زدن توی پروژه هایی که با graphQl سروکار دارن نداره.آپولو یه لایبرری state manager و cache enginer همه جانبه جاوا اسکریپتی هست که به ما اجازه هندل همزمان استیت های لوکال و ریموت رو میده.به کمک آپولو میتونیم دیتای مورد نیازمون رو دریافت، کش، و تغییر بدیم اون هم با آپدیت خودکار UI مربوطه.چرا apollo ?سادگی در استفاده : آپولو سینتکس و لاجیک خیلی ساده ای داره و در حالت عادی با یکی دو خط کد میره دیتا رو همراه وضعیت هاش بر میداره میاره.دیتا فچینگ declarative : آپولو به طور معجزه آسا و هوشمندانه ای وضعیت های فچینگ رو خودش برامون track میکنه و برمیگردونه؛ یعنی دیگه لازم نیست دوتا اکشن و کلی کد و شرط برای گرفتن loading و error بنویسیم و خود آپولو این کارو برامون انجام میده :)کشینگ ساده : آپولو سیستم caching قدرتمند و باهوشی داره که با چند خط کد قابل پیاده سازی هست و اونقدر باهوشه که اگر یک کوئری رو برای بار دوم ارسال کنید دیگه برای دریافت دیتاش سمت سرور نمیره و مستقیما از cache خونده میشه :)نورمالایز خودکار : برعکس ریداکس که خودمون مسئول نورمالایز کردن - نورمالایز یعنی مرتب سازی فیلد ها- و همگام سازی استیت هامون هستیم آپولو حتی این بار رو هم از دوش ما برداشته و خودش اینکار رو برامون انجام میده( لایبرری انقدر با شعور آخه؟ )ترکیب دیتای لوکال و ریموت : آپولو این قابلیت رو برامون فراهم میکنه که در کنار فیلد های سرور کوئریمون فیلد های لوکال هم بنویسیم که کاملا سمت فرانت نگهداری میشن و ربطی به بک ندارن.یعنی آپولو علاوه بر اینکه یه لایبرری برای فچ کردن کوئری هامون هست میتونه یه لوکال استیت منیجر عالی هم باشه و هیبریدی عمل کنه برامون.ضمنا آپولو قابلیت کار با rest رو هم داره که نیازی به ابزار دیگه ای مثل axios هم نداشته باشید حتی.آپولو چه تفاوت هایی با ریداکس داره ؟Redux vs Apolloتوی آپولو دیگه خبری از reducer و action و store config و این داستان ها نیست. ایزی ایزی :)تمامی وظایف اکشن هارو hook ها و گاها متد های خوشگلش انجام میدن که هم میتونن دیتا رو فچ کنن و هم دیتای سمت سرور رو mutate کنن.چیزی به اسم middleware دیگه معنی نداره و همه چیز async عمل میکنه.تمامی وظایف reducer ها و تغییرات استیت ها و نورمالایز اون ها رو هم خود آپولو بصورت خودکار برامون انجام میده و نیازی نیست دستمونو آلوده کنیم.و اما داخل آپولو بجای یک store container همه چیز مستقیما داخل cache مرورگر هندل میشه و از هرجای اپ میشه به راحتی دیتارو مستقیما از کش دریافت کنیم.بریم ببینیم آپولو چطوری کار میکنه:مطابق شکل بالا مراحل زیر انجام میشن : ۱- اولین کار نوشتن کوئری سمت UI هست که شامل فیلد های درخواستی از سرور هست.۲- آپولو این کوئری رو سمت سرور میفرسته تا دیتای اون رو دریافت بکنه ( بالاتر هم گفتم که آپولو میتونه همزمان با api های rest هم کار بکنه ).۳- بعد از دریافت دیتای سرور نوبت به دیتای local میرسه که دریافت یا اصطلاحا read بشه( دیتای local-only باید منتظر دیتای ریموت بمونه)۴- در نهایت دیتا به UI ارسال میشه و کامپوننت های مربوطه آپدیت میشن.حالا اگر موارد بالا رو در نظر بگیریم و بخوایم ببینیم مثال CODE-1 بالا که با ریداکس نوشته شده بود چطوری با آپولو به سادگی نوشته میشه به مثال زیر توجه کنید و سر به بیابان بزارید :)CODE-2همون طور که بالا تر گفتم حتی استیت های فچینگ کوئری هم بصورت خودکار در اختیارمون قرار میگیرن و فقط با یک خط کد و به کمک هوک useQuery آپولو از شر ده ها خط اکشن نویسی و شرط گذاری و میدلویر گذاری خلاص شدیم *ــــ*( البته فراموش نکنید که کوئری ها برای اسفاده با آپولو باید داخل تمپلیت gql خود آپولو نوشته بشن که در کنار همین useQuery میشه ایمپورت و استفادش کرد )تا اینجای کار فقط با استیت های سمت سرور و ریموت کار کردیم و وارد بحث local state ها و انواع اونها و همینطور بررسی عملکرد cashing نشدیم چون یکم طولانی شد مقاله...تا همینجا داشته باشید مقاله رو به زودی توی قسمت دوم میریم سراغ این مباحث و خیلی بیشتر با آپولو حال میکنیم. https://virgool.io/@mohammad.mirzaei/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-apollo-client-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-state-manager%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-kha6ed4ytddr beardy developer beardy developer Mon, 19 Apr 2021 01:06:04 +0430