https://virgool.io/feed/@m_43844107 fa 2026-07-06 06:16:16 https://files.virgool.io/upload/users/4866803/avatar/Rhgc5l.jpg?height=120&width=120 https://virgool.io/@m_43844107 https://virgool.io/@m_43844107/%D8%AA%D8%B3%D9%84%D8%B7-%D8%A8%D8%B1-source-maps-%D9%88-symbolication-%D8%A7%D8%B4%DA%A9%D8%A7%D9%84-%D8%B2%D8%AF%D8%A7%DB%8C%DB%8C-%DA%A9%D8%AF-%D9%81%D8%B4%D8%B1%D8%AF%D9%87-%D8%AF%D8%B1-%D9%85%D8%AD%DB%8C%D8%B7-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-mtsbti8ibzso اشکال‌زدایی کد فشرده در محیط تولید: آموزش کامل Source Map و Symbolicationکابوس خطاهای مبهم در تولیدفرض کنید اپلیکیشن وب یا موبایل شما منتشر شده است. ناگهان کاربر خطا می‌دهد. شما به لاگ سرور مراجعه می‌کنید و می‌بینید:TypeError: Cannot read property 'x' of undefined at a.min.js:1:87923خط شماره ۱، کاراکتر ۸۷۹۲۳ یعنی چه؟ اصلاً کد شما کجاست؟!این مشکل تمام تیم‌هایی است که کد خود را برای محیط تولید (production) فشرده (minify) و مبهم (obfuscate) می‌کنند. فشرده‌سازی سرعت بارگذاری را بالا می‌برد اما خطاها را غیرقابل خواندن می‌کند.راه حل چیست؟ Source Map و Symbolication.Source Map چیست؟فایل .map یک دیکشنری است که ارتباط بین کد فشرده (همان a.min.js) و کد اصلی شما (مثل index.js) را نگهداری می‌کند.وقتی مرورگر خطا می‌دهد، دیباگر به کمک Source Map می‌تواند دقیقاً مشخص کند که این خطا در کدام خط از کد اصلی شما رخ داده است.مثال عملی:- کد اصلی شما: function getUserName(user) { return user.name; }- بعد از minify: function a(b){return b.name}- خطا در کد minify: a is not defined- بعد از اعمال Source Map: خطا در تابع getUserName در خط ۱۲ فایل profile.jsSymbolication چیست؟ (برای اپلیکیشن‌های موبایل)در اپلیکیشن‌های iOS و اندروید، کرنل سیستم عامل هنگام crash یک آدرس حافظه (مثل 0x1a2b3c4d) برمی‌گرداند. این آدرس برای انسان بی‌معناست.Symbolication فرآیند تبدیل این آدرس حافظه به نام تابع، نام فایل و شماره خط با استفاده از فایل‌های dSYM (در iOS) یا mapping.txt (در ProGuard اندروید) است.بدون Symbolication، یک crash report شبیه این است:0x0000000102a3b4c50x0000000102a3b4d0با Symbolication تبدیل می‌شود به:applicationDidBecomeActive (AppDelegate.swift:45)viewDidLoad (HomeViewController.swift:120)چرا این ابزارها برای هر تیم توسعه‌ای ضروری است؟۱. صرفه‌جویی در زمان: به جای حدس زدن، دقیقاً محل خطا را می‌بینید.۲. حذف ردپای کد از سرور عمومی: نیازی نیست فایل‌های .map را روی سرور تولید منتشر کنید. می‌توانید آن‌ها را در ابزارهای داخلی یا سرویس‌های ردیابی خطا نگهداری کنید.۳. گروه‌بندی هوشمند خطاها: ابزارهای مدرن با استفاده از Source Map خطاهای تکراری را شناسایی و گروه‌بندی می‌کنند.چالش اصلی: مدیریت نسخه‌هااگر Source Map نسخه ۱.۰ را برای خطای نسخه ۱.۱ استفاده کنید، نتیجه اشتباه خواهد بود.راهکار: همیشه Source Map را همراه با همان build در یک مکان امن (مثل دشبورد ردیابی خطا) آپلود کنید.یک ابزار پیشنهادیاگر نمی‌خواهید خودتان زیرساخت مدیریت Source Map را بسازید، سرویس‌هایی مثل Rivium Trace (در آدرس rivium.co) این کار را خودکار کرده‌اند. شما فقط فایل .map را آپلود می‌کنید و بقیه فرآیند symbolication خودکار انجام می‌شود. اما حتی بدون آن هم می‌توانید با ابزارهای خط فرمان مانند source-map در Node.js این کار را انجام دهید.جمع‌بندی- همیشه از Source Map در پروژه‌های JavaScript/TypeScript استفاده کنید.- برای اپلیکیشن‌های موبایل، فایل‌های dSYM یا ProGuard را نگهداری کنید.- هرگز فایل‌های .map را در پوشه عمومی سرور قرار ندهید.- فرآیند آپلود نقشه‌ها را در CI/CD خود خودکار کنید.با رعایت این اصول، دیگر خطاهای مبهم در تولید شما را متوقف نخواهند کرد.اگر سوالی درباره نحوه تولید Source Map در Webpack، Vite یا Next.js دارید، در کامنت‌ها بپرسید. محمد مهدی محمد مهدی Sun, 14 Jun 2026 14:29:33 +0330 https://virgool.io/@m_43844107/%DA%86%D8%B1%D8%A7-%D9%BE%DB%8C%D8%AF%D8%A7-%DA%A9%D8%B1%D8%AF%D9%86-%D8%B9%D9%84%D8%AA-%D8%A7%D8%B5%D9%84%DB%8C-%DA%A9%D9%86%D8%AF%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%A7%D8%B2-%D8%AE%D9%88%D8%AF%D9%90-%D9%85%D8%B4%DA%A9%D9%84-%D8%B3%D8%AE%D8%AA-%D8%AA%D8%B1-%D8%B4%D8%AF%D9%87-%D8%A7%D8%B3%D8%AA-qtriwkssxymn وقتی یک سیستم کوچک است، پیدا کردن خطا معمولاً کار پیچیده‌ای نیست.یک درخواست به سرور ارسال می‌شود، چند کوئری به دیتابیس اجرا می‌شود و نتیجه به کاربر برمی‌گردد. اگر مشکلی وجود داشته باشد، معمولاً با چند لاگ یا بررسی ساده می‌توان دلیل آن را پیدا کرد.اما با بزرگ‌تر شدن سیستم‌ها، داستان کاملاً تغییر می‌کند.امروزه بسیاری از تیم‌ها از معماری Microservice استفاده می‌کنند. هر درخواست ممکن است از چندین سرویس مختلف عبور کند، به دیتابیس متصل شود، با سرویس‌های شخص ثالث ارتباط برقرار کند و در نهایت نتیجه را به کاربر برگرداند.در چنین شرایطی وقتی کاربر می‌گوید:«سایت کند شده»یا«پرداخت انجام نمی‌شود»یا«بعضی کاربران با خطا مواجه می‌شوند»پیدا کردن دلیل اصلی مشکل دیگر ساده نیست.مشکل از جایی شروع می‌شود که لاگ‌ها کافی نیستندبسیاری از تیم‌ها هنگام بروز مشکل سراغ لاگ‌ها می‌روند.لاگ‌ها اطلاعات ارزشمندی هستند، اما یک محدودیت مهم دارند:آن‌ها فقط اتفاقات را ثبت می‌کنند، نه ارتباط بین اتفاقات را.فرض کنید یک درخواست برای پرداخت وارد سیستم می‌شود.این درخواست:از API Gateway عبور می‌کندبه سرویس احراز هویت می‌رسدموجودی کاربر را بررسی می‌کندبا سرویس پرداخت ارتباط می‌گیردنتیجه را ذخیره می‌کندحالا اگر این فرآیند به جای ۵۰۰ میلی‌ثانیه، ۴ ثانیه طول بکشد، از روی لاگ‌ها همیشه مشخص نیست تأخیر دقیقاً در کدام مرحله ایجاد شده است.Metrics هم همیشه پاسخ را نمی‌دهندبسیاری از تیم‌ها از ابزارهای مانیتورینگ استفاده می‌کنند.آن‌ها می‌توانند نشان دهند:مصرف CPU افزایش پیدا کردهحافظه بیشتر استفاده شدهتعداد خطاها بالا رفتهاما معمولاً نمی‌توانند پاسخ دهند:«کدام درخواست؟»«کدام سرویس؟»«کدام تابع؟»«کدام کاربر؟»در واقع Metrics به شما می‌گوید مشکلی وجود دارد، اما لزوماً دلیل آن را مشخص نمی‌کند.جایی که Distributed Tracing اهمیت پیدا می‌کندDistributed Tracing برای حل همین مسئله به وجود آمده است.به جای اینکه فقط لاگ یا متریک جمع‌آوری شود، مسیر کامل یک درخواست در سیستم ثبت می‌شود.در نتیجه می‌توان مشاهده کرد:درخواست از کجا شروع شده استاز چه سرویس‌هایی عبور کرده استهر سرویس چه مدت زمان پردازش داشته استخطا دقیقاً در کدام بخش رخ داده استبه جای حدس زدن، تیم می‌تواند مسیر واقعی درخواست را مشاهده کند.یک مثال واقعیفرض کنید کاربران گزارش می‌دهند که فرآیند پرداخت بسیار کند شده است.هیچ خطایی ثبت نشده.CPU و RAM نیز وضعیت طبیعی دارند.در نگاه اول همه چیز سالم به نظر می‌رسد.اما با بررسی Trace مشخص می‌شود:سرویس پرداخت ۱۲۰ میلی‌ثانیه زمان مصرف کردهسرویس احراز هویت ۸۰ میلی‌ثانیه زمان مصرف کردهاما یک API خارجی بیش از ۳ ثانیه تأخیر داشته استدر این حالت تیم ظرف چند دقیقه علت اصلی مشکل را پیدا می‌کند؛ در حالی که بدون Trace ممکن بود ساعت‌ها زمان صرف بررسی لاگ‌ها شود.چرا این موضوع برای تیم‌های ایرانی مهم‌تر است؟بسیاری از ابزارهای Observability مطرح دنیا برای شرکت‌های ایرانی چالش‌هایی ایجاد می‌کنند:هزینه دلاریمحدودیت‌های دسترسیپیچیدگی در راه‌اندازینیاز به زیرساخت‌های جانبی متعدددر نتیجه بسیاری از تیم‌ها یا اصلاً از این ابزارها استفاده نمی‌کنند یا تنها بخش کوچکی از قابلیت‌های آن‌ها را به کار می‌گیرند.در حالی که با رشد سیستم‌ها، نیاز به مشاهده‌پذیری (Observability) دیگر یک قابلیت دور از دسترس نیست؛ بلکه بخشی ضروری از فرآیند توسعه و نگهداری نرم‌افزار محسوب می‌شود.جمع‌بندیهرچه سیستم‌ها بزرگ‌تر می‌شوند، پیدا کردن علت اصلی مشکلات دشوارتر می‌شود.لاگ‌ها مهم هستند.متریک‌ها مهم هستند.اما زمانی که بخواهیم دقیقاً بفهمیم یک درخواست چه مسیری را طی کرده و دلیل واقعی کندی یا خطا چیست، Distributed Tracing به یکی از مهم‌ترین ابزارهای تیم‌های فنی تبدیل می‌شود.سؤال دیگر این نیست که «آیا سیستم ما مشکل دارد؟»سؤال این است که «چقدر سریع می‌توانیم علت واقعی آن را پیدا کنیم؟» محمد مهدی محمد مهدی Sat, 13 Jun 2026 08:41:32 +0330