کتاب آنلاین تکنیک های مدرن یادگیری عمیق در پردازش زبان طبیعی

این #کتاب آنلاین مباحث زیادی را پوشش داده که برای علاقه مندان و حوزه #NLP مطالعه کتاب پیشنهاد می شود.
در تصویر بالا فهرست مطالب پوشش داده شده در این کتاب را مشاهده می کنید.
لینک کتاب: nlpoverview.com

@silicon_brain

مالک محصول کیست و چه کاری انجام می دهد؟

گاهی فرایند اضافه کردن ویژگی‌های جدید به محصول انقدر واضح و منطقی به‌نظر می‌رسد و ویژگی‌ها آنچنان جذاب و هیجان انگیز هستند که افراد تیم به سرعت دست‌به‌کار می‌شوند تا بدون فوت وقت ویژگی‌های جدید را طراحی و به محصول اضافه کنند. در ابتدای کار همه چیز ظاهرا درست پیش می‌رود اما وقتی زمان اضافه کردن این ویژگی‌ها به محصول فرا می‌رسد و آن‌ها در کنار محصول قرار می‌گیرد همه چیز تغییر می‌کند.

به این ترتیب آن‌چه که زمانی بسیار واضح و روشن بود به فرایندی مبهم و سخت تبدیل می‌شود چرا که گاهی ویژگی‌های طراحی شده با ارزش‌های اصلی هم‌خوانی ندارند. این باعث به وجود آمدن سوالات و ابهام‌هایی‌ برای گروه‌های مختلف ذینفعان می‌شود و کار به جایی می‌رسد که اعضای تیم از خود می‌پرسند: چرا ما این ویژگی را ایجاد کرده‌ایم؟ اصلا چه کسی آن‌را را درخواست کرده است؟

این اتفاق زمانی اتفاق می‌افتد که نقش مالک یا صاحب محصول (Product Owner) درنظر گرفته نشده باشد، محصول بدون مالک شبیه زورقی است که سکان ندارد، ممکن است پیشرفت کند اما هیچ تضمینی وجود ندارد که این مسیر در جهت مقصد موردنظر باشد. چنین زورقی ممکن است فقط دور خود بچرخد یا حتی بدتر از آن تعادل خود را از دست داده و غرق شود!

اینجاست که اهمیت نقش مالک محصول مشخص می‌‌شود. مالک محصول نقشی است که در اسکرام (scrum) معنی پیدا می‌کند و با مدیر محصول (Product Manager) متفاوت است. مالک محصول کمک می‌کند تا مسیر طراحی و بازطراحی محصول در جهت مقصد مورد نظر قرار گیرد. برخی از نکات اصلی در مورد نقش مالک محصول عبارتند از:

۱- مالک محصول مسئول به حداکثر رساندن ارزش محصول از طریق کار تیم توسعه است.
۲- مالک محصول یک نفر است ، نه یک کمیته.
۳- ممکن است مالک محصول خواسته‌های یک کمیته را انعکاس دهد ، اما هماهنگی برای اولویت‌بندی و تغییر اولویت موارد مطرح شده با مالک محصول است و هیچ‌کس نمی‌تواند تیم توسعه را مجبور به انجام روندی متفاوت کند.

به طور کلی مالک محصول کسی است که محصول را کاملا می‌شناسد و به همه جوانب آن آگاهی دارد. او می‌داند که محصول چگونه کار می‌کند، چه کسی از آن استفاده می‌کند، چه زمانی از آن استفاده می‌شود، چرا از آن استفاده می‌شود و از همه مهم‌تر می‌داند که چه چیزهایی در ارتقای محصول موثر نیست و تاثیری در بهتر شدن آن ندارد.

مالک محصول باید توانایی این را داشته باشد که با اقتدار در مورد هر یک از ویژگی‌های محصول، ارزشی که محصول ارائه می‌دهد و قوانین کسب‌و‌کار آن صحبت کند. همچنین نیاز است که درک گسترده‌ای از فناوری و فرصت‌ها یا چالش‌هایی که برای محصول ایجاد می‌کند داشته باشد.

برخی از کارهای مالک محصول عبارتند از:
- همدلی با مشتری
- تعیین چشم انداز و هدف برای تیم
- تعیین اولویت‌ها
- مدیریت ذینفعان
- برنامه ریزی برای نقشه راه

مالک محصول ترکیبی است از نقش‌های طراح محصول، تحلیلگر تجارت ، مدیر پروژه ، تحلیلگر بازاریابی و همچنین چندین نقش دیگر. مجموعه مهارت‌ها و مسئولیت‌های مالک محصول گسترده است و برای سازمان‌ها، تیم‌ها و افراد مختلف بسیار متفاوت خواهد بود، اما صرف نظر از سناریو، ویژگی‌های اصلی "صدای مشتری" بودن و شناخت محصول و حمایت از آن همیشه برای مالکان محصول وجود دارد.
اگر به مباحث اسکرام و شناخت بیشتر نقش مالک محصول علاقه‌مندید این مقاله را بخوانید.

http://bit.ly/dxgn786

زمان حدودی مطالعه: ۷ دقیقه

نویسنده: فیروزه ایمانی

#طراحی_محصول #رابط_کاربری #مالک_محصول #اسکرام

@Dexign فلسفه دیزاین

______

بالاخره golang هم generic دار شد!

طبق این پروپوزال، امکان استفاده از generic به نسخه Go 1.18 اضافه می‌شود و در سال 2022 منتشر خواهد شد. اما نکته جالب در مورد تغییر این است بر خلاف بیشتر زبان‌ها که مفهوم جنریک با
Foo<T>
نماش داده می‌شود، در Go این مفهوم به صورت
Foo[T]

نمایش داده خواهد شد و برای این تصمیم هم دلیل جالبی وجود دارد که در این مستند توضیح داده شده‌است.

نکته جالب‌تر این است که این چالش هنگامی که Generic به زبان C# در نسخه 2.0 هم اضافه شد وجود داشت و باعث ایجاد یک Breaking Change از نسخه 1.0 به نسخه 2.0 شد. در این پست سعی می‌کنم این مشکل را با یک مثال از توییتی که Eric Lippert در این مورد زده توضیح بدم.

عبارت زیر را در نظر بگیرید:
A(B<C,D>E())

این عبارت در نسخه 1.0 و در نسخه 2.0 به دو طریق مختلف ترجمه می‌شود. که در کد زیر سعی کردم با فاصله‌گذاری‌های متفاوت آن را نشان دهم.

// C# 1.0
A( B<C , D>E() )

// C# 2.0
A( B<C,D> E() )

همانطور که می‌بینید در نسخه 1.0، فراخوانی متد A با دو پارامتر ورودی انجام شده و علامت < و > به عنوان علامت‌های کوچکتری و بزرگتری تفسیر شده‌اند، اما در نسخه 2.0 این عبارت فراخوانی متد A با یک ورودی جنریک است.

نکته جالب دیگر این است که generics به عنوان یک ویژگی بسیار مهم، تقریبا در سال 2002 به C# اضافه شد و پس از ۲۰ سال قرار است به زبان Go اضافه شود.

در این مدت برخی طرفداران زبان Go نبود این امکان را این گونه توجیه می‌کردند که این یک نقص نیست و تصمیم طراحی بوده که این زبان این امکان را نداشته باشد. به هر حال دیگر نیازی به توجیه نیست و از این به بعد هنگام استفاده از زبان قدرتمند Go از generic ها هم می‌توانید استفاده کنید.

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

#مهران_داودی (لینکدین - بلاگ)


کانال تلگرام:
@SoftwarePhilosophy

________

مدل انتخاب سخت؛
چه نوع تصمیمی می‌گیرم؟

معمولا بین راه‌حل‌هایی که در چالش‌های دیزاین پیدا می‌کنیم دچار تردید در گرفتن تصمیم می‌شویم که درواقع «مدلِ انتخابِ سخت» می‌تواند به نوع تصمیمی که می‌گیریم کمک کند - چه بی‌فکر باشد، چه انتخاب سختی باشد یا چیزی بین این دو. این مدل تصمیم‌گیری، شمارا قادر می‌سازد که تا با تصمیم خود، رو به جلو حرکت کنید.

نحوه استفاده از آن
به دو عامل تصمیم خود فکر کنید:

۰ چقدر تأثیرگذار است؟
۰ مقایسه‌ی گزینه‌هایی که وجود دارد چقدر آسان است؟

چهار نوع تصمیم وجود دارد که می‌توانید بگیرید. این مدل، آن‌ها را بر اساس این دو عامل تقسیم می‌کند:

انتخاب بدون فکر
«تصمیم‌گیری با تأثیر کم در جایی که مقایسه‌ی گزینه‌ها آسان باشد.»
در اینجا می‌توانید سریع حرکت کنید و از روی حس خود جلو بروید.

انتخاب تصفیه‌ای
«تصمیم‌گیری با تأثیر کم در جایی که مقایسه‌ی گزینه‌ها دشوار است.»
باید گزینه‌های خود را بر اساس آنچه واقعاً برای شما مهم است تصفیه و اصلاح کنید.

انتخاب بزرگ
«تصمیم‌گیری با تأثیر زیاد در جایی که مقایسه‌ی گزینه‌ها آسان باشد.»
قبل از تصمیم‌گیری کافی است که شجات و اعتماد‌به‌نفس اجرای آن را پیدا کنید.

انتخاب سخت
«تصمیم‌گیری با تأثیر زیاد در جایی که مقایسه‌ی گزینه‌ها دشوار است.»
در این حالت‌، ابزاری مانند ماتریس تصمیم‌گیری می تواند به شما در ارزیابی دقیق گزینه‌ها بر اساس عوامل مختلف کمک کند. هدف شما باید این باشد که بازخورد دریافت کنید، ریسک‌ها را کاهش دهید و همچنین با جسارت آن تصمیم را اجرا کنید.

به جلو حرکت کنید
وقتی بتوانید با استفاده از این مدل، تصمیم خود را دسته‌بندی کنید، این امکان برای شما فراهم می‌شود که بتوانید اقدام مناسب را انجام دهید.

مطلب بالا برگرفته شده از لینک زیر است، می‌توانید در این لینک اسکرول کنید و مدل‌های ذهنی دیگری که برای دیزاینر‌ها مفید است را نیز مطالعه کنید.

http://bit.ly/dxgn787

(زمان حدودی مطالعه‌: ۱۰ دقیقه)

نویسنده: حسین میرزاده

#تصمیم_گیری #مدل_انتخاب_سخت #تصمیم

@Dexign فلسفه دیزاین

______

لطفا (اگه می‌تونید) از Span استفاده کنید!

یکی از متداول‌ترین کدهایی که نوشته می‌شه زمانیست که می‌خواهیم کاری را با تایپ immutable انجام دهیم.

مثلا زمانی که می‌خواهیم قسمتی از یک string را داخل متغیری بریزیم.

همانطور که می‌دانید این کار باعث می‌شود محلی از حافظه Heap اشغال شود.

[سمت راست تصویر]

روش بهتر به جای استفاده از یک متغیر از نوع string استفاده از یک متغییر از نوع Span است، چرا که در این حالت به خاطر استفاده از ref struct به جای استفاده از Heap از Stack استفاده می‌شود.

[سمت چپ تصویر]

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۱: توجه کنید که در اینجا اولین مقداری که داخل تایپی از نوع Span یا مشتقاتش (ReadOnlySpan و ...) می‌ریزید مثل قبل داخل Heap قرار دارند. اما از آن به بعد هر بلایی که سر اون متغیر بیاورید توی Stack ذخیره می‌شود.

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۲: استفاده از این تکنیک یکی از دلایلی ست که باعث افزایش سرعت و کاهش memory allocation در Kestrel شده است.

➖➖➖➖➖➖➖➖➖➖➖

❗️نکته۳: دلیل متن داخل پرانتر عنوان این پست (اگه می‌تونید) این است که از این تکنیک همه جا نمی‌شود استفاده کرد. مثلا در Class ها نمی‌توان متغیری از این نوع تعریف کرد. یا هنگام Boxing. یا در ساختار های await و yeild و ...

یک مثال از نحوه تعریف یک متغییر از این نوع:

public DateTime Span()
{
     ReadOnlySpan<char> dateSpan = "01 05 1991";
     var day = dateSpan.Slice(0, 2);
     var month = dateSpan.Slice(3, 2);
     var year = dateSpan.Slice(6);
     return new DateTime(int.Parse(year), 
                         int.Parse(month), 
                         int.Parse(day));
}

➖➖➖➖➖➖➖➖➖➖➖

✅ نتیجه: استفاده کردن از این امکان در صورتی که میسر باشد باعث افزایش سرعت و اختصاص بهینه حافظه می‌شود.

➖➖➖➖➖➖➖➖➖➖➖

در این پست علاوه بر توضیحات بیشتر و دقیقتر، نتیجه این امکان زبان سی شارپ در قالب یک Benchmark نمایش داده شده است.

نسخه ویدیویی همین پست

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

چگونه هوش مصنوعی بر طراحی UX تاثیر می‌گذارد؟

امروزه، هر بخش تجاری و صنعتی از هوش مصنوعی (AI) برای خودکارسازی فرآیندها، بهبود کارایی خود و کاهش هزینه‌ها استفاده می‌کند. صنعت دیجیتال نیز از هوش مصنوعی به طور خاص برای بهبود تجربه کاربر استفاده می‌کند.

در این مقاله، برخی از تأثیرات هوش مصنوعی بر تجربیات کاربر، اینکه هوش مصنوعی کدام‌ یک از فرآیندهای UX را می‌تواند کارآمدتر کند، چگونه می‌تواند به طراحان UX کمک کند و چطور ممکن است بر مشاغل طراحی UX در آینده تأثیر بگذارد، صحبت می‌شود.

تاثیرات هوش مصنوعی بر تجربیات کاربر
از برخی جهات، هوش مصنوعی یا یادگیری ماشین (ML) و طراحان UX عملکردهای مشابهی دارند. آن‌ها، هم داده‌ها را جمع‌آوری می‌کنند، هم تعاملات کاربران را تجزیه و تحلیل می‌کنند و هم می‌توانند رفتار انسان را پیش‌بینی کنند. چت‌بات‌ها، ماشین‌های خودران، هواپیماهای بدون سرنشین، گوگل ترنسلیت، الکسا و سیری همگی نمونه‌های کاملی از هوش مصنوعی هستند که از داده‌های گذشته برای ارائه خدمات پیشرفته استفاده می‌کنند. پیشرفت در هوش مصنوعی و فناوری یادگیری ماشینی، توسعه تجارب کاربر را ممکن ساخته است. به صورت موردی، تاثیرات هوش مصنوعی بر تجربیات کاربر شامل این است: رابط‌های کاربری ظریف‌تر، جلوه‌های بصری و توانایی بیشتر در شخصی‌سازی سیستم‌ها.

تقویت فرآیندهای UX از طریق هوش مصنوعی
دلیل اصلی استفاده از هوش مصنوعی کاهش نیاز به توجه انسان است. در زمینه طراحی UX، هوش مصنوعی یا یادگیری ماشین، اکنون می‌تواند فرآیندهای UX از جمله تجزیه و تحلیل داده‌ها، وایرفریمینگ و تست A/B را تقویت کند.

چگونه هوش مصنوعی می‌تواند به طراحان UX کمک کند؟
هوش مصنوعی و یادگیری ماشین برای مدت طولانی به توسعه‌دهندگان و طراحان کمک می‌کند تا بسیاری از فرایندهایشان را خودکار کنند. مثلا در مرحله تصمیم‌گیری، هوش مصنوعی می‌تواند با در اختیار قرار دادن گزینه‌های کمتر اما بهتر به طراحان UX، به آن‌ها در تصمیم‌گیری سریع کمک کند. تصور کنید گزینه‌هایی را که در نتیجه‌ی تحلیل اقیانوسی از داده‌ها در کمترین زمان ممکن تولید شده باشند چقدر در ارائه تجربه‌‌ای بهتر موثرند.

آیا هوش مصنوعی می‌تواند مشاغل طراحی UX را تصاحب کند؟
هوش مصنوعی می‌تواند به طراحان UX کمک کند تا تجربیات کاربری شخصی‌سازی شده‌ای را ایجاد کنند که نیازهای فردی کاربران را برآورده کند. به علاوه، می‌تواند با کمک به طراحان UX در طراحی و مدیریت خدمات مشتری، در زمان و تلاش آن‌ها صرفه‌جویی کند.

در حقیقت، هوش مصنوعی هنوز در مرحله یادگیری خود است. در حالی که می‌تواند از تجربیات انسانی بیاموزد، اما هنوز توانایی تفکر را ندارد. یک هوش مصنوعی در تلاش برای حل مسائل پیچیده طراحی که طراحان UX به راحتی می‌توانند آن را حل کنند، ناکارآمد خواهد بود. بنابراین، هوش مصنوعی جایگزین طراحان UX نخواهد شد. اما توسعه روزافزون قابلیت‌های هوش مصنوعی نشان می‌دهد که نقش آن‌ها ممکن است در آینده متفاوت باشد.
ممکن است زمانی فرا برسد که فناوری‌های ML آنقدر توسعه یافته باشند که تمام کاری که برای یک طراح UX باقی می‌ماند کارهای بسیار خلاقانه باشد.

در نهایت مهم نیست که هوش مصنوعی چقدر تکامل می‌‌یابد، حتی اگر بتواند از تجربیات خود بیاموزد، نمی‌تواند به توانایی مستقل، نوآورانه و تفکر خلاقی که فقط ذهن انسان دارد، دست یابد. بنابراین، در آینده قابل پیش‌بینی، هیچ خطری وجود ندارد که هوش مصنوعی جایگزین شغل طراح UX شود.

https://bit.ly/dxgn907

(زمان حدودی مطالعه: ١٠ دقیقه)

نویسنده: نیلوفر موجودی

#هوش_مصنوعی #طراحی_تجربه_کاربری

@Dexign فلسفه دیزاین

_______

کامپایل در انگولار

در انگولار دو نوع کامپایل وجود دارد:

• JIT (Just In Time)
• AOT (Ahead Of Time)

اگر بخواهیم تفاوت این دو نوع کامپایل را در یک جمله خلاصه کنیم، کامپایل از نوع JIT کد شما را در زمان اجرا در مرورگر کامپایل می‌کند ولی AOT کد شما را در زمان build کامپایل می‌کند.

اگر بخواهیم دقیقتر در مورد تفاوت دو مورد تو ضیح دهیم:

در کامپایل JIT دائما قسمتی از کد که نیاز است در لحظه اجرا شود، کامپایل می‌شود، دقیقا قبل از اینکه برنامه شما در مرورگر نمایش داده شود.

در کامپایل AOT کل کد شما در زمان build شدن کامپایل می‌شود و هر قسمتی از کد که برای انگولار قابل شناسایی ولی برای مرورگر نیست مثل directives یا pipe ها به فایل‌های جاوااسکریپت تبدیل می‌شوند و برای مثال خطاهای binding در تمام تمپلیت‌ها شناسایی می‌شود، در صورتی که این برای یک کامپوننت در کامپایل JIT زمانی اتفاق می‌افتد که شما آن کامپوننت یا فانکشن را مستقیما اجرا کنید.

ویژگی‌های دیگر این دو نوع کامپایل:

🔶 کامپایل JIT:

🔸سایز bundle در این نوع کامپایل زیاد است.

🔸سرعت لود شدن برنامه پایین است چون این کامپایل در زمان اجرا اتفاق می‌افتد.

🔸سورس کد شما در این نوع کامپایل قابل مشاهده‌ست و به همین دلیل برای development mode بسیار مناسب است.

🔶 کامپایل AOT:

🔸سایز bundle در این نوع کامپایل پایین است.

🔸سرعت لود برنامه بالاست چون دیگر نیازی نیست که کامپایلی انجام شود، در واقع فقط یک‌ بار به صورت کامل در زمان build کامپایل می‌شود و بعد مستقیم توسط مرورگر قابل اجراست.

🔸سورس کد شما دیگر در دسترس نیست ولی در عوض از نظر امنیتی ریسک خیلی پایینی دارد.

🔸برای production mode بسیار مناسب است.

تا انگولار 8 کامپایل پیشفرض به صورت AOT بود ولی از انگولار 9 به بعد به صورت پیشفرض کامپایل JIT انجام می‌شود. هر چند که کامپایل به صورت AOT همچنان به راحتی قابل دسترس است.

❇️ کامندهای هر کامپایل:

JIT: ng build or ng serve

AOT: ng build --prod or ng build --aot

#حسن_یوسفی (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

اگه می‌خواین بدونین فرق Blazor server و Blazor WASM تو چیه این مطلب رو بخونین:

در Blazor Wasm:
‌ وب اسمبلی بلیزر روی بروزر کلاینت اجرا می‌کنه و مثل انگولار و ری اکت تو اولین ریکوست CLR, Assemblies, JavaScript, CSS رو دانلود می‌کنه. تو این حالت blazor JavaScript Handler به DOM دسترسی داره و می‌تونه تغییرات رو اعمال کنه.

در Blazor Server:
کد سی شارپ نوشته شده سمت سرور ران می‌شه و javaScript hookهایی هستن که به DOM دسترسی دارن و می‌تونن تغییر ایجاد کنن. تو این حالت باینری مسیج‌هایی وجود داره که اطلاعات رو بین سرور و کلاینت با استفاده از SignalR رد و بدل میکنن. این کار رو فایلblazor.server.js که تو فایل _layout.cshtml قرار داره، انجام می‌ده. در واقع اگر تغییری لازمه باشه، این تغییر با یه update message به دست کلاینت می‌رسه و DOM با توجه به اون بروز می‌کنه.

معایب و مزایای هرکدوم از این دو حالت رو می‌تونید تو این لینک بخونید.

⁉️ سوالات و نکات خود را در قسمت کامنت با ما در میان بگذارید.

#مریم_داودی (لینکدین)

کانال تلگرام:

@SoftwarePhilosophy

_______

معماری نرم‌افزار مانند معماری ساختمان یک هنر است

آیا تا به حال به فرق یک معمار و یک مهندس عمران فکر کرده‌اید؟ تمرکز مهندسان عمران معمولا بر ساخت سازه‌ها است. آنها فکر می‌کنند چطور سازه‌هایی مانند دیوار، در، پنجره و سایر اجزا را به طور صحیح بسازند. از طرف دیگر معمارها معمولا به اینها فکر نمی‌کنند! تمرکز اصلی آنها روی ساخت و معماری فضاهایی است که بین این اجزا به وجود می‌آید. در حقیقت مهندسین عمران به دیوارها فکر می‌کنند و معمارها به فضای بین دیوارها.

نکته جالب این است که انسان‌ها یا مشتریان در نهایت از فضا‌ها استفاده می‌کنند نه دیوارها! آنها پول خرج می‌کنند تا فضای زیبایی بخرند و به ندرت دیوارها را می‌بینند.

در مهندسی نرم‌افزار، ساخت دیوار مانند کد نویسی است. برنامه‌نویسان با کد نویسی در حقیقت در حال ساخت دیوارهایی هستند که این دیوارها مستقیما برای مشتری معنی ندارد. مشتریان امکاناتی را می‌بینند که توسط این کدها برای آنها خلق شده‌است. یکی از وظایف یک مهندس نرم‌افزار تمرکز بر فضاهای ایجاد شده برای مشتری است. اینکه این فضاها چقدر کارا و مفید طراحی شده‌اند.

توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را می‌توانید در لینک زیر بخوانید.


http://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/


#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy

_____

📽 اگه دوست دارید مسیر دیزاینر شدن رو بشناسید، در لایو اینستاگرامی آکادمی دیزاین که برگزار می‌شه شرکت کنید.

چهارشنبه ۲۲ تیر
ساعت ۲۰ الی ۲۱:۳۰

📱 برای اطلاعات بیشتر، صفحه‌ی اینستاگرام آکادمی دیزاین رو دنبال کنید:

https://instagram.com/dexignacademy

⁠⁣
@Dexign فلسفه دیزاین

___

دلایل بیزنسی مهاجرت به Blazor، خوش شانسی دات‌نتی‌ها

داستانِ داشتن یک تیم نرم‌افزاری همیشه یک داستان پر فراز و نشیب برای شرکت‌های نرم‌افزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژی‌ها، پیدا کردن نیروهای خوب و متعهد، همه اینها فقط قسمتی از چالش‌هایی است که یک تیم نرم‌افزاری با آن مواجه است. یکی از مواردی که این داستان را پیچیده می‌کند، وجود تکنولوژی‌های مختلف و زبان‌های مختلف است.

تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیم‌هایی با زبان‌های هر یک از محیطهای بالا نیاز دارید:

Backend: Java, Node.js, PHP, ASP.NET (C#), Python
Frontend: Angular, React, Vue
Android: Java, Kotlin
IOS: Objective-C, Swift
Job: Java, C#
IoT: C++

اگر هر تیم قرار باشد از یک تکنولوژی با زبان متفاوت کار کند شما تقریبا به ۶ تیم نیاز دارید. همچنین اگر بخواهید تیم نسبت به رفت و آمد نیرو امن باشد باید برای هر کاری حداقل ۳ نفر در تیم‌تان داشته باشید. یک نفر با تسلط ۱۰۰٪، یک نفر با تسلط ۷۰٪ و یک نفر با تسلط ۵۰٪.

بنابراین برای داشتن یک تیم امن شما به حدوده ۱۸ نفر نیرو نیاز خواهید داشت تا بتوانید دیسیپلین‌های بالا را پوشش دهید.

شاخص «تحمل‌پذیری» یک تیم نرم‌افزاری

این شاخص نشان می‌دهد تیم شما نسبت به رفت و آمد نیرو و یا تحمل تیم در مقابل حجم زیاد کار نامتوازن لحظه‌ای چقدر است. هر چه افراد تیم به قسمت‌های مختلف کد مسلط‌تر باشند این شاخص بالاتر است.

مهاجرت به Blazor

زبان سی‌شارپ در چند سال اخیر در همه پلتفرم‌ها قابل استفاده بود به غیر از وب. خوشبختانه با ظهور Blazor که یک فریم‌ورک فوق‌العاده است برنامه‌نویسان سی‌شارپ می‌توانند سیستم‌های بسیار با کیفیت و با پرفورمنس بالایی را روی بستر WebAssembly روی بروزرها بنویسند.

بنابراین اگر تیم شما یک تیم دات‌نتی است، پیشنهاد می‌کنم برای مهاجرت و آموزش نیروهای خود را برای حرکت به سمت Cross-Platform شدن و رسیدن به Full Stack های واقعی، از همین الان برنامه‌ریزی کنید. خبر خوبتر این است که این مسیر کماکان ادامه دارد و با ظهور NET MAUI داستان قرار است بسیار جذاب‌تر و شیرین‌تر هم شود.

توضیحات و دلایل دقیق‌تر را می‌توانید در اینجا مطالعه کنید.

#مهران_داودی (لینکدین - بلاگ)


کانال تلگرام:
@SoftwarePhilosophy

________

درنگ کردن: مهمترین ابزار برای مدیران محصول

کار کردن در شرکت‌های تکنولوژیک به عنوان یک مدیر محصول، کار چالش برانگیزی است. تقریبا همه کارها اورژانسی هستند و باید خیلی سریع انجام شوند. ممکن است در میان انبوه ایمیل‌ها، چارت‌ها و اسلایدها حس کنید زمانی برای نفس کشیدن ندارید. این لحظات زمان‌هایی هستند که شما باید چند دقیقه درنگ کنید. یک قدم به عقب بردارید و چند برای دقیقه کاری را که انجام می‌دادید متوقف کنید.
در ادامه، در این مورد صحبت می‌کنیم که درنگ کردن چطور به شما برای تحویل محصول بهتر کمک می‌کند.

درنگی برای اولویت‌بندی مجدد

معمولا ذی‌نفعان می‌خواهند همه کارها همزمان انجام شود. این رویکرد باعث می‌شود همه کارها همیشه اورژانسی و در اولویت بالا باشند. اما وقتی همه چیز اولویت بالایی دارد، هیچ چیز در اولویت نیست. در این موقعیت لازم است درنگ کنید.
شما به عنوان مدیر محصول بهتر از هرکس دیگری از تاثیرات هر کار و منابع لازم برای آن آگاه هستید. پس درنگ کنید و با ذهن باز اولویت‌بندی را مشخص کنید. سپس نتیجه را شفاف و کامل، به اطلاع ذی‌نفعان برسانید.

درنگی برای هماهنگی مجدد با گروه

برای جواب دادن عجله نکنید. وقتی از سمت ذی‌نفعان سوالی از شما پرسیده می‌شود، درنگ کنید و با گروه‌های مختلفِ مشغول در پروژه هماهنگ شوید، اطلاعات را دسته بندی کنید و پس از آن جواب بدهید.

درنگی برای بررسی

به عنوان مدیر محصول شما با انبوهی از مسئولیت‌های مختلف درگیر هستید. مراقب باشید در میان این بحبوحه کاربر را از یاد نبرید. همیشه زمانی را برای درنگ کردن در کارهای جاری، و تمرکز روی کاربران اختصاص دهید. این زمان را باید به بررسی عمیق نیاز کاربران، فیدبک‌های آن‌ها، رفتار و پیشنهاداتشان سپری کنید. البته که برای پروژه رودمپ طراحی شده که شما موظف هستید بر اساس آن پیش بروید، ولی فراموش نکنید کاربر از همه چیز مهم‌تر است.


درنگی برای تجلیل کردن

دستاوردهایتان را دست کم نگیرید. در بین کارهایتان اندکی درنگ کنید و از مسیری که آمده‌اید و اهداف پروژه که به آن دست پیدا کرده‌اید لذت ببرید. با تجلیل از دستاوردهایتان، برای خودتان و تیم انرژی بیشتری برای ادامه مسیر فراهم می‌کنید.

در محیط‌های کاری پرسرعت این روزها، فشار زیادی به مدیران پروژه وارد می‌شود. احساس گیر افتادن در یک چرخه بی پایان و خسته کننده آسان است. پس فراموش نکیند که گاهی درنگ کنید و انرژی لازم برای ادامه کار را کسب کنید.

مقاله کامل را در لینک زیر مطالعه کنید:

https://bit.ly/dxgn946

(زمان حدودی مطالعه: ۴ دقیقه)

نویسنده: عاطفه صفری

#مدیر_محصول #PM

@Dexign فلسفه دیزاین

_______

ببخشید، ولی شما مدیر محصول نیستید!

بعضی از مدیرها ادعا می‌کنند مدیر محصول هستند ولی در واقع با کانسپت مدیریت محصول آشنایی ندارند. در این مقاله مواردی ذکر شده که اگر در مورد شما صدق می‌کند، نشان می‌دهد شما یک مدیر محصول نیستید.

۱. اگر اجازه می‌دهید ذی‌نفعان کسب و کار به شما دیکته کنند که فیچر چطور ساخته شود.

در مسیر پروژه‌هایتان به ذی‌نفعانی برمی‌خورید که تلاش می‌کنند شما را مجبور کنند یا حداقل پیشنهاد دهند که محصول چطور باید ساخته شود. این پیشنهادات معمولا با سوگیری همراه است و پشتوانه اطلاعاتی ندارند. به عنوان یک مدیر محصول شما باید از ذی‌نفع در مورد چرایی مشکل سوال کنید. آنقدر به پرسیدن این چرا ادامه بدهید تا مشکلی که باید حل شود، به وضوح مشخص شود.

۲. اگر راه حل را بیشتر از مشکل دوست دارید.

به عنوان یک مدیر محصول باید بتوانید مشکلات کاربر یا ذی‌نفعان را حل کنید. برای این که بتوانید راه حل درست را پیدا کنید، لازم است عمیقا مشکل را بشناسید. برای شناخت عمیق مشکل از ریسرچ، مصاحبه با کاربر، تحلیل دیتا، پیش‌بینی دیتا و ... استفاده می‌کنید. وقتی که مشکل را با جزئیات فهمیدید وقت آن است که انتخاب کنید چه راه حلی، بهترین است. به یاد داشته باشید که یک راه حل ممکن است در یک موقعیت بهترین باشد و در موقعیت دیگر نه. یکی از اساتید این حوزه می‌گوید: عاشق مشکل باشید نه راه حل!

۳. اگر از دیتا برای تصمیم گیری استفاده نمی‌کنید.

یک مدیر محصول نباید زیاد تصمیمات شهودی بگیرد. در مورد هر تصمیم، از خودتان سوال کنید چرا و در صورتی که یک پاسخ دیتامحور ندارید، به تحقیق ادامه بدهید. حتی گاهی باید در مورد دیتا پارانویید باشید!

۴. اگر نمی‌توانید حداقل یک وایرفریم لوفیدیلیتی بسازید.

درست است که در پروژه طراحانی وجود دارند که مسئولیت طراحی محصول به عهده آن‌هاست. اما بهترین کسی که محصول را می‌فهمد شما هستید و باید بتوانید یک وایرفریم حداقلی بسازید تا هرجایی که لازم شد برای بهتر منتقل کردن منظورتان از آن استفاده کنید. نرم‌افزار بالزامیک گزینه مناسبی برای تازه‌کارهاست.

۵. اگر برای تعریف معیارهای موفقیت تا بعد از لانچ محصول صبر می‌کنید.

به عنوان یک مدیر محصول باید در ابتدا تحقیقات لازم را انجام دهید و همه پارامترها را بررسی کرده و معیارهایی را تعریف کنید که نشان‌دهنده موفقیت محصول هستند. نه این‌که پیش بروید تا ببینید چه پیش می‌آید. تیم‌های دیگر مثل تیم مارکتینگ هم می‌توانند از معیارهایی که شما تعریف کرده‌اید استفاده کنند.

در ادامه این مقاله موارد دیگری آورده شده است. اگر در حال حاضر مدیر محصول هستید یا به مدیریت محصول علاقه‌مندید پیشنهاد می‌کنیم از لینک زیر مقاله را به صورت کامل مطالعه کنید:

https://bit.ly/dxgn948

(زمان حدودی مطالعه: ۴ دقیقه)

نویسنده: عاطفه صفری

#مدیر_محصول #PM

@Dexign فلسفه دیزاین

_______

📋 استفاده از Bit platform برای ساخت یک پروژه Blazor

احتمالا هنگام ایجاد یک پروژه #Blazor ای با سوال‌ها و چالش‌های متعددی روبرو شدید.

🖊 کندی سرعت لود اولیه سایت در حالت Wasm به دلیل دانلود فایل های مورد نیاز.
🖊 مشکلات سئو.
🖊 مشکلات ایجاد شده به واسطه تعداد بالای کاربر در آن واحد در حالت Blazor Server.
🖊 دردسر زیاد زمانی که تصمیم به سوییچ کردن بین حالت‌های مختلف Blazor داشته باشید.
🖊 و مشکلات احتمالی دیگر

تمام این مسائل در🔗 Bit platform مورد بررسی قرار گرفته و شما می‌توانید از پروژه Todo Template به عنوان template اولیه خود استفاده کنید.

همچنین 🔗در داکیومنت Todo template توضیحات مختصر و مفیدی مبنی بر نحوه کانفیگ پروژه ارائه شده است که در صورت استفاده از آن می‌توانید اکثر مشکلات مطرح شده را حل کنید.

🎯 در حالت کلی هم در اکثر مواقع شما نیاز به یک پروژه Blazor Webassembly ای دارید که Prerendering دارد. یعنی کانفیگ زیر:

<BlazorMode>BlazorWebAssembly</BlazorMode>
<WebAppDeploymentType>SSR</WebAppDeploymentType>


🎯 در این حالت شما یک PWA ای دارید که حالت Prerendering دارد و چالش سرعت اولیه لود سایت در همین جا حل می‌شود.

🎯 به خاطر کانفیگ‌هایی که در این Template وجود دارد و در داکیومنت به آن اشاره شده است سئو سایت در بهینه‌ترین حالت خود قرار می‌گیرد.

🎯 با یک کانفیگ بسیار ساده می‌توانید بین سه حالت BlazorServer, BlazorWebAssembly و BlazorHybrid سوئیچ کنید.

🎯 می‌توانید با یک کد خروجی Web,Android, IOS, Windows و ... داشته باشید.

💻 در نهایت اگه به نظرتون #BitPlatform ابزار مفیدی بود با ستاره دادن و Contribute در Github و اشتراک گزاری این مطلب می‌تونید از این ابزار حمایت کنید.

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

Directives in Angular

یکی از کانسپت‌های بسیار مهم در انگولار، دیرکتیوهاست.
به طور کلی دیرکتیوها کلاس‌هایی برای ایجاد رفتار جدید یا تغییر رفتارهای موجود المنت‌های DOM می‌باشند، در واقع می‌شود گفت: هر نوع دستکاری در المنت‌های DOM. برای مثال می‌شود به حذف و اضافه کردن، تغییرات ظاهری المنت‌ها اشاره کرد.

می‌توانیم دیرکتیوها را به سه نوع تقسیم کنیم:

• Component directive
کامپوننت‌ها یک دیرکیتو خاص در انگولار هستند.
یک دیرکیتو همراه با یک تمپلیت، یعنی اجزای اصلی اپلیکیشن انگولاری که کامپوننت‌ها می‌باشند. کامپوننت‌ها در واقع از مجموعه‌ای از دیرکیتوها ساخته می‌شوند (این موضوعه که انقدر اهمیتشو بالا می‌بره).

• Structural directive
همانطور که از اسمش پیداست، این دیرکتیوها ساختار DOM را تحت تاثیر قرار می‌دهند، از مهم‌ترین‌های این نوع می‌توانیم به ngIf و ngFor اشاره کنیم که به ترتیب برای حذف و اضافه کردن المنت و رندر کردن لیستی از المنت‌ها در DOM مورد استفاده قرار می‌گیرند.
این دیرکتیوها همیشه باید با پیشوند ' * ' مورد استفاده قرار گیرند
مثال:
*ngIf


• Attribute directive
این نوع دیرکتیوها به طور کلی برای تغییر ظاهر یا رفتار المنت‌ها مورد استفاده قرار می‌گیرند که از مهم‌ترین‌هایشان می‌شود به ngClass, ngStyle و ngModel اشاره کرد.

دیرکتیوهای نام برده شده همگی از پیش ساخته هستند، ولی ما می‌توانیم دیرکتیو خود را بسازیم، ساختن دیرکتیو اصول و قواعد خاصی دارد و از موارد نسبتا تخصصی برای توسعه‌دهندگان انگولار است.

توضیحات تکمیلی و نحوه ساختن انواع دیرکتیو در لینک زیر قابل دسترس است:

https://blog.bitsrc.io/directives-in-angular-6160ce805416

#حسن_یوسفی (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

💻 به روزرسانی View در Blazor توسط یک Event غیر UI ای

فرض کنید قصد پیاده سازی یک Toaster در Blazor را دارید. احتمالا به این شکل کامپوننت خود را پیاده سازی می‌کنید که برای مشاهده Toast یک Event را در یک Thread مجزا Raise می‌کنید و بعد از مثلا ۵ ثانیه یک Event دیگر Raise می‌کنید که آن Toast محو شود.
داخل Event محو کننده نیز حتما از کد زیر استفاده می‌کنید.

StateHasChanged();

اما در این حالت با خطای زیر مواجه می‌شوید:

System.InvalidOperationException: The current thread is not associated with the Dispatcher.

در پروژه‌های Blazor,WPF,WinForm, ... زمانی که کد فرانت توسط یک event غیر UI ای صدا زده شده باشد، نیاز به پیاده سازی نوعی سیستم thread locking/synchronisation هست.

این مشکل در Blazor (اکثرا) زمانی رخ می‌دهد که در آن Thread ای که توسط event غیر UI ای صدا زده شده است بخواهید StateHasChanged را صدا بزنید.

راه حل ساده در Blazor استفاده از کد زیر است.

InvokeAsync(() => StateHasChanged());

داخل بدنه InvokeAsync در این مثال StateHasChanged قرار دارد ولی شما می‌توانید هر کدی که بخواهد باعث تغییر در View شود را در نظر بگیرید.

توضیحات کامل را می‌توانید از این لینک مطالعه کنید.

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

بررسی خطای همزمانی آپدیت در EFCore

فرض کنید از جدول user یک آبجکت با آیدی x لود و track کرده‌اید. سپس فیلد name را آپدیت می‌کنید. اما هنوز SaveChange را صدا نزده‌اید.
در این بین (بعد از لود و قبل از save کردن) در یک جای دیگر از سیستم همین user آپدیت می‌شود.

می‌توانید مثالی شبیه به کد زیر را پیاده سازی کرده و نتیجه را ببینید:

var user = await Db.Users.Find(x);
user.Name = "jamez";
Db.Database.ExecuteSqlRaw("UPDATE User SET Name = 'david',age=22 WHERE Id = x");
await Db.SaveChangesAsync();

⁉️ چه اتفاقی خواهد افتاد؟

اتفاقی که خواهد افتاد صادر شدن خطای DbUpdateConcurrencyException است.

چون چیزی که track شده مقدارش steve است ولی در زمان ذخیره مقدار در دیتابیس متفاوت است.

برای درک بهتر این اتفاق و بررسی نحوه حل کردن آن می‌توانید از این لینک کمک بگیرید.

در این لینک یک قسمت TODO ای وجود دارد که شما باید تصمیم بگیرید که کدام یک از آپدیت‌ها را اعمال کنید.

 // TODO: decide which value should be written to database
 // proposedValues[property] = <value to be saved>;

در مثال لینک بالا اینگونه به نظر می‌رسد که باید یکی از آپدیت‌های دیتابیس یا #EF را اعمال کنیم.

اما در این حالت مشکلی وجود دارد. فرض کنید با EF یک user لود کرده‌اید و نام او را به "jamez" تغییر داده‌اید و در آن لحظه age برابر ۲۰ بوده (یعنی ما اصلا در اینجا کاری با age نداریم)
در این مثال قبل از این که savechange را صدا بزنید یک جابی ران شده ونام را به "david" تغییر داده و علاوه بر آن age را نیز به 22 تغییر داده است.

در لینک بالا سیاستی که پیش گرفته شده این است که یا باید name=jamez , age=20 را اعمال کنیم یا name=david, age=22.
در صورتی که به نظر منطقی‌تر این است که name=jamez و age= 22 را اعمال کنیم.

✅ برای این حالت هم می‌توانیم به جای Catch ای که در اینجا آمده از این کد استفاده کنیم:

foreach (var entry in ex.Entries)
{
    var proposedValues = entry.CurrentValues;
    var databaseValues = await entry.GetDatabaseValuesAsync(cancellationToken);


    foreach (var property in proposedValues.Properties)
    {
        var proposedValue = proposedValues[property];
        var databaseValue = databaseValues[property];
        var propEnrty = entry.Property(property.Name);
        if (propEnrty.IsModified)
        {
            proposedValues[property] = proposedValue;
        }
        else
        {
            proposedValues[property] = databaseValue;
        }
    }
    // Refresh original values to bypass next concurrency check
    entry.OriginalValues.SetValues(databaseValues);
}

___________

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

نحوه کار کردن با UTC در دیتابیس‌هایی که خارج از ایران مستقر شده‌اند

در یکی از پروژه‌هایمان پایگاه‌ داده‌ ما خارج از ایران مستقر شده است و زمانی که کوئری‌هایی را می‌نویسیم که نیاز به مقایسه تاریخ داده با تاریخ حال حاضر سیستم دارد (سیستم SQL) دچار مشکل می‌شویم.

⁉️چه مشکلی؟
فرض کنید الان ساعت ۲ بامداد روز ۵ مرداد است (با احتساب TimeZone ایران). پایگاه داده ما جایی مستقر شده است که TimeZone اش برای مثال 01:00+ است.
اگر بخواهیم داده‌های ۵ مرداد فراخوانی شود (همین دو ساعت، یعنی تا ۲ بامداد) چه اتفاقی خواهد افتاد؟

🖊 پاسخ:
اگر تاریخ SQL را در ساده‌ترین حالت مورد استفاده قرار دهیم داده‌های روز قبل فراخوانی می‌شوند.
منظور از ساده ترین حالت مثال زیر است:

select CAST( SYSDATETIMEOFFSET() AS Date )

خروجی این کوئری در مثال ما در آن ساعت‌های خاص به جای این که ۵ مرداد باشد برابر است با ۴ مرداد.

⁉️اما راه حل چیست؟
برای این مشکل شما باید مستقیما به #SQL بگویید که چه تایم‌زونی مد نظرتان است:

select SYSDATETIMEOFFSET() AT TIME ZONE 'Iran Standard Time'

برای دیدن لیست TimeZone ها نیز می‌توانید از کوئری زیر استفاده کنید:

SELECT * FROM sys.time_zone_info;

برای بررسی بیشتر موارد مربوطه می‌توانید از این دو مطلب ( یک , دو ) استفاده کنید.

___________

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

دردسرهای فعال کردن nullable reference types و راه حل جدید سی‌شارپ

📘قبل از ورژن ۱۱ سی شارپ، اگر شما nullable value type را در پروژه خود فعال می‌کردید، هنگام تعریف یک property اگر این property از نوع nullable بود، به چالشی که قرار است مطرح کنیم بر نمی‌خوردیم، اما اگر nullable نباشد، شما با warning ای مواجه می‌شوید که باید حتما مقدار اولیه را به این property بدهید.

📗چالش‌هایی در مقدار دهی این property ها وجود داشت که باعث شد مایکروسافت در C# 11 از کلمه کلیدی required رو نمایی کند.

🔗 از این لینک (https://vrgl.ir/1aVWd) می‌توانید جهت مشاهده دقیق‌تر چالش‌ها و همچنین نحوه استفاده از این ویژگی جدید استفاده کنید.


___________

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

امکان Raw String Literals، یکی از جذاب‌ترین‌های C# 11

معمولا زمانی که قصد دارید در متغییری از جنس string داده‌ای قرار دهید که فرمت خاصی دارد، مثلا داخل آن " وجود دارد یا زمانی که قصد دارید در یک sting interpolated کاراکتر کرلی براکت ({}) نیز در خروجی نمایش داده شود.

و یا زمانی که با گذاشتن @ قبل از string قصد دارید با زدن Enter، در خروجی نیز محتوایی ببینید که Enter خورده است ولی مجبورید خطوط بعدی را به اول کد بچسبانید و یا زمانی که قصد دارید یک xml یا json ایجاد کنید و آن را داخل یک string بریزید...

تقریبا باید با نوشتن کدهای بی‌ریخت آپولو هوا کنید!

مایکروسافت در ورژن ۱۱ سی‌شارپ خود امکان Raw String Literals را اضافه کرده است و به تمام این شامورتی بازی ها خاتمه داده است.

جهت مشاهده نحوه کار با این قابلیت می‌تواتید از این لینک استفاده کنید.

___________

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

#حامد_حاجیلو (لینکدین)

کانال تلگرام:
@SoftwarePhilosophy

________

رسیدن به Small Team, Big Impact با تکنولوژی‌های Cross-Platform

داستانِ داشتن یک تیم نرم‌افزاری همیشه یک داستان پر فراز و نشیب برای شرکت‌های نرم‌افزاری است. رفت و آمد نیروها، تغییر مداوم تکنولوژی‌ها، پیدا کردن نیروهای خوب و متعهد، همه اینها فقط قسمتی از چالش‌هایی است که یک تیم نرم‌افزاری با آن مواجه است. یکی از مواردی که این داستان را پیچیده می‌کند، وجود تکنولوژی‌های مختلف و زبان‌های مختلف است.

تیمی را فرض کنید که باید محصولی را بنویسد، در حالت سنتی، شما به تیم‌هایی با زبان‌های متفاوت برای هر کار نیاز دارید، مثلا:

Backend: Java
Frontend: Angular
Android: Kotlin
iOS: Swift
IoT: C++
Windows: C#

اگر هر تیم قرار باشد از یک تکنولوژی با زبان متفاوت کار کند شما تقریبا به ۶ تیم نیاز دارید. همچنین اگر بخواهید تیم نسبت به رفت و آمد نیرو امن باشد باید برای هر کاری حداقل ۳ نفر در تیم‌تان داشته باشید. یک نفر با تسلط ۱۰۰٪، یک نفر با تسلط ۷۰٪ و یک نفر با تسلط ۵۰٪.

بنابراین برای داشتن یک تیم امن شما به حدود ۱۸ نفر نیرو نیاز خواهید داشت تا بتوانید دیسیپلین‌های بالا را پوشش دهید.

شاخص «تحمل‌پذیری» یک تیم نرم‌افزاری

این شاخص نشان می‌دهد تیم شما نسبت به رفت و آمد نیرو و یا تحمل تیم در مقابل حجم زیاد کار نامتوازن لحظه‌ای چقدر است. هر چه افراد تیم به قسمت‌های مختلف کد مسلط‌تر باشند این شاخص بالاتر است.

مقاله زیر نشان می‌دهد که چطور استفاده از یک تکنولوژی Cross-Platform می‌تواند به شما کمک کند به تحمل‌پذیری بالاتری در تیم خود برسید و بتوانید این کار را حتی با تعداد برنامه‌نویس کمتر انجام دهید.
در حقیقت این مقاله برای یک مخاطب بیزنسی نوشته شده‌است تا توضیح دهد چرا از لحاظ بیزنسی استفاده از این تکنولوژی‌ها بسیار به نفع شرکت است.

توضیحات دقیق‌تر را می‌توانید در اینجا مطالعه کنید.

#مهران_داودی (لینکدین - بلاگ)

کانال تلگرام:
@SoftwarePhilosophy

_____