مهران داودی
مهران داودی
خواندن ۴ دقیقه·۲ سال پیش

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

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

تیمی را فرض کنید که باید محصولی را بنویسد که شامل محصولاتی «وب بک‌اند»، «وب فرانت‌اند»، «اپ اندرویدی»، «اپ آی‌او‌اس» و «جاب‌های سیستمی» و شاید کمی کارهای «IoT» است. در حالت معمولی یا شاید بگوییم سنتی، شما به تیم‌هایی با زبان‌های هر یک از محیطهای بالا نیاز دارید.

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

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

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

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

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

بنابراین این شاخص میانگین تسلط همه افراد روی همه قسمت‌های کد است و هر چقدر بالاتر باشد تیم تحمل‌پذیری بالاتری دارد.

مقایسه دو مدل تیم‌سازی

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

ساختار یک تیم با زبان‌های مختلف و تحمل‌پذیری ۲۴٪
ساختار یک تیم با زبان‌های مختلف و تحمل‌پذیری ۲۴٪

در این تیم سه برنامه نویس بک‌اند، سه برنامه‌نویس فرانت‌اند و سه برنامه‌نویس اندروید ترتیب مهارتی ۱۰۰٪ و ۷۰٪ و ۵۰٪ وجود دارند. در این تیم به وضوح Developer1 که در تیم Backend است نمی‌تواند به تیم‌های دیگر کمک کند زیرا زبان برنامه‌نویسی کاملا متفاوتی دارند. همچنین با اینکه این تیم ۹ نفر دارد. ولی برای هر محیط فقط سه نفر برنامه‌نویس دارد و عملا تسلط یک برنامه‌نویس روی محیط‌های دیگر صفر است. اگر از تمام اعداد این جدول میانگین بگیرین متوجه می‌شوید که شاخص «تحمل‌پذیری» این تیم ۲۴٪ باشد.

همانطور که ممکن است به فکر شما هم رسیده باشد:

چقدر خوب می‌شد اگر امکان این وجود داشت تا چندتا از اینها را با یک زبان نوشت تا نیاز به تیم‌های جداگانه نباشد.

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

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

ساختار یک تیم با زبان‌های یکسان و تحمل‌پذیری ۴۳٪
ساختار یک تیم با زبان‌های یکسان و تحمل‌پذیری ۴۳٪

در این ساختار تیمی شما تیمی با ۷ برنامه‌نویس‌ و تحمل‌پذیری ۴۳٪ دارید (این عدد از گرفتن میانگین همه اعداد جدول بدست آمده). در این تیم برنامه‌نویس Developer1 که تسلط ۱۰۰٪ روی بک‌اند دارد، روی پروژه‌های اندروید و وب هم می‌تواند در مواقع لازم کمک کند. بنابراین تیم شما نسبت به رفت و آمد نیرو تحمل بسیار بالاتری دارد. و همچنین تیم بسیار راحت‌تر می‌تواند تغییر پلتفرم برای محصولات مختلف بدهد.

در این مدل با بودجه کمتر، تیم کوچکتر و تحمل‌پذیری بسیار بالاتر رسیده‌اید. و این از لحاظ بیزنسی برای شرکت‌ها بسیار جذاب است.

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

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

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

البته ناگفته نماند که در استک تکنولوژی‌های دیگر هم در حال ساخت امکانات Full Cross-Platform هستند که در حال حاضر می‌توان به استک‌های JavaScript اشاره کرد.

ریسک‌ها‍

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

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


زبان برنامه‌نویسیتیمblazorسی‌اس اینترنشیپcs internship
رویاپرداز، مدیرعامل ملک‌رادار
شاید از این پست‌ها خوشتان بیاید