<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Navid Barsalari</title>
        <link>https://virgool.io/feed/@navidbarsalari</link>
        <description>بیش از 4 سال سابقه حرفه ای برنامه نویسی موبایل و وب،یوتیوبر.....مقالات وب ،جاوا اسکریپت،گیت،ریکت،ریکت نیتیو.....</description>
        <language>fa</language>
        <pubDate>2026-04-15 06:59:23</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/194232/avatar/1dheUO.png?height=120&amp;width=120</url>
            <title>Navid Barsalari</title>
            <link>https://virgool.io/@navidbarsalari</link>
        </image>

                    <item>
                <title>⚖️ مقایسه‌ی مهاجرت تدریجی و مهاجرت یک‌باره — کدام برای پروژه‌ی شما مناسب‌تر است؟</title>
                <link>https://virgool.io/@navidbarsalari/%E2%9A%96%EF%B8%8F-%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%DB%8C-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D8%AA%D8%AF%D8%B1%DB%8C%D8%AC%DB%8C-%D9%88-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B1%D9%87-%E2%80%94-%DA%A9%D8%AF%D8%A7%D9%85-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%DB%8C-%D8%B4%D9%85%D8%A7-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D8%AA%D8%B1-%D8%A7%D8%B3%D8%AA-bsrmi447e8wm</link>
                <description>این مقاله ادامه‌ی دو پست قبلی من درباره‌ی  این مقاله ادامه‌ی دو پست قبلی من درباره‌ی مهاجرت تدریجی از Nuxt به Next.js و بازنویسی کامل از Node.js به Go است.اگر هنوز آن‌ها را نخوانده‌اید، پیشنهاد می‌کنم ابتدا از آن‌ها شروع کنید تا با دو سناریوی واقعی آشنا شوید.مقدمهدر مسیر مدرن‌سازی نرم‌افزار، همیشه یک سؤال کلیدی مطرح است:«آیا باید پروژه را مرحله‌به‌مرحله به‌روزرسانی کنیم یا از نو بسازیم؟»این تصمیم ساده به نظر می‌رسد، اما می‌تواند سرنوشت فنی و حتی مالی کل شرکت را تغییر دهد.در این مقاله، با تکیه بر دو تجربه‌ی واقعی، تفاوت‌ها، مزایا و چالش‌های دو رویکرد Incremental Migration و Big Bang Migration را بررسی می‌کنیم.🚀 ۱. مهاجرت تدریجی (Incremental Migration)در این رویکرد، سیستم فعلی را به‌صورت مرحله‌به‌مرحله به فناوری جدید منتقل می‌کنیم.هر بخش جدید در کنار سیستم قدیمی بالا می‌آید و به مرور کل سیستم جایگزین می‌شود.🔹 نمونه‌ی واقعی:ما از Nuxt (Vue) به Next.js (React) رفتیم، بدون اینکه سرویس حتی یک دقیقه از کار بیفتد.🔹 ویژگی‌ها:بدون downtimeریسک پایین‌ترامکان یادگیری تدریجی تیمزمان طولانی‌تر تا اتمام کامل🔹 چالش‌ها:همزیستی دو سیستم (تداخل Auth، استایل، داده)نیاز به DevOps قوی برای مدیریت ترافیک بین دو اپپیچیدگی در CI/CD💥 ۲. مهاجرت یک‌باره (Big Bang Migration)در مقابل، این روش یعنی بازنویسی کامل — همه‌چیز از نو، در یک پرتاب (launch) واحد.سیستم قدیمی خاموش می‌شود، نسخه‌ی جدید بالا می‌آید.🔹 نمونه‌ی واقعی:ما بک‌اند را از Node.js به Go بازنویسی کردیم، چون ساختار قبلی قابل نگهداری نبود.🔹 ویژگی‌ها:طراحی کاملاً جدیدحذف کامل بدهی فنی (technical debt)عملکرد بهینه‌ترانتشار سریع‌تر از نظر زمان اجرا (ولی طولانی‌تر در آماده‌سازی)🔹 چالش‌ها:ریسک بالا (اگر شکست بخورد، کل سیستم از کار می‌افتد)نیاز به تست و مستندسازی بسیار دقیقاحتمال تأخیر در لانچ🧭 انتخاب درست چیه؟هیچ پاسخ مطلقی وجود نداره، ولی چند قاعده‌ی طلایی هست:⚙️ ترکیب هر دو رویکرددر پروژه‌های بزرگ، اغلب ترکیب این دو جواب می‌دهد:Frontend را با مهاجرت تدریجی پیش ببر (مثلاً Nuxt → Next)Backend را با بازنویسی کامل انجام بده (مثلاً Node → Go)به این ترتیب هم ریسک را کنترل می‌کنی و هم از مزایای هر دو جهان استفاده می‌کنی.نتیجه‌گیریمهاجرت نرم‌افزار فقط تغییر فریم‌ورک نیست؛یک تصمیم معماری و فرهنگی است.Incremental Migration مثل تغییر قطعات ماشین در حین حرکت است.Big Bang Migration مثل خرید یک ماشین جدید با همان پلاک است.مهم این است که:تصمیم بگیری کدام مسیر با واقعیت تیم، بودجه و کاربران تو هم‌خوانی دارد.</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Sat, 18 Oct 2025 12:45:59 +0330</pubDate>
            </item>
                    <item>
                <title>💥 مهاجرت یک‌باره (Big Bang Migration): بازسازی کامل از Node.js به Go</title>
                <link>https://virgool.io/@navidbarsalari/%F0%9F%92%A5-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B1%D9%87-big-bang-migration-%D8%A8%D8%A7%D8%B2%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D8%A7%D9%85%D9%84-%D8%A7%D8%B2-nodejs-%D8%A8%D9%87-go-t0wua8jvzoge</link>
                <description>مقدمهگاهی وقت‌ها نمی‌شه با وصله‌پینه و ریفکتورهای کوچک آینده‌ی پروژه رو ساخت.به کد نگاه می‌کنی، پر از تودرتوهای قدیمی و منطق‌های سنگینه، و می‌گی:&quot;دیگه این درست‌شدنی نیست. باید از صفر بسازیمش.&quot;اینجاست که مهاجرت یک‌باره یا Big Bang Migration مطرح می‌شه.حرکتی جسورانه که در اون، سیستم قدیمی به‌طور کامل با نسخه‌ی جدید جایگزین می‌شه — در یک لانچ واحد.ریسکیه؟ قطعاً.ولی گاهی تنها راه واقعیه.در این مقاله تجربه‌ی واقعی ما از بازنویسی بک‌اند از Node.js به Go رو توضیح می‌دم؛ مسیری پرچالش اما موفق.⚡ مهاجرت Big Bang چیست؟در این مدل، سیستم فعلی رو یک‌جا و کامل با سیستم جدید جایگزین می‌کنی.هیچ اجرای همزمانی بین قدیم و جدید وجود نداره.همه‌چیز طراحی، پیاده‌سازی و تست می‌شه — و در یک لحظه سوئیچ می‌کنی.مثل خراب‌کردن یه خونه و ساخت دوباره‌ی اون روی همون زمین.🧠 چرا ما Big Bang رو انتخاب کردیم؟بک‌اند ما با Node.js شروع شده بود، اما طی ۴ سال به هیولایی ۲۰۰ هزار خطی تبدیل شد:حجم زیاد منطق CPU-bound (آنالیز، پردازش ویدیو)مشکلات مقیاس‌پذیری در ترافیک بالالیک حافظه و باگ‌های asyncعملکرد ناپایدار در بار زیادبهینه‌سازی‌ها جواب نمی‌دادن.به Go نگاه کردیم — زبان سریع‌تر، همزمانی ذاتی (goroutine) و مدیریت حافظه‌ی بهتر.اما مهاجرت تدریجی ممکن نبود؛ دو محیط کاملاً متفاوت بودن.پس تصمیم گرفتیم همه‌چیز رو از اول بسازیم.🧭 برنامه‌ریزی مهاجرتکلید موفقیت در Big Bang، برنامه‌ریزی دقیقه.1. توقف توسعه فیچر جدیدبرای دو ماه هیچ فیچر تازه‌ای اضافه نکردیم تا سیستم فعلی پایدار بمونه.2. مستندسازی کاملتمام APIها، مدل‌های داده، و وظایف پس‌زمینه رو مستند کردیم تا قرارداد رفتاری نسخه‌ی جدید مشخص باشه.3. همسان‌سازی لایه‌ی APIدر نسخه‌ی Go، تمام endpointها دقیقاً مثل Node طراحی شدن تا فرانت‌اند یا اپ موبایل نیازی به تغییر نداشته باشه.4. تست در محیط جداسرویس Go رو در محیط staging بالا آوردیم، با دیتابیس کپی‌شده از production.هر روز با داده‌ی واقعی تست فشار (load test) می‌گرفتیم.5. شبیه‌سازی ترافیکقبل از لانچ نهایی، یه هفته درخواست‌های واقعی کاربرها رو shadow کردیم تا رفتار سیستم رو در شرایط واقعی بسنجیم.6. روز مهاجرتدر ساعت ۲ بامداد، با تغییر تنظیمات Load Balancer، ترافیک از Node به Go منتقل شد:service backend set-target go-app
در عرض ۳۰ ثانیه همه‌ی درخواست‌ها به سرویس جدید رسید.7. طرح بازگشت (Rollback)اگر مشکلی پیش می‌اومد، با یک تغییر ساده می‌تونستیم ترافیک رو به Node برگردونیم — بدون تغییر در دیتابیس.⚙️ نکات فنیاستفاده از Go Fiber به‌عنوان وب‌فریم‌ورک سریع و سبکGORM برای ORM با PostgreSQLاشتراک JWT tokens با فرانت‌اند (بدون تغییر در auth)پردازش وظایف با goroutine و Redis Streamمانیتورینگ با Prometheus + Grafanaنمونه‌ای ساده از ساختار Go:app := fiber.New()

app.Get(&quot;/api/users/:id&quot;, getUserHandler)
app.Post(&quot;/api/upload&quot;, uploadHandler)
app.Post(&quot;/api/aggregate&quot;, aggregateHandler)

log.Fatal(app.Listen(&quot;:8080&quot;))
همه‌ی کارهایی که قبلاً چند پروسه‌ی Node لازم داشت، حالا با goroutineها انجام می‌شد.⏱ کل فرآیند ۳ ماه توسعه و فقط یک شب انتشار طول کشید.بدون هیچ قطعی جدی — فقط یک بازه‌ی کوتاه فقط‌خواندنی هنگام سینک دیتابیس.⚠️ درس‌های آموخته‌شده۱. Big Bang یعنی ریسک بزرگ.یک باگ می‌تونه کل سیستم رو از کار بندازه. تست و مانیتورینگ حیاتی‌ان.۲. محیط موازی (Shadow Testing) نجات‌بخشه.قبل از لانچ، ترافیک واقعی رو به‌صورت مخفی به Go فرستادیم تا باگ‌ها زودتر شناسایی شن.۳. ارتباط تیمی حیاتی‌ه.از dev تا پشتیبانی، همه از برنامه‌ی مهاجرت خبر داشتن — هیچ شوکی در سازمان پیش نیومد.۴. قراردادهای API رو ثابت نگه دار.بازنویسی به معنی تغییر رفتار نیست. تطابق APIها باعث شد کاربران هیچ تغییری حس نکنن.🧭 چه زمانی Big Bang انتخاب مناسبه؟مناسب زمانی که...نامناسب زمانی که...سیستم فعلی غیرقابل نگه‌داریههنوز می‌شه بخش‌به‌بخش ریفکتور کرددو محیط فنی قابل همزیستی نیستنمی‌تونی قدیم و جدید رو کنار هم اجرا کنیتست پوشش کامل داریتست و staging نداریمی‌تونی کمی downtime بپذیریسرویس ۲۴/۷ فعاله🏁 جمع‌بندیمهاجرت یک‌باره شرط‌بندی بزرگیه — ولی اگه درست برنامه‌ریزی بشه، می‌تونه همه‌چیز رو متحول کنه.ما با این بازنویسی از Node به Go تونستیم:سرعت سیستم رو دو برابر کنیممصرف منابع رو نصف کنیمو بک‌اند تمیز و مقیاس‌پذیری بسازیمگاهی برای ساخت آینده، باید گذشته رو کامل کنار بذاری.</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Sat, 18 Oct 2025 12:40:49 +0330</pubDate>
            </item>
                    <item>
                <title>🚀 مهاجرت تدریجی (Incremental Migration): تکامل بدون شکستن تولید</title>
                <link>https://virgool.io/@navidbarsalari/%F0%9F%9A%80-%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D8%AA%D8%AF%D8%B1%DB%8C%D8%AC%DB%8C-incremental-migration-%D8%AA%DA%A9%D8%A7%D9%85%D9%84-%D8%A8%D8%AF%D9%88%D9%86-%D8%B4%DA%A9%D8%B3%D8%AA%D9%86-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-c7i5juylwvtf</link>
                <description>مقدمهبازسازی یک سیستم در حال اجرا مثل عوض کردن موتور هواپیما وسط پروازه — باید مدرن‌سازی انجام بدی در حالی که سیستم همچنان کار می‌کنه.اینجاست که مفهوم مهاجرت تدریجی (Incremental Migration) وارد می‌شه.به‌جای اینکه کل پروژه رو از نو بسازی، سیستم رو مرحله‌به‌مرحله مهاجرت می‌دی و در هر گام، پایداری رو حفظ می‌کنی.این استراتژی مخصوصاً وقتی جواب می‌ده که بخوای از یه فریم‌ورک مدرن به یه فریم‌ورک مدرن‌تر بری، مثلاً:مهاجرت از Nuxt (Vue) به Next.js (React)یا جداسازی یک Next.js monolith به React frontend + NestJS backendدر این مقاله، یاد می‌گیری چطور می‌تونی یه پروژه‌ی فعال در بازار رو بدون توقف، ریفکتور و مدرن‌سازی کنی.مهاجرت تدریجی چیست؟در مهاجرت تدریجی، سیستم رو در چند فاز کوچک جابه‌جا می‌کنی.به‌جای یک بازنویسی بزرگ، بین سیستم قدیمی و جدید پل می‌سازی تا مدتی کنار هم کار کنن.مثل وقتی که داری خونه‌ت رو بازسازی می‌کنی ولی هنوز توش زندگی می‌کنی — یه اتاق رو تعمیر می‌کنی، بعد میری سراغ بعدی.چرا مهاجرت تدریجی؟✅ بدون زمان ازکارافتادگی (Downtime) — کاربران همچنان از سیستم استفاده می‌کنن.✅ ریسک پایین‌تر — هر مرحله کوچیک و قابل‌آزمایش هست.✅ یادگیری تدریجی تیم — اعضا کم‌کم با تکنولوژی جدید آشنا می‌شن.✅ تحویل مداوم (Continuous Delivery) — هر فاز می‌تونه مستقل منتشر بشه.🧠 سناریو ۱: مهاجرت از Nuxt به Next.jsفرض کن یه داشبورد SaaS داری که با Nuxt 2 ساخته شده و هزاران کاربر داره.تیمت می‌خواد به Next.js مهاجرت کنه چون:پشتیبانی از TypeScript بهتره،ابزارهای اکوسیستم React قوی‌ترن،و SSR سریع‌تره.اما نمی‌تونی سرویس رو متوقف کنی. پس چطور انجامش بدی؟گام‌به‌گام مهاجرت1. تعیین مرزهاابتدا بخش‌های مختلف اپ رو شناسایی کن (مثل Dashboard، Profile، Admin Panel).یک قسمت ایزوله مثل Dashboard رو برای شروع انتخاب کن.2. ساخت پروژه‌ی Next.js جدیددر کنار کد Nuxt فعلی، یه پروژه‌ی Next.js جدید بساز.فعلاً هر دو کنار هم وجود دارن.3. تنظیم مسیرها با پراکسیبا استفاده از Nginx یا Gateway می‌تونی درخواست‌ها رو بین دو اپ تقسیم کنی:مسیر /dashboard → به Next.jsبقیه مسیرها → به Nuxtکاربرها هیچ تفاوتی حس نمی‌کنن.4. اشتراک سشن و طراحیتوکن‌های احراز هویت (JWT) یا کوکی‌ها رو مشترک کن تا کاربر بدون لاگین مجدد بین دو سیستم جابه‌جا شه.همچنین CSS و تم رو در یه پکیج مشترک بذار تا ظاهر ثابت بمونه.5. مهاجرت مرحله‌ایبه‌مرور صفحات، کامپوننت‌ها و APIها رو منتقل کن.وقتی همه بخش‌ها به Next منتقل شدن، پروژه‌ی Nuxt رو حذف کن — بدون حتی یک لحظه downtime.⚙️ سناریو ۲: مهاجرت از Node.js به Goبک‌اند سیستم با Node.js نوشته شده و با گذر زمان کند و سنگین شده.تیم تصمیم گرفته قسمت‌های CPU-محور (مثل پردازش تصویر و آنالیز داده‌ها) رو به Go منتقل کنه.اما نمی‌خوای بک‌اند رو از پایه بازنویسی کنی.مراحل انجام1. شناسایی نقاط گلوگاهبا پروفایلینگ، دو بخش پرمصرف پیدا کردیم:تحلیل داده‌هاپردازش تصویر2. ساخت سرویس جانبی در Goبه‌جای جایگزینی کامل، یه سرویس Go کنار Node ساختیم.Node همچنان API اصلی رو داشت ولی وظایف سنگین رو به Go می‌سپرد:app.post(&#039;/api/aggregate&#039;, async (req, res) =&gt; {
  const result = await fetch(&#039;http://go-service:8080/aggregate&#039;, {
    method: &#039;POST&#039;,
    body: JSON.stringify(req.body)
  });
  res.json(await result.json());
});3. استخراج تدریجیبه‌مرور کارهای دیگر مثل Queue و Jobها رو هم به Go منتقل کردیم تا در نهایت Node فقط دروازه (Gateway) باقی موند.📈 نتیجه نهاییبعد از سه ماه:هیچ قطعی نداشتیم، عملکرد بهبود پیدا کرد، و تیم همزمان فیچرهای جدید رو توسعه داد.🧭 نکات کلیدیمهاجرت تدریجی سریع نیست، ولی ایمنه.از پراکسی یا API Gateway برای همزیستی دو سیستم استفاده کن.Auth و داده مشترک حیاتی‌ان.هر گام کوچیک، یه پیروزی بزرگه.در کل:مهاجرت تدریجی یعنی حرکت بدون شکستن چیزها.</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Sat, 18 Oct 2025 10:47:47 +0330</pubDate>
            </item>
                    <item>
                <title>آموزش ES6  مبحث Var</title>
                <link>https://virgool.io/@navidbarsalari/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-es6-%D9%85%D8%A8%D8%AD%D8%AB-var-uv8oupqtjzed</link>
                <description>آموزش فارسی جاوا اسکریپت (es6) مبحث متغیر،در این ویدیو به بررسی دقیق Var  از سطح مقدماتی تا پیشرفته می پردازیم. تمام  موضوعات مورد نیاز در پروژه و مصاحبه های فنی را بررسی می کنیم:لینک ویدیو در کانال یوتیوب : https://youtu.be/VTbnwD88GrQhttps://bit.ly/30W8qjb لینک پلی لیست1.معرفی متغیر در جاوا اسکریپت2.چرا var را بررسی می کنیم؟3.خصوصیات متغیر از نوع var4.تعریف متغییر و اولین مثال5.  var scoping (function scope , global scope)6.اولین مثال در block scope7. دومین مثال block scope8. سومین مثال  block scope9.var hoistingبرای دیدن ویدیو ها بیشتر کانال ما را سابسکرایب کنید</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Sat, 20 Jun 2020 17:03:15 +0430</pubDate>
            </item>
                    <item>
                <title>وقتی مصاحبه کننده می پرسد &quot;آیا سوالی دارید؟&quot;</title>
                <link>https://virgool.io/@navidbarsalari/%D9%88%D9%82%D8%AA%DB%8C-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-%DA%A9%D9%86%D9%86%D8%AF%D9%87-%D9%85%DB%8C-%D9%BE%D8%B1%D8%B3%D8%AF-%D8%A2%DB%8C%D8%A7-%D8%B3%D9%88%D8%A7%D9%84%DB%8C-%D8%AF%D8%A7%D8%B1%DB%8C%D8%AF-otknboxhrfiw</link>
                <description>این پایان مصاحبه نیست.در واقع اگر مصاحبه کننده درباره استخدام شما مطمئن نباشد یا نظر مساعدی در مورد شما ندارد، این آخرین شانس شما برای تغییر نظر مصاحبه کننده است.سؤالاتی را مطرح کنید که 1) مختص شرکت است، 2) با نقش شما مطابقت دارد و 3) نشان می‌دهد که شما علاقه مند هستید.سوالات بد:چه آموزش‌هایی به کارمندان داده می‌شود؟سوال بهتر:&quot;چه اهدافی در این نقش (role) برای من در نظر گرفته شده؟&quot;اگر آموزش برای شما مهم است، می‌توانید ادامه دهید: &quot;و چه آموزش‌هایی برای کمک به من در دستیابی به این اهداف برای شرکت وجود خواهد داشت؟&quot;آدرس کانال یوتیوب و صفحه گیت هاب برای دیدن ویدیو و مقالات بیشتر در زمینه برنامه نویسی.</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Mon, 25 May 2020 09:52:01 +0430</pubDate>
            </item>
                    <item>
                <title>وقتی گوگل ما رو بچه 5 ساله فرض میکنه!</title>
                <link>https://virgool.io/@navidbarsalari/%D9%88%D9%82%D8%AA%DB%8C-%DA%AF%D9%88%DA%AF%D9%84-%D9%85%D8%A7-%D8%B1%D9%88-%D8%A8%DA%86%D9%87-5-%D8%B3%D8%A7%D9%84%D9%87-%D9%81%D8%B1%D8%B6-%D9%85%DB%8C%DA%A9%D9%86%D9%87-fwlnb1bqq210</link>
                <description>وقتی گوگل ما رو بچه 5 ساله فرض میکنه!اگر به یک مقاله پیچیده در گوگل برخوردید که فهمش براتون سخت بود ...گوگل راه حلی برای این مسئله داره. به این صورت که قبل واژه ای که میخواید سرچ کنید، بنویسید eli5عبارت eli5 یعنی explain like im five(در واقع از گوگل در خواست می‌کنید که جوری توضیح بده که انگار 5 سالمه! )انجمن‌هایی مانند ردیت، مباحث پیچیده رو به زبان ساده توضیح میدنلینک یه سری از انجمن و سایت‌های که از eli5 استفاده می‌کنند:https://eli5.readthedocs.io/https://www.reddit.com/r/explainlikeimfive/https://pypi.org/project/eli5/آدرس کانال یوتیوب و صفحه گیت هاب برای دیدن ویدیو و مقالات بیشتر در زمینه برنامه نویسی.</description>
                <category>Navid Barsalari</category>
                <author>Navid Barsalari</author>
                <pubDate>Wed, 20 May 2020 01:02:11 +0430</pubDate>
            </item>
            </channel>
</rss>