1. مقدمه:
در قسمت اول از این مجموعه به طور اجمالی با Micro Front-End آشنا شدیم و دیدیم نحوه مدیریت تیم و تقسیم وظایف به چه شکلی در این روش انجام می‌شود. در نهایت بررسی کردیم ترکیب صفحات در این روش به چه شکلی انجام می‌شود. حال که ایده بهتری در مورد چیستی Micro front-endها داریم، بیایید با هم نگاهی دقیق‌تر به مزایای این روش توسعه و دستاورد‌های آن داشته باشیم.
2. سرعت بالا در افزودن ویژگی‌های جدید:
به جرات اولین دلیل تیم‌های فنی از انتخاب Micro front-end برای توسعه نرم‌افزارها سرعت بالای توسعه در این روش است.
در یک تیم معمول که از میکروسرویس‌ها برای توسعه نرم افزار استفاده می‌کنند تیم‌های زیادی برای افزودن یک ویژگی جدید درگیر می‌شوند. فرض کنید تیم کسب و کار تصمیم می‌گیرد برای افزایش قدرت خود در بازار و تبلیغات بهتر نوع جدیدی از بنر‌ها را ایجاد کند. برای این کار آن‌ها به سراغ تیم سرویس محتوا می‌روند و ایده‌های خود را با آن‌ها مطرح می‌کنند. و از آن‌ها می‌خواهند ساختار داده‌ها را به گونه‌ای تغییر دهند تا پیاده سازی ایده بنر جدید امکان پذیر باشد. اما مسلما تغییر ساختار داده‌ها به تنهایی کاربرد ندارد و باید جلساتی بین تیم محتوا و front-end برگزار شود تا در مورد نحوه انتقال داده‌ها به front-end و نمایش و مدیریت آن تصمیم گیری کنند. جلساتی تشکیل می‌شود و ویژگی‌ها لیست می‌شود. هر تیم مسئولیت‌های خود را در نظر می‌گیرد و در طول اسپرینت‌های آتی سراغ پیاده‌سازی‌های خود می‌رود. اگر همه چیز به خوبی پیش‌برود بعد از چند اسپرینت محصول آماده بهره‌برداری است. اما اگر کار دچار مشکل شود نیاز به چندین و چند جلسه بین تیمی است تا تیم‌ها عملکرد‌ها و نیاز‌های خود را با سایرین تنظیم کنند.
اینجا به سادگی یکی از تفاوت‌های روش Micro front-end قابل مشاهده است. با اینکه کاری که قرار است انجام شود، تغییری نمی‌کند، اما حضور افراد درگیر در انجام یک کار در یک تیم باعث می‌شود، نیاز‌ها خیلی سریع‌تر تشخیص داده شود و به جای برگزاری جلسات بین تیمی زمانگیر، با چند گپ و گفت درون تیمی کار به خوبی پیش برود. درون تیم‌ها روابط بسیار صمیمی‌تر است و از جو رسمی جلسات بیرون تیمی خارج می‌شویم. نیاز به کارهای جانبی رسمی مثل صورت جلسات و ... کاسته می‌شود و در نهایت نیازی نیست تا به اعضای تیم دیگری در مورد اولویت کار‌ها و ... توضیح دهیم و توافق کنیم.
3. حذف گلو‌گاه Front-End:
در اغلب روش‌های توسعه نرم افزار مطرح برای Scale کردن front-end فکری نشده است. در تصویر بعدی مشاهده می‌کنید که در سه روش مرسوم در توسعه نرم افزار، حتی وقتی از میکروسرویس‌ها استفاده می‌کنیم کماکان یک لایه front کاملا Monolithic داریم.
در Micro Front-end حتی front-end هم به چندین قسمت کوچک تقسیم می‌شود که مزایای زیر را برای ما به همراه خواهد داشت:
بیایید کمی با جزئیات بیشتری این مطالب را بررسی کنیم.
4. توانایی تغییر:
به عنوان یک توسعه‌دهنده و مهندس نرم‌افزار طی این سالها این مورد را به خوبی دریافته ام که یادگیری مستمر و به کارگیری دانش‌جدید تنها راه پیشرفت در این حرفه است. این نیاز به تغییر و یادگیری و به روز رسانی هرچه به کاربر نهایی نزدیک‌تر باشد، بیشتر احساس می‌شود و مسلما نزدیک‌ترین بخش به کاربر نهایی لایه front-end است. ابزارها و تکنولوژی‌ها در این لایه به سرعت تغییر می‌کنند. سال 2005 با معرفی AJAX جهان متحول شد و فکر می‌کردیم به حد‌نهایی پیشرفت رسیده ایم، اما فاصله بین ریلیز‌های فریم‌ورک‌ها و تکنولوژی‌های front-end این نظریه را تایید نمی‌کند. برای مثال نیم نگاهی به فاصله زمانی انتشار نسخه‌های Angular داشته باشید تا احساس دقیق‌تری به سرعت انتشار داشته باشید.
از سال 2005 که تنها زیبایی و مرتب بودن یک صفحه کفایت می‌کرد تا امروز که طراحی و پیاده سازی front-end تبدیل به کاری بسیار حساس و تخصصی شده است روزگار زیادی سپری نشده است. از روزگاری که front-end صرفا بخشی بی اهمیت از رزومه توسعه دهنده‌ها بود تا امروز که پیاده سازی front-end نیاز به یک رزومه کامل و قوی دارد تنها 15 سال گذشته است که این سرعت پیشرفت واقعا اعجاب آور است. ( البته با سرعت رشد دلار قابل مقایسه نیست و خدا رو شکر به لطف دوستان ما سرعت‌های بالاتری تجربه کردیم :-|)
این روز‌ها دیگر front-end فقط html و css نیست و یک توسعه دهنده متخصص front-end باید مطالب زیادی بداند مثلا باید بداند طراحی responsive چیست و چگونه انجام می‌شود. باید حداقل یک فریم ورک مثل Angular را مسلط باشد و با react و VUنیز باید آشنا باشد. با استاندارد‌های روز و تغییرات دائمی آن‌ها و پشتیبانی آن‌ها توسط بستر‌های مختلف باید کاملا آشنا باشد.
4.1. میراث بد
کد‌های مشکل دار و قدیمی همیشه جز معضلات یک تیم نرم‌افزاری است و این مشکل در Front-End نیز قابل اجتناب نیست. هرچه قابلیت تغییر و بهینه‌سازی در این لایه را بالاتر ببریم، می‌توانیم به جای مجبور کردن نیرو‌های ارزشمند به تغییر و نگهداری کد‌های قدیمی از آن‌ها در کارهای جدید و بهتر بهره ببریم که باعث بالارفتن کیفیت سیستم و انگیزه اعضای تیم نیز می‌شود. هرچه سیستم بزرگ‌تر و گره خورده تر باشد این به روز رسانی سخت‌تر خواهد شد. برای مثال github نزدیک به 1 سال زمان صرف کرد تا کل سیستم خود را از Jquery خلاص کند.
وقتی در دنیای رقابتی امروز زندگی می‌کنید باید بتوانید خیلی سریع ویژگی‌هایی متناسب با تکنولوژی روز را به نرم‌افزار خود بیافزایید. این مهم است که افزودن ویژگی‌های جدید با تکنولوژی روز و جدید انجام شود. استفاده از تکنولوژی روز به این معنی نیست که شما مجبور هستید برای هر تغییری کل سیستم را باز نویسی کنید. بلکه باید بتوانید روی موج فناوری حرکت کنید.
4.2. تصمیمات و تاثیرات کوچک:
توانایی اینکه در یک تیم کوچک برای بخشی از کار بتوانید تکنولوژی جدید و دلخواه خود را انتخاب کنید بدون اینکه نیاز باشد با جامعه بزرگی طرف شوید و مجبور به اعمال تغییرات بسیار زیاد در بخش‌های زیادی از نرم افزار باشید ارزشی است که به سادگی به دست نمی‌آید. Micro Front-end این امکان را به شما می‌دهد تا تصمیمات بزرگی را در تیم‌های کوچک و محلی بگیرید.
فرض کنید که بخشی از نرم افزار بسیار حساس است و باید کاملا از باگ عاری باشد. اما ماهیت جاوا اسکریپت امکان خطایابی را مشکل می‌کند. بنابر این تیمی که مسئول انجام این کار است تصمیم می‌گیرد به سراغ typescript رفته از قابلیت کامپایل شدن آن و یافتن برخی خطا‌ها و جلوگیری از بروز برخی خطا‌های دیگر استفاده کند. اگر روش عادی توسعه را استفاده کرده باشیم باید کل برنامه از این روش استفاده کند که خوب سربار یادگیری و بازنویسی زیادی را به سیستم تحمیل می‌کند. اما در Micro front-end تنها تیمی که مسئولیت حیاتی دارد می‌تواند بهای این کار را بپردازد.
5. مزایایی عدم وابستگی:
خودمختاری یکی از دستاورد‌های عدم وابستگی است. به سادگی و بدون نیاز به تایید سایر تیم‌ها یک تیم می‌تواند عملکرد خود را تصحیح کند یا تغییر دهد. هرچند در صورتی که همه تیم‌ها از یک روش و تکنولوژی هم استفاده کنند باز هم این خود مختاری در مواقعی می‌تواند گره گشا باشد.
هنگامی که می‌گوییم در روش Micro Front-end یک سیستم بدون وابستگی است، نیاز است که یک بخش همه نیاز‌های خود را تامین کند. یعنی HTML, CSS, Script, Data و هر نیازمندی دیگری که برای کار کردن صحیح داشته باشد. به این روش تیم ها می‌توانند یک Fragment را بدون اینکه نیاز به تغییر بخش دیگری باشد تغییر دهند و منتشر کنند و نرم‌افزار به سادگی به روز می‌شود.
شاید با خود فکر کنید که تولید Front-end در کنار Back-end و اینکه هر سرویس به جای خروجی دادن داده‌ها باید یک ماژول کامل همراه با UI را برای خروجی ارسال کند کار سنگینی است که باعث خواهد شد سرویس‌ها از وظیفه اصلی خود و سبک بودن دور شوند. اما باید به این نکته دقت کنیم که این روش، همراه میکروسرویس‌ها استفاده می‌شود که خود سرویس‌های کوچک و قابل توزیع ایجاد می‌کند و در صورتی که نیاز باشد می‌توان بسیار راحت یک سرویس را Scale کرد و این Scale شدن front-end را هم در بر می‌گیرد. ممکن است با خود فکر کنید اینکه برای یک صفحه لازم است چندین فریم‌ورک بارگذاری و استفاده شود و بخش‌هایی که می‌تواند به سادگی مشترک باشد چندین و چند بار دانلود می‌شود کمی غیر بهینه است و می‌تواند ما را دچار مشکل کند که فکر اشتباهی نیست. البته برای این مشکلات راهکارهایی در نظر گرفته شده است و شاید در آینده در مورد این مشکل و برطرف کردن آن مطلبی را با هم بررسی کنیم.
6. معایب Micro front-end:
مثل هر روشی استفاده از این روش نیز معایبی دارد و نمی‌توان آن را بدون عیب و مدینه فاضله دانست و باید با دانستن مزایا و معایب این روش در مواقع صحیح از آن استفاده کنیم.
6.1. افزونگی:
شاید از هر فرد تازه کاری در دنیای فناوری اطلاعات بپرسید بزرگترین اتفاقی که باید از آن اجتناب کنیم چیست به شما پاسخ دهد افزونگی. این افزونگی در بخش‌های مختلف به شکل‌های متفاوت حذف می‌شود. در دیتابیس‌های رابطه با نرمال سازی. در برنامه نویسی شی گرا با ارث بری و ... هر توسعه دهنده‌ای میداند بخش‌های تکراری کد را باید در قالب یک ماژول مشترک توسعه دهند و در اختیار تمامی قسمت‌ها بگذارد. با این روش هم کد‌های کمتری می‌نویسیم و هم تغییر و نگهداری سریع‌تر و کم خطا‌تری را تجربه خواهیم کرد. به عنوان یک توسعه دهنده در این سالها مغز و چشم ما یادگرفته تا تکرار‌ها را پیدا کند و سریع برای رفع آن‌ها به دنبال راه حل باشد. وقتی چندین تیم تلاش می‌کنند کارهای کاملا مستقل ایجاد کنند تکرار بخش غیرقابل اجتناب سیستم است. باید بدانیم هر دستاوردی بهایی دارد و بهای استقلال هم بعضا تکرار است.
6.2. ناهمگونی و عدم تجانس:
قبل از این گفتیم که هر تیم می‌تواند به سادگی تکنولوژی و ابزار دلخواه خود را انتخاب و استفاده کند. خیلی هم خوب و عالی. اما واقعا نیاز داریم که اینچنین جهنمی از تکنولوژی را برای خود ایجاد کنیم؟ در این روش اگر توسعه دهنده‌ای قرار باشد از تیمی به تیم دیگر برود تقریبا هیچ چیز با خود نمی‌برد. با توجه به تفاوت حیطه فعالیت قاعدتا بیزنیس را به خوبی نمی‌شناسد و در این شرایط تنها داشته توسعه دهنده دانش فنی است که باز آن هم بی فایده می‌شود.
همین چند روز پیش در حال بررسی پروژه ای مربوط به یکی از سازمان‌های بزرگ بودم که در آن به طور همزمان از EF, Dapper, NHibernate, Angularjs, Angular8, MSMQ, RabbitMQ, NServicebus, Masstransit و ... استفاده شده بود. واقعا دیدن پروژه چیزی بیش از سرگیجه و به این نتیجه رسیدن که تیم توسعه بیشتر به دنبال تست و یادگیری بوده تا انجام کار نتیجه دیگری نداشت.
7. نتیجه:
مثل هر روشی توسعه Micro front-end هم مزایا و معایب خاص خود را دارد. در این سری مسائل سعی می‌کنیم با روش پیاده سازی به این روش آشنا شویم و مثل یک ابزار خوب در کنار سایر ابزارها از آن نگهداری کنیم و هر زمان نیاز بود از آن استفاده می‌کنیم نه همیشه.
