https://virgool.ir/feed/@m0stafafa2026-11-11 10:56:12https://files.virgool.ir/upload/users/60244/avatar/PlqUpE.jpeghttps://virgool.ir/@m0stafahttps://virgool.ir/@m0stafa/معماری-پروژه-به-چه-دردی-می-خوره-whp5d47kq34lاگر بخواهیم از صفر شروع کنیم معماری پروژه یک سری کارهای اضافه هست که ما برای اینکه بعدا نگهداری نرم‌افزار رو راحت‌تر کنیم انجام می دهیم. این کارها می تواند در طول توسعه نرم افزار سرعت توسعه ما را افزایش یا کاهش بدهد.همه برنامه نویس ها در دوران ابتدایی برنامه نویسی ولع شروع سریع توسعه را دارند و در واقع دوست دارند زودتر به محصول نهایی برسند. این حس، حس خوبی است اما ممکن است هزینه آن، سختی تغییرات آینده در سیستم باشد. اگر چند پروژه مشتری محور را همزمان پشتیبانی کنید طعم آن حس خوب به یک حس بسیار بد تبدیل می‌شود و از آنجا به بعد به خودتان، مشتری، زمین و زمان فحش خواهید داد. حالا مشتری درخواست می‌دهد و شما می‌گویی نمی‌شود یا می‌بینید به صرفه نیست تغییرات را با آن قیمت همیشگی پشتیبانی اعمال کنید.حالا این ایده به ذهمان می‌رسد که باید مشتری را راضی به بازنویسی پروژه کنیم. تجربه مان افزایش یافته و قطعا اینبار پخته تر عمل می‌کنیم تا آینده نرم افزارمان شفاف تر باشد. این چرخه بر اساس جنس نرم افزار و تجربه اکتسابی ما همیشه در حال تکرار است.خب پس تا اینجا مطمئن هستیم [آن‌هایی که تجربه کرده اند] در شروع کار ولع شدید استارت توسعه را کنار بگذاریم و حداقلیات را رعایت کنیم.در یکی از پروژه های بزرگ که پروژه شامل چندین زیرسیستم بود پیش از شروع به کار یک معماری توسط تیم معماری سیستم ایجاد شد. این معماری در سمت توسعه دهنده بسیار ساده و روان بود، اما در بخش فریمورک پیچیدگی های زیادی داشت، حال همه این زیرسیستم های بزرگ و کوچک می بایست با این معماری پیش می‌رفت. معمار سیستم که تصمیم مهاجرت داشت پیش از شروع توسعه اولین سیستم از کشور رفت. حالا چند تیم بزرگ بود یک معماری بدون معمار سازنده اش و تعدادی پروژه که می‌بایست توسعه پیدا می کرد.دو سه زیرسیستم استارت خورد، بعد از مدتی کم کم مشکلات معماری مشخص می‌شد و تغییرات را معمار جدید اعمال می‌کرد. شش ماهی گذشته بود زیرسیستم ها در حال توسعه بودند که قرار شد دو زیرسیستم دیگر استارت بخورند. معمار جدید تصمیم به ایجاد یک معماری جدید برمبنای تکنولوژی های بروزتر گرفت. عده ای موافق و عده ای مخالف وجود داشت اما در نهایت اجماع با موافقان بود و معماری جدید استارت خورد، دو زیرسیستم جدید چند ماهی منتظر توسعه معماری ماندند، مشاور خارج از شرکت [آقای ارومند عزیز] نیز روال را تایید کرد و پس از اتمام فرآیند تولید معماری دو پروژه جدید استارت خورد. حالا هنوز هیچ زیرسیستمی تمام نشده بود اما معماری یکبار تغییر کرده بود!سه پروژه اول با توجه به جنس تیم ها که بیشتر مشتری محور بود تمام شد، اما پس از آن تا الان بیش از 1.5 سال از توسعه دو سیستم بعدی با معماری جدید می‌گذرد که جنس این تیم ها فنی محور بود. در این بین جلستاتی جهت بررسی علل تاخیر این دو پروژه جدید تشکیل شد اما خروجی خاصی نداشت و همچنان اجماع بر توسعه با همین روال بود.معماری جدید فقط یک معماری نبود، انبوهی از پترن ها، ابزارها و تکنولوژی ها بود که امکانات بسیار فراوان و کامل را برای توسعه هر نرم افزاری محیا می‌ساخت.فرض کنید یک خودکار را می‌خواهید تا سر کوچه ببرید:می‌توانید آن را به دست بگیرید و ببرید.می‌توانید آن را درون پاکتی قرار دهید و ببرید.می‌توانید آن را روی یک گاری قرار داده و ببرید.می‌توانید آن را بر پشت یک وانت قرار داده و ببرید.می‌توانید آن را بر پشت یک کامیون قرار داده و ببرید.و شاید ده‌ها و صدها راه دیگر، اما مسئله این است زمانیکه می‌توان یک وسیله کوچک را با دست تا سرکوچه برد چه لزومی به استفاده از کامیون برای آن است. این همان چیزی است که در این معماری در حال رخ دادن بود. حال پروژه های با پیچیدگی متوسط تبدیل به غول بی شاخ و دمی شده بودند که نه راه پس داشت و نه راه پیش. درخواست استعفای تمامی تیم موافق به معماری جدید قوز بالای قوزی شد که کمر بقیه را شکست.پس از آن نیز تصمیم به ایجاد زیرساختی یکپارچه گرفته شد که قطعا آن نیز علاج درد نخواهد بود.معماری و استفاده از ابزار خوب است اما بدون رعایت اصل KISS مخفف Keep It Simple, Stupid به معنای سادگی همه روال ها و نیز اصل YAGNI مخفف You Aren’t Gonna Need It به معنای عدم پیاده سازی چیزی که به آن نیاز ندارید، می تواند پروژه شما را به یک پروژه وحشتناک و شکست خورده تبدیل کند.نتیجه گیری اگر پروژه شما کوچک است تمپلیت پیش فرض خودش یک معماری بسیار مناسب برای شماست، اگر بزرگتر است بسته به نیازتان معماری انتخاب کنید و هیچگاه لقمه بزرگتر از دهانتان بر ندارید.مدیران باید دقت داشته باشند که عده ای ممکن است برای تست ابزارها و تکنولوژی های روز خود را پشت نام معماری و تکنولوژی ها قایم کنند این شما هستید که هزینه آن را پرداخت خواهید کرد حرف ها زیباست اما هزینه ها گزاف، مشتری شما را طرف حساب خود می داند نه تیم فنی‌تان را!در صورتیکه تیم فنی هدفشان توسعه سریع و با کیفیت نرم افزار نیست (هدف تست و ارتقا دانش تیم فنی است) پروژه نباید استارت بخورد، در این حالت یقینا منتظر شکست پروژه باشید.در مطلب بعدی قصد دارم تجربه کاملی از پیاده سازی DDD و تصورات غلطی که ممکن است در ابتدا از آن داشته باشیم را به اشتراک بذارم.مصطفیمصطفیSun, 14 Mar 2021 13:46:08 +0330https://virgool.ir/dpkharazmi/به-سادگی-اعتماد-کاری-نکنید-vegbtigflstfهر کدوم از ما نگرش و رویکردهای متفاوتی نسبت به مسائل مختلف داریم اما برخی هنجارها و ناهنجارها به صورت پیش فرض برای همه ما به یک شکل تداعی می شود.معمولا همه ما از مدیران شرکت و سازمانمون انتقاد داریم و همیشه در حال نقد و بررسی کارهای اون ها هستیم اما من میخوام امروز راجع به خودمون بنویسم.همیشه می تونیم به آدم های مختلف توی حوزه کاری سریع اعتماد کنیم. حتی یه مصاحبه خوب میتونه اعتماد ما رو نسبت به یک توسعه دهنده تحلیلگر و یا حتی مدیر پروژه کاملا جلب کنه و از روز اول روش حساب ویژه ای باز کنیم. اما آیا هزینه این اعتماد در صورت شکست به همون راحتی قابل جبران هست یا خیر؟همه ما بدنبال جلب اعتماد افراد مهم توی زندگی و کارمون هستیم. اما تا الان چند بار موقع جلب اعتماد که روزی چندین بار در حال انجامش هستیم از خودمون پرسیدیم که آیا من آدم قابل اعتمادی برای این موضوع هستم؟یقینا عده زیادی از افراد قابل اعتماد هستند اما اگر شما از اعتماد به 10 نفر در 9 مورد نتیجه مثبت ببینید و تنها در یک مورد نتیجه منفی ببینید شوکه خواهید شد و ارزش کار شما بسیار ناچیز دیده خواهد شد چرا که این شکست نتیجه اعتماد شماست اما هزینه آن را شما به تنهایی پرداخت نمی کنید، همه افراد سازمان این هزینه را پرداخت خواهد کرد. در سال های اخیر مواردی از این شکست ها برای من اتفاق افتاد. در یکی از موارد بعد از دفاع تمام قد از یکی از بچه ها در برابر مدیر بالادستی، شرایط جدیدی که درخواست خود او بود برایش ایجاد کردم بعد از آن با کم کردن حجم کاری امکان مطالعه برای حوزه جدید مد نظر وی ایجاد کردم بعد از آن دوره زمانی پروژه ای در آن حوزه برای او تعریف شد. پروژه شدیدا عقب افتاد و سوال بابت عقب افتادگی این پاسخ را بدنبال داشت: من تسلطی ندارم و انتظار شما زیاد است!اما نه پروژه بزرگ بود نه انتظار زیاد چراکه مشابه آن پروژه با افراد مبتدی تر نتیجه بسیار بهتری به ارمغان آورده بود.ذکر این نکته خیلی مهم است که مدیر بالا دستی بعد از آن جلسه آن جلسه به من گفته بود:اعتماد زیاد به افراد نکن، افراد زیادی هستند که قدر اعتمادت را نمی دانند!و دقیقا همان شد و من ماندم و یک شکست در اعتماد و برخورد سرد و طلبکارانه فرد مورد اعتماد، اما خداروشکر تبعات زیادی نداشت. از آن زمان به بعد نگرش من در حوزه اعتماد به افراد تغییر کرد که به نظرم می تونه به شما هم کمک کنه:به هیچ عنوان زود اعتماد نکنیداعتماد زودتر از موعد بزرگترین ریسکی هست که می تونه برای شما دردسرساز بشه، عجله نکنید اجازه بدید با گذر زمان ویژگی های دقیق افراد رو برای شما مشخص کنه تا بتونید تصمیم دقیقتری بگیرید.رفاقتی کار کنید اما اعتماد رفاقتی هرگزدوست شما حتما میتونه بهترین همکار شما باشه اما اگر آدم کاملا قابل اعتمادی باشه. رفاقت های زیادی دیدم که در حوزه کاری تبدیل به دشمنی شده و خب قاعدتا یکی از طرفین طعم شکست اعتماد رفاقتی را خواهد چشید.همیشه آماده شکست باشیددر بحث های دینی میگن فک کنید امروز آخرین روز عمرتونه و با اون شرایط روزتون رو بگذرونید. توی این مباحث نیز آماده باشید که فردا طعم شکست رو بچشید، پیش بینی شکست خودش بزرگترین موفقیت برای شما خواهد بود.برای هر شخص به اندازه ای که او برای سازمان ارزش قائل است اعتماد کنیدممکنه همه ما از مدیر عاملمون متنفر باشیم اما این دلیل بر تنفر از برندمون نخواهد بود. مثلا ممکنه یه بازیکن فوتبال از مدیرعامل تیمش خوشش نیاد اما هیچ دلیلی نداره مثلا به اسم تیم خودش توهین کنه و امان از افرادی که شرکت و سازمان را دشمن خودشون میدونن و هیچ ارزشی برای اون قائل نیستند. بزرگترین قمار میتونه اعتماد به این افراد باشه.همیشه اعتماد کنیددر آخر باید بگم که همیشه به افراد اعتماد کنید و به افراد مثبت نگاه کنید. حرفای من اصلا دلیل بر عدم اعتماد نیست چراکه اعتماد نتیجش حرکت رو به جلوی شرکت شما خواهد بود و عدم اعتماد شما را درجا نگه خواهد داشت. اما حتما در این موضوع دقت بسیار بکنید اعتماد کردن ساده و بی هزینه نیست. شما هم اگر تجرباتی دارید به اشتراک بذارید تا همه بتونیم ازش استفاده کنیم.مصطفیمصطفیWed, 28 Oct 2020 13:52:40 +0330https://virgool.ir/dpkharazmi/نیروی-انسانی-کلیویی-چنده-kqcje0aikmxfیکی از پرچالش ترین بحث های حوزه آی تی منابع انسانی هست. از خلق و خوی برنامه نویس ها گرفته تا بد اخلاقی مدیران، همه و همه دست به دست هم میدن تا منابع انسانی یک شرکت از دست برن.مهمترین ارزش یک شرکت به منابع انسانی اون شرکت هست. هر چقدر منابع انسانی یک شرکت توانمندتر، شرکت توانمندتر و هر چه منابع انسانی ضعیف تر شرکت ضعیف تر خواهد بود.قصد دارم توی این مقاله چند مورد از رخدادهایی که می تونه به هر شرکتی توی استخدام، ارزشمند سازی و حفظ نیروی انسانی کمک کنه اشاره کنم و امیدوارم بتونه کمکی برای شما باشه.خودمون باید نیروی حرفه ای بسازیماول از هر چیز این نکته رو باید همیشه به یاد داشته باشیم که تقریبا در هیچ موردی پیدا نمیشه که شما بتونید یک نیروی فوق العاده نسبت به کل شرکتتون استخدام کنید دلایل مختلف داره مثل تفاوت تکنولوژی های شرکت های مختلف و قاعدتا عدم تسلط نیروی جدید و یا عدم توانایی شرکت ها برای استخدام نیروی گرانقیمت به تناسب مهارت و... .باید یاد بگیریم نیروی انسانی حرفه ای شرکت رو خودمون پرورش بدیم و به نقطه اوج برسونیم. دلیل اول رو توی بند قبل گفتم و دلایل دیگر هم این هست که پرورش یه نیروی خوب خیلی سریعتر، کم هزینه تر و راحت تر از استخدام یک نیروی خوب هست.نیرو خوب همواره بدنبال رشد استدر حوزه آی تی سه نوع رشد داریم:رشد فنیرشد مالیرشد شغلیعموم افراد به دنبال دو مورد اول هستند بسته به شرایط برخی بدنبال رشد فنی و برخی بدنبال رشد مالی به تناسب هستند. اما رشد شغلی عموما در رده های بالاتر سازمان و شرکت ها دیده می شود.همیشه باید آماده این باشید که درخواست های مربوط به رشد به سمت شما ارسال بشه اما خب به یقین امکان ارتقا همه افراد میسر نیست. عموما تعداد زیادی از این درخواست ها بی مبنا و با هدف رشد نوع دوم یعنی مالی هست.در این شرایط می بایست روال های مربوط به ارتقا افراد را در سازمان و شرکت خودتون تدوین کنید که اولا تعداد درخواست های بی مورد کاهش و از سوی دیگر افراد از آگاهی کامل برای نحوه ارتقا با خبر بشن. در این شرایط اگر کسی درخواست داد و تونست روال مربوط به ارتقا رو به خوبی طی کنه (مثلا مصاحبه مجدد و...) چرا نباید ارتقا داشته باشه؟ اگر شرایط این امر وجود داشت حتما باید اینکار رو انجام بدید. چرا نیروها فرار می کنند؟دلایل مختلفی برای خروج نیروی انسانی از شرکت وجود داره. اگر تیتر وار بخوام برخی از این دلایل رو ذکر کنم میشه به موارد زیر اشاره کرد:قوانین سخت گیرانه شرکت و سازمانرفتار نامناسب مدیران شرایط کاری نامناسبعدم تطابق کار با تصورات افراد (عدم شفافیت در زمان استخدام)عدم تطابق حقوق دریافتی و شغل فردعدم امکان رشد فنی و...عموما علت ترک کار نیروهای فنی ذهنی و روانی است و مهمترین عامل در حفظ آن توجه و تاکید بر ایجاد آرامش برای افراد. اگر فردی به شما اعلام کرد که از لحاظ ذهنی در شرکت تحت فشار است مطمئن باشید جایی از کار شما میلنگه! مثلا اگر شما یا فردی صب از خواب بیدار شد و با خودش گفت اه بازم باید برم توی اون خراب شده و این موضوع به صورت بلند مدت طول کشید یقینا سازمان و شرکت داره در مسیر غلط راه میره! در این نقطه حتما باید اصلاحات زیادی رخ بده تا اینکه شرایط مجددا به مسیر درست خودش برگرده.اگر فردی بخاطر حقوق دریافتی درخواست خروج از سازمان رو داشت حتی اگر با افزایش حقوق اون موافقت کردید از فردای اون روز آمادگی درخواست مجدد فرد برای خروج از سازمان رو داشته باشید. همیشه باید سعی بر اون داشته باشید که ارزش های غیر مالی شرکتتون اونقدر زیاد باشه که انگیزه مالی کم رنگ بشه چرا که انگیزه مالی انتها نداره.افراد منتظر تغییر و تقویت روحیه اندانسان همیشه بدنبال تغییر به سمت بهتر شدن هست، باید دقت کنیم در این موضوع بخوبی عمل کنیم. روحیه افراد گروه شما میتواند سازنده و ویرانگر باشد. تکنیک های مختلفی برای افزایش روحیه فرد وجود دارد از تشویق ساده کلامی گرفته تا تشویق به صورت گیفت یا هدیه. اما مراقب باشید تشویق را حتی الامکان به سمت تشویق‌های مالی (نقدی) نبرید. یکی دیگر از آیتم های موثر در روحیه افراد تغییرات محیطی فضای کار است. از تغییر در چیدمان گرفته و دکوراسوین تا ابزارهای کاربردی کاری. این موضوع روحیه افراد رو رفرش می کند و به شما کمک می کند تا با چالش های کمتری در حوزه ذهنی افراد مواجه شوید.اخلاق یا مهارتهمیشه موقع مصاحبه با افراد اولین پارامتری که توی ذهن شما هست بررسی وضعیت فرد از لحاظ فنی و مهارت هاست. اما جدای از اون اخلاق هم باید به صورت جدی مورد بررسی قرار بگیره. حوزه آی تی و دنیای برنامه نویسی بسیار شبیه به فوتباله، یک فرد بی اخلاق با مهارت بالا می تونه یک شرکت رو نابود کنه دقیقا مثل فوتبال که یک بازیکن بی اخلاق با تکنیک بالا میتونه منجر به باخت تیمش بشه. شما می تونید مهارت یک فرد رو ارتقا بدید اما تغییر در اخلاق یک فرد برای شما تقریبا محال خواهد بود.به هیچ عنوان یک فرد بی اخلاق را استخدام نکنید چرا که همیشه آسیب بیشتری از کاری که برای شما می کند خواهد داشت.در آخر باید بگم که اولین برنامه ریزی باید برای نیروی انسانی سازمان و شرکت انجام بشه چرا که مهمترین ارزش شرکت شماست و اگر این موضوع رو شوخی گرفتید یا اهمیتی به این موضوع ندادید خودتون رو برای چالش های بسیار بزرگ آماده کنید.امیدوارم این پست بتونه کمکی برای شما باشه و در فرصتی دیگه سعی میکنم با یه پست دیگه این مبحث رو کاملتر کاملتر کنم.مصطفیمصطفیMon, 13 Jul 2020 11:35:18 +0430https://virgool.ir/dpkharazmi/سیر-تحول-frontend-و-angular-و-ux-توی-شرکت-ما-zixkjia6vwebاین اولین مطلبیه که من داخل سایت ویرگول مینویسم. امیدوارم بتونم با نوشتن به ارتقا دانش خودم و شما کمک کنم.من توی شرکت خوارزمی کار میکنم. اوایل همه از شرکت بد میگفتن ولی من امید داشتم که شرکت در آینده میتونه خیلی پیشرفت های خوبی توی حوزه برنامه نویسی داشته باشه. ترجیح میدم سال دیگه راجع به این موضوع یه پست کامل بذارم.قبل از اینکه من توی شرکت استخدام بشم AngularJs بعد از JQuery به عنوان زبان frontend شرکت انتخاب شده بود که به توسعه برنامه نویس ها بسیار کمک می کرد. تیم زیساخت اون زمان یه package برای شرکت نوشته بود که برنامه نویس ها خیلی راحت میتونستن با چند خط کد به حالت scaffolding صفحات CRUD (فرم های ایجاد، نمایش، آپدیت و حذف) خودشون رو طراحی کنن. این داستان برای برنامه نویس هایی که با فسیل شدن مشکل نداشتن خیلی خوب بود، راحت کد میزدن، نیاز به فکر نداشتن، اگرم مشکلی پیش می اومد میرفتن رو سر تیم زیرساخت خراب می شدن و تیم زیرساخت باید مشکلاتشون رو حل میکرد.angular typescriptمن که اومدم شروع کردیم به سوییچ روی Angular 2. شرکت ما پر از برنامه نویس های دات نت بود که وجود TypeScript در Angular 2 به ما کمک می کرد که بچه ها خیلی راحت بتونن با Angular ارتباط برقرار کنن.خلاصه شروع کردیم به ساختن یک ساختار جدید، ما شرکت هستیم و علی الله هی نمیتونیم پروژه بالا بیاریم پس لازم بود اول یه سری قوانین در نظر بگیریم که همه پروژه ها شبیه هم باشن و اگه یه برنامه نویس از یه پروژه رفت روی یک پروژه دیگه دچار سردرگمی نشه و در سریعترین زمان ممکن شروع به کار کنه.بعدا سر فرصت روال تکامل ساختار پروژه هامون از اول تا امروز رو توضیح میدم. سعی من این بود که برنامه نویس ها بیشتر با Angular درگیر بشن و ما کتابخونه ای برای scaffolding نسازیم که طرف نفهمه چی شد اصلا و اگه دو روز دیگه رفت خارج بهش نگن هیچی حالیت نیست.اولین پروژمون استارت خورد رفت جلو، توی ساختار اولیمون برای یه سری کارهای روتین یه سری چیزا تعریف کرده بودیم که کارها راحت شه، بعد از یه مدیت دیدیم کافی نیست و رفتیم سراغ توسعه بیشتر کامپوننت ها و سرویس ها و دایرکتیوها و... به محض شروع دومین پروژمون دیدم عه یه سری اشتراکات داریم که توی این پروژه هم نیازه استفاده بشه، رفتیم سراغ پکیج نویسی و اولین پکیجمون رو توسعه دادیم و از اونجا به بعد اونو به پروژه ها رفرنس دادیم.ngxsتوی یکی از پروژه ها به یه مشکلی برخوردیم که نیاز بود یه دیتایی همزمان توی چند جا تغییر کنه که در حالت عادی کار سختی بود. رفتیم سراغ Redux ، چند تا کتابخونه رو مطالعه کردیم و از بینشون NGXS رو انتخاب کریم چون از همه ساده تر بود و خیلی راحت می شد آموزشش داد و کار ما رو هم به صورت کامل راه مینداخت.همزمان با این موضوع دیدم توی پروژه های مختلفمون ظاهرهای متفاوتی داریم میبینیم. یه پروژه یه ظاهر میبره جلو اون یکی پروژه یه شکل دیگه. تصمیم گرفتیم بحث UX رو جدی تر کنیم، و با ابزار Justinmind شروع کردیم ولی بعد اکسپایر شده نتونیستیم کرک کنیمش (اگه کسی کرکشو داره بذاره توی کامنت شاید کسی نیازش شد) رفتیم سراغ Adobe XD و دیدیم اینم نرم افزار قدری هست و تقریبا همه چیز رو پوشش میده. حالا تیم UX شرکت ظاهر صفحات رو طراحی میکرد، توی جلسات شرکت میکرد و با نظر اون تیم ظاهر صفحات دیزاین می شد و دیگه پروژه ها ظاهر متحدالشکلی بخودشون گرفت.ما با یه روشی ساختار تم رو از پروژه ها مجزا کردیم و در واقع پروژه هامون رو تم پذیر کردیم، البته تم ما فقط شامل فایل های sass، تصاویر، فونت ها و از این دست فایل ها بود. حالا میتونستیم با تغییر یک خط کد از یه تم به یه تم دیگه سوییچ کنیم. البته ما تم هامون رو هم رنگ پذیر کردیم و میتونستیم با یه خط کد دیگه رنگ تم رو مثلا از آبی به قرمز سوییچ کنیم. primengیک نکنه که فراموش کردم بگم اینکه ما PrimeNg رو به عنوان کتابخونه UI خودمون انتخاب کردیم و همه قالب هایی که طراحی کردیم با اون بود، اون زمان که این کتابخونه رو انتخاب کردیم یه تجربه با material داشتیم و تجربه تلخی برای کاربرای بانکی بود ولی این کتابخونه کاملا مورد پسند کاربر ما قرار گرفت. تنها مشکلی که داشت این بود که برای بعضی از ابزارهاش راست چین رو پشتیبانی نمی کرد که مجبور شدیم خودمون راست چینشون کنیم.بعد از یه مدت با مفهومی به اسم MonoRepo آشنا شدیم که تحقیق راجع به اون ما رو با NX آشنا کرد. NX به ما کمک میکرد برای پروژه های بزرگ با تیپ کاری ما یه معماری شسته رفته تر داشته باشیم و بتونیم از امکانات MonoRepo (بعدا راجع بهش مفصل توضیح می دم) استفاده کنیم.بعد از اولین پابلیش متوجه حجم بالا و کندی شدید پروژه شدیم، حجم فایل main.js حدود 16 مگ شده بود. رفتیم سراغ AOT و Production Build و نهایتا با حجم بسیار بسیار کمتر و سرعت لود بسیار بالاتر پروژه رو deploy کردیم.بعد از دو سال تقریبا به یک نقطه استیبل رسیدیم و داریم تکنولوژی های جدید رو بررسی می کنیم تا بر اساس نیاز اون ها رو به پروژه ها اضافه و مورد استفاده قرار بدیم. اگر شما هم یه توسعه دهنده Angular یا حتی الباقی زبان های JavaScriptی باشید حتما با خیلی از مسائلی که گفتم رو به رو شدید. خوشحال میشم تجربیاتتون رو به اشتراک بذارید تا ما هم بتونیم از اون ها استفاده کنیم.مصطفیمصطفیSun, 16 Feb 2020 17:40:00 +0330