<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های نوید معدن نژاد</title><link>https://virgool.ir/feed/@navid_mnzh</link><description>یک برنامه‌نویس بدبخت، عاشق علم، تاریخ و موسیقی</description><language>fa</language><pubDate>2026-11-12 01:40:07</pubDate><image><url>https://files.virgool.ir/upload/users/216541/avatar/xOLDSZ.jpg</url><title>نوید معدن نژاد</title><link>https://virgool.ir/@navid_mnzh</link></image><item><title>میکروفرانت، انقلابی در توسعه سمت کاربر</title><link>https://virgool.ir/@navid_mnzh/میکروفرانت-انقلابی-در-توسعه-سمت-کاربر-bxbvn43be20q</link><description>هرروز که میگذره، شاهد گسترده‌تر شدن و پیچیده‌تر شدن سیستم‌ها هستیم. سیستم‌های تحت وب هم از این قاعده مستثنی نیستن. یک فروشگاه تحت وب رو در نظر بگیرید (البته با دید فرانت اند!). شاید ساده‌ترین قسمت این فروشگاه، صفحاتی مثل درباره ما باشه که صرفا از چند متن و عکس ساده تشکیل شدن. صفحات همینطور پیچیده و پیچیده‌تر میشن، تا به غول‌هایی مثل صفحه جست و جوی پیشرفته یا پنل کاربری برای هر مشتری یا فروشنده می‌رسن! اون اوایل طبیعی بود که بیایم و تمامی این مجموعه رو، هرچقدرم که پیچیده باشه، تحت یک سیستم بالا بیاریم. ولی خب این مسئله باعث کاهش شدید قابلیت مقیاس‌پذیری (scalability) و افزایش شدید هزینه‌های مربوطه میشد (چه مالی و چه زمانی).اینجا بود که یک معماری خاص به نام معماری میکرو-فرانت یا Micro-Front به وجود اومد. این معماری، برگرفته از مفهوم کلی‌تر معماری میکروسرویس هست، معماری‌ای که بر طبق اون، یک سیستم نرم‌افزاری به قسمت‌های کوچیک، مقیاس‌پذیر و قابل مدیریتی به نام سرویس یا Service تقسیم میشه.بنابراین معماری میکروفرانت، میگه آقا! اون سیستم غولی رو که داری میسازی، حتما و حتما به اجزای کوچک‌تر و تا حد امکان مستقل تقسیمش کن.حالا بررسی کنیم و ببینیم معماری میکروفرانت چه فوایدی برای ما داره؟فرض کنید که یک وب‌سایت شامل دو سرویس main و dashboard داریم. تو سرویس main، ساختار اصلی سایت رو میبینیم، چیزی که در نتایج گوگل نمایش داده میشه. سرویس dashboard، همونطور که از اسمش پیداست، پنل مدیریت وب‌سایت رو در برمیگیره. چیزی که فقط مدیران سایت یا کاربران ثبت‌نام شده باهاش سر و کار دارن.این دو سرویس کاملا به شکل جداگونه‌ای توسعه پیدا می‌کنن و در نهایت توسط روش‌های مخصوص به خودشون، به هم متصل میشن.استقلال تیم‌های فعال بر پروژهافراد و تیم‌های فعال بر پروژه، دارای آزادی مناسبی تو انجام کارشون هستن. ازونجایی که dashboard و main، کمترین وابستگی رو به هم دارن، دیگه لازم نیست تیم توسعه dashboard، بابت هر تغییر یا مسئله کوچیکی مزاحم تیم توسعه main بشه. ارتباط این دو تیم صرفا بابت تغییرات گسترده در تمام سایت خواهد بود. برای مثال، ممکنه مدیر پروژه درخواست کنه که بخش فروشگاه از سایت حذف شه. در این صورت، دو تیم باید یه صحبت کوچیک داشته باشن تا صرفا سر یک سری مسائل فنی، استانداردهای ساده‌ای رو تعیین کنن.این استقلال به حدی بالاست، که ما می‌تونیم در یک سیستم فرانت-اند، از تکنولوژی‌های متفاوتی استفاده کنیم. تیم‌ها آزادی زیادی در انتخاب تکنولوژی مورد استفادشون دارن. ما در میکرو-فرانت، می‌‌تونیم main رو با React، و dashboard رو با Vue بنویسیم. مشکلی پیش نمیاد!وابسته نبودن کتابخونه‌ها!کتابخونه‌ها (اصطلاح تخصصی‌تر، dependencyها یا وابستگی‌ها) نقش مهمی رو در اضافه کردن قابلیت‌های پیشرفته در فرانت-اند ما بازی می‌کنن. ممکنه فرانت-اندی که داریم می‌نویسیم، دارای ۱۰ها کتابخونه مختلف باشه. این ۱۰ها کتابخونه، باید از نظر نسخه باهم خوانایی داشته باشن.فرض کنید در هردو سرویس dashboard و main، کتابخونه X با ورژن ۱۰ رو داریم. بنا به دلایلی، مجبوریم ورژن این کتابخونه در main رو از ۱۰ به ۶ کاهش بدیم. در معماری میکروفرانت، بخش dashboard میتونه همواره با همون ورژن ۱۰ کار کنه، بدون اینکه نگران تغییر ورژن X در بخش main و در نتیجه نگران ناخوانی ورژن کتابخونه‌ها با هم باشه.سرعت بالا در توسعهاستقلال تیم‌های فعال در پروژه، متناسبا باعث سرعت بالاتر در توسعه نرم افزار میشه، چرا که نیاز ما به برگزاری جلسات فنی زیاد رو کم می‌کنه.قابلیت نگهداری بسیار بالا (maintainability)مستقل بودن اجزای یک سیستم، فرآیند نگهداری و باگیابی در اون‌هارو بسیار ساده می‌کنه. بارزترین مثال این امر، در تست‌نویسی ظاهر میشه، جایی که سرویس‌های مورد نظر به شکل کاملا جداگانه و در محیط ایزوله تست می‌شن. main به تست خود و dashboard هم به تست خود! هیچکدوم با اون یکی قاطی نمی‌شه.میکروفرانت چطور کار می‌کنه؟همونطور که گفتیم، میکروفرانت، میاد و فرانت-اند ما رو به اجزای کوچک‌تری به نام سرویس تقسیم می‌کنه. این سرویس‌ها که هرکدوم یک نرم‌افزار کوچیک به حساب میان، تحت یک نرم‌افزار بزرگ‌تر کار می‌کنن.نرم‌افزار کانتینر ما (همون نرم‌افزار بزرگ‌تره !) می‌تونه به شکل‌های متفاوتی پیاده‌سازی شه:سمت کاربر یا client-sideدر این روش، تمام سرویس‌های ما به شکل همزمان build گرفته شده و تحت عنوان یک build کلی روی سرور قرار می‌گیرن. اگه بخوایم سرویس جدیدتری اضافه کنیم، نیاز داریم که مجدد تمام سرویس‌هارو build بگیریم.سمت سرور یا server-sideدر روش سمت سرور، سرویس‌های ما به شکل جداگونه build گرفته شده و روی سرور قرار می‌گیرن. اینطوری دیگه با یک build گنده و سنگین سر و کله نمی‌زنیم، هر سرویس فقط زمانی لود می‌شه که صدا زده شه و این مسئله باعث بهبود عملکرد (Performance) نرم‌افزار ما می‌شه.سمت مرزی یا Edge-sideاین روش، برگرفته از حوزه رایانش مرزی هست. در این روش، سرویس‌های ما در لایه Edge باهم ترکیب میشن، مثل CDN.نتیجه‌گیریبه انتهای این مقاله می‌رسیم. در این مقاله راجب معماری Micro-Frontend صحبت کردیم و بررسی کردیم که شکستن نرم‌افزار بزرگ به نرم‌افزارهای کوچیک، چه فوایدی می‌تونه داشته باشه.امیدوارم این نوشته براتون مفید بوده باشه، اگه جایی حس کردید مطلب اشتباه نوشته شده یا ایرادی وجود داره، در کامنت‌ها پذیرای شما هستم.منبع: MicroFrontend on Dev.to</description><category>نوید معدن نژاد</category><author>نوید معدن نژاد</author><pubDate>Fri, 31 Mar 2023 22:38:32 +0330</pubDate></item><item><title>ترس از تکنولوژی!</title><link>https://virgool.ir/@navid_mnzh/تکنولوژی-هایی-که-باعث-ترس-مردم-شدن-y6bc5yoqtldw</link><description>علم یا جهان رو نجات می‌ده، و یا همه ما رو می‌کشه!داشتم فکر می‌کردم به عنوان اولین پستم در ویرگول چی بنویسم که این مسئله به ذهنم رسید، که چی بهتر از صحبت در مورد ترسی که از تکنولوژی داره به همه سرایت می‌کنه؟این روز ها، جملاتی که در مورد تکنولوژی به گوشمون می‌رسه خیلی تکراری شده. جملاتی مثل &#34;هوش مصنوعی و رباتیک به زودی ما رو نابود می‌کنه&#34; یا &#34;واکسن های کووید۱۹ هدفدار ساخته شدن&#34;.البته اره، واکسنا یک هدف دارن و اونم بهبود بیماریه!اما این ترس ها از کجا میان؟ تو این پست قصد دارم یه خلاصه ای از ترس مردم از تکنولوژی رو براتون بنویسیم و بگم که این ترس ها همیشه بودن، هستن و خواهند بود.۱ - ترس از قطارشاید براتون عجیب باشه، اما تو روز های اولی که قطار داشت جای اسب و گاری رو می‌گرفت، خیلی از مردم تصور می‌کردن که سرعت بالای قطار، باعث آسیب های شدیدی به بدنشون می‌شه. مثل آب شدن بدن، کنده شدن اعضای بدن و غیره.۲ - ترس از تلفنمردم از تلفن دوری می‌کردن، تاجایی که حتی خود مجله نیویورک تایمز اعلام کرد تلفن ها به حریم خصوصی مردم تجاوز می‌کنن و افراد رو تنبل بار میارن. حتی یک سری از مردم تعصبی تو مسائل مذهبی، پا رو فراتر گذاشتن و گفتن تلفن می‌تونه با مرده ها ارتباط برقرار کنه.۳ - ترس از تلگرافاز اونجایی که زبان به کار رفته تو تلگراف، از کد مورس تشکیل می‌شد (اگه اشتباه می‌کنم بگید) مردم فکر می‌کردن که به زودی، تلگراف جای زبان های انسانی، مثل انگلیسی و اسپانیایی رو می‌گیره و در آینده خود مردم هم توسط کد مورس با هم صحبت می‌کنن!۴ - رادیو، تلویزیون، گوشی های همراههمزمان با این اختراعات که در دهه های مختلفی اتفاق افتادن، همیشه مسائلی مثل &#34;این تکنولوژی ها آدمارو از هم دور می‌کنن!&#34; وجود داشته.البته کمو بیش این یک ترس درست از آب درومده، به خصوص در زمینه تلفن های همراه.با این تفاوت که این تکنولوژی ها هیچوقت نخواستن آدم ها رو از هم دور کنن، شاید این استفاده افراطی ما آدم ها بود که ما رو از هم دور کرد :)این مطلب به اینجا ختم نمی‌شه، اگه دوست داشتید می‌تونین تو سایت Ranker.com در موردش بیشتر بخونین.امیدوارم که لذت برده باشین :) </description><category>نوید معدن نژاد</category><author>نوید معدن نژاد</author><pubDate>Thu, 25 Jun 2020 12:52:08 +0430</pubDate></item></channel></rss>