<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های Masoud</title><link>https://virgool.ir/feed/@masoud.it2012</link><description></description><language>fa</language><pubDate>2026-11-10 15:06:45</pubDate><image><url>https://files.virgool.ir/upload/users/1150497/avatar/avatar.png</url><title>Masoud</title><link>https://virgool.ir/@masoud.it2012</link></image><item><title>چرا معیارهای هندوانه ای خطرناک هستند</title><link>https://virgool.ir/@masoud.it2012/چرا-معیارهای-هندوانه-ای-خطرناک-هستند-ipokvmfx0meq</link><description>مسابقه برای «بهره‌ورتر و کاراتر بودن» → مستقیم به فرسودگی می‌رسه  burnout اگه هر روز با خودت یا تیم‌های دیگه رقابت کنی که «امروز بیشتر از دیروز تحویل بدیم»، یه روزی می‌بینی همه چیز سبزه، ولی در واقع داری به هدف اصلی نزدیک نمی‌شی.  نتیجه؟ خستگی ذهنی و جسمی، بی‌حوصلگی از پروژه طولانی، و در نهایت بهترین آدما یا می‌رن یا می‌سوزن.تمرکز فقط روی خروجی → پدیده «هندونه metrics» (Watermelon Effect)  از بیرون همه چیز سبز و قشنگه (معیارها گرین، تیک خورده، تحویل داده شده)  ولی وقتی می‌بريش، از داخل قرمزِ قرمزِ خونینه (هیچ نتیجه واقعی و ارزشمندی به دست نیومده).چرا معیارهای هندونه‌ای خطرناک‌اند؟  چند مثال واقعی:- تعداد خطوط کد بالا → ممکنه یعنی کدنویسی کثیف، پر از باگ، پر از دِین فنی و مشکلات عملکردی  - تعداد باگ‌های رفع‌شده زیاد → بدون در نظر گرفتن شدت یا تکرار باگ، هیچی در مورد کیفیت واقعی نرم‌افزار نمی‌گه - تعداد فیچر تحویل‌شده زیاد → اگه فیچرها کم‌ارزش باشن و مشتری اصلاً ازشون استفاده نکنه، فقط یه عدد قشنگ روی کاغذه (false positive) اندازه‌گیری نتیجه (Outcome) خیلی پیچیده‌تر از خروجی است  برای اینکه بفهمی یه فیچر واقعاً چقدر درآمد یا ارزش ساخته، باید داده‌های تحقیق کاربر و بینش کسب‌وکار داشته باشی.  به‌عنوان لید مهندسی، باید همیشه با تیم محصول و ذی‌نفعان کسب‌وکار در ارتباط باشی. هر گونه قطع ارتباط در این زمینه = فاجعه برای پروژه.خلاصه اینکه - معیار سبز ≠ موفقیت واقعی  - تعداد فیچر / خط کد / باگ رفع‌شده = معیارهای هندونه‌ای (از بیرون سبز، از داخل قرمز)  - اگه فقط خروجی اندازه بگیری و نتیجه رو فراموش کنی، بهترین تیم رو هم تبدیل می‌کنی به کارخانه تولید زباله با سرعت بالا  - راه درست: هر فیچر باید قبل از ساختن جواب این سؤال رو داشته باشه:    «این دقیقاً چه outcome مشخص و قابل اندازه‌گیری‌ای برای کاربر یا کسب‌وکار ایجاد می‌کنه؟»</description><category>Masoud</category><author>Masoud</author><pubDate>Fri, 12 Dec 2025 14:52:47 +0330</pubDate></item><item><title>میکرو-فرانت‌اند ها: چی، چرا و چطور؟</title><link>https://virgool.ir/@masoud.it2012/میکرو-فرانت-اند-ها-چی-چرا-و-چطور-wgrbxtwhpbnu</link><description>در سال های اخیر مبحث میکروفرانت‌اند ها بسیار مورد بحث بوده و در این مقاله قصد دارم درباره این که  میکرو فرانت‌اندها چی هستند، چرا به  میکرو فرانتدها نیاز داریم، و روش های متفاوت پیاده سازی آن ها بنویسم. این مبحث کمک بسیاری به من برای نوشتن پیشنهادی برای تغییر در معماری شرکت کرد و امیدوارم در پروژه های شما هم مفید باشه.میکرو-فرانت‌اند چیه؟در تعریف مارتین فولر از معماری میکرو-فرانت‌اند به عنوان؛ یک سبک معماری که اپ های مستقل و قابل تحویل فرانت‌اند باهم در مجموعه بزرگتر ترکیب شده اند، یاد شده است. در تعریف ساده تر، میکرو-فرانت‌اند، بخشی از صفحه web است( نه محتوای داخلی آن). در معماری میکرو-فرانت‌اند یک صفحه Host یا یک Container وجود دارد که میتوانید چندین میکروفرانت‌اند را میزبانی کند. صفحه Host/Container همچنین قابلیت اشتراک گذاری  کامپوننت های میکروفرانت‌اند خود را دارد. برای مثال mfe1 یک هاست هست که یک button از mfe1 دارد.معماری میکروفرانت‌اند از سه قسمت تشکیل شده:میکروفرانت‌اندهایک Host یا Containerفریم ورک میکروفرانت‌اند، اینجا از Webpack 5 Module Federation Plugin استفاده میکنیم.چرا میکرو-فرانت‌اند ؟جهت برطرف کردن مشکلات توسعه SPA فرانت‌اند، این معماری عرضه شده است. من رشد یک وب سایت را تا حدی تجربه کرده ام، مقیاس پذیری،‌ تغییر یا حتی آموزش مهندسان جدید در آن بسیار دشوار است. توسعه دهندگان بلاک یکدیگر میشوند تا تغییر کوچکی اعمال شود. برخی از مزایای میکروفرانت‌اند:مقیاس پذیری تیممسولیت یکتاقابل استفاده مجددمستقل از نوع تکنولوژی: با react یا انگولار یا ویو مهم نیست.یادگیری آسانمعماری Domain-Drivenنحوه پیاده سازی میکرو-فرانت‌اندکلید اصلی میکروفرانت‌اند، ادغام هاست و میکروفرانت‌اند هاست. دو روش جهت یکپارچه سازی یا ادغام وجود داره:۱-  یکپارچه سازی در زمان بیلد (Build-Time):روش معمول بیشتر کدهای پیاده سازی شده امروزی است. به صورت library اجزا در هاست نصب میشوند. مشابه کتابخانه های npm . مشکلات و مسائل مربوط به این رویکرد بیشتر مربوط به همگام سازی نسخه های مختلف کتابخانه هاست. همچنین استفاده از فناوری های مختلف دشوار است. همچنین سایز بسته نهایی چون شامل همه بسته های قبلی است بزرگ است.علاوه بر این، برای هر تغییر در dependecy ها باید بیلد جدید گرفت. همچنین یک رابطه محکم بین هاست و همه میکرو‌فرانت‌اندها وجود دارد.۲-  پکپارچه سازی در زمان اجرا (Run-Time):ادغام در زمان اجرا سه نوع ترکیب داره:۱- روش سمت بکند یا سرورساید:در این روش کل عملیات سمت بکند انجام میشه و بکند تصمیم میگیره که کدام میکروفرانتند اجرا بشه. سرور تصمیم میگیره که کدام مسیر نمایش داده شود. با وسیله Nginx reverse-proxy امکان پیاده سازی چنین ترکیبی وجود دارد.۲. روش سمت لبهدر این رویکرد از CDN (Ex: AWS CloudFront) و Lambda@Edge استفاده میشه. تنظیمات در cdn انجام میشود.3- ترکیب سمت کلاینتدر این روش هاست مجزا بیلد میشود و هر میکروفرانتندی هم به صورت مجزا  به عنوان یک پکیج منتشر میشود که هاست میتواند میکروفرانت هایی که نیاز هست رو فراخوانی کند. در این روش هاست و میکرو کاملا از هم جداشده و هیچگونه اشتراکی در بیلد و deploy نداشته و میتوانند از تکنولوژی های متفاوتی استفاده کنند. هاست میتواند ورژن میکروفرانتد را انتخاب کند.در این زمینه اخیرا Webpack 5 Module Federation Plugin نتایج خوبی ارائه میکند.منبع: برگرفته از مقاله#Micro-Frontends, #میکروفرانت</description><category>Masoud</category><author>Masoud</author><pubDate>Tue, 07 Sep 2021 17:48:37 +0430</pubDate></item></channel></rss>