چطوری استک تکنولوژی نرم افزار رو انتخاب کنیم؟

توی تجربیات سال‌های کاریم بارها بوده که موقعیت هایی پیش اومده که می‌خواستیم یک معماری، ابزار یا حتی کتابخانه برای پروژه ای انتخاب کنیم. توی این موقعیت ها باید به چه نکاتی توجه کرد؟ چه چیزهایی به تصمیم ما باید جهت بده؟ آیا صرف این‌که یک تکنولوژی رو می‌شناسیم دلیل کافی برای استفاده ازش توی همه پروژه ها هست؟ یا این که علاقه داریم به تجربه کردن یه تکنولوژی جدید دلیل بدیه برای تغییر و خروج از محدوده راحتی؟توی این مقاله می‌خوام در مورد تجربه های خودم تو این زمینه صحبت کنم و بعضی عقایدی که بر اساس سال های فعالیتم چه به عنوان عضو تیم و چه به عنوان رهبر یا مدیر تیم بدست آوردم و الان برای انتخاب بهشون رجوع می‌کنم رو معرفی کنم.طبیعتا با توجه به پیشینه کاری خودم بیشتر مثال ها تو حوزه وب و موبایل خواهد بود.ترتیب موارد لزوما بر اساس اهمیت اون ها نیست و توی شرایط مختلف از دید من اهمیت هر کدوم ممکنه کمتر یا بیشتر بشه.کلمه تکنولوژی توی این مقاله خیلی تکرار شده و منظور از اون هر چیز تکنیکالیه که توی اجرای پروژه نرم افزاری میتونه تاثیر داشته باشه. مثل:‌ زبان برنامه نویسی،سرور، فریمورک، دیتابیس، سیستم Cache و … .زمانیکی از مهم ترین فاکتور ها در مورد تصمیم گیری تکنولوژی مربوط به زمان تصمیم گیریه. زمان تصمیم گیری از دو جهت اهمیت داره، اول از نظر بازه زمانی که پروژه در اون باید اجرا بشه و دوم از این نظر که در چه مقطعی از طول عمر نرم افزار هستیم.اگر در اولین مرحله از تحلیل و طراحی باشیم هزینه تغییر تکنولوژی انتخابی قابل مقایسه با زمانی که پیاده سازی شروع شده و زمانی که نسخه های پروداکشن تولید شده اصلا قابل مقایسه نیست. هر چی از طول عمر نرم افزار بیشتر گذشته باشه باید برای تغییر بیشتر احتیاط کرد.درباره نقش بازه زمانی اجرا هم که موضوع نیازی به توضیح اضافه نداره و مشخصه وقتی بازه خیلی کوتاهی برای اجرای یک محصول داشته باشیم انتخاب ها محدود تر هستند و مطمئن ترین و امتحان پس داده ترین گزینه ها انتخاب می‌شن.ماهیت (حوزه فعالیت)بعضی وقت ها و یک سری حوزه ها هستند که استاندارد ها و فرهنگ خاص خودشون رو دارن. به طور مثال وقتی در مورد نرم افزار های Enterprise صحبت می‌کنیم، نرم افزار هایی مثل CRM یا نرم افزار های مالی، فرهنگ و عادت قالب این حوزه ها به زبان های نرم افزاری و فریمورک های خاصی نزدیک تره. توی بعضی حوزه ها مثل مالی و بانکی خیلی مهمه که تکنولوژی های انتخاب شده دسترسی شما به افراد متخصص اون حوزه رو محدود نکنه. به طور مثال اگر برای یک پروژه با ماهیت مالی زبان JavaScript رو بررسی می کنید، حتما ببینید که آیا توی جامعه برنامه نویس های اون حوزه این زبان به رسمیت شناخته می‌شه یا افراد شاخص و با تجربه اون حوزه تجربه کارکردن با این تکنولوژی رو دارند یا نه و اگر جواب منفیه حتما این نکته رو توی انتخاب در نظر داشته باشین. ما نمی‌خوایم تکنولوژی ای رو انتخاب کنیم که با پیشرفت و رشد لزوما مجبور به تغییرش باشیم. همچنین ماهیت بعضی حوزه ها به طور مشخصی نیازمندی هایی بوجود میاره که به طور خودکار انتخاب یک سری ابزار ها رو اجباری می‌کنه. به طور مثال تصور کنید که توی نرم افزار بانکی امکان استفاده از Transaction های دیتابیسی رو با انتخاب دیتابیسی که از اون پشتیبانی نمی‌کنه از خودتون بگیرید! ماهیت نرم افزار و جامعه برنامه نویس های اون حوزه اهمیت زیادی توی انتخاب های تکنولوژی باید داشته باشند.علاقه و تسلطتسلط داشتن اعضای تیم به تکنولوژی های انتخاب شده نقش کلیدی توی موفقیت یا عدم موفقیت پروژه داره. هر تکنولوژی یا معماری که انتخاب می‌کنید حتما اطمینان داشته باشید که دانش کافی در مورد اون ها در بین اعضای تیم وجود داره و در صورتی که ضعفی توی این زمینه می‌بینین جزو بالاترین اولویت ها باید رفع کردن ضعف دانش باشه. تسلط کم و سطحی هرچند شاید ۸۰ درصد مواقع باعث مشکل شدیدی نشه اما توی مواقع بحرانی و مشکلات داشتن تسلط عمیق به تکنولوژی مورد استفاده اون چیزیه که شما رو زنده نگه می‌داره.یه ایده ای که توی این زمینه داشتم و استفاده کردم این بوده که وقتی برای آینده تیم تکنولوژی، زبان یا فریمورک خاصی رو مناسب می‌بینیم، می‌تونیم توی پروژه های کم ریسک تر اون ها رو تست کنیم و کل اعضای تیم به مرور با اون ها آشنا بشن تا توی موقعیت های حساس تر هم بتونیم اون تکنولوژی ها رو جزو انتخاب هامون قرار بدیم. احتمالا تو آینده در مورد معماری میکروسرویس مقاله ای می‌نویسم و این مورد رو اونجا بیشتر توضیح می‌دم.اما در مورد علاقه، واقعیت اینه که برنامه نویسی شغل سنگین و خسته کننده ایه، به خصوص که خیلی از آدم های جامعه ما عادت به کار بیشتر از ظرفیت دارن و به شدت در خطر Burnout شدن هستند. حالا اگه توی این شرایط کاری پر فشار، از تکنولوژی های منسوخ شده یا رو به منسوخ شدن هم استفاده کنیم که اعضای تیم از اون ها متنفرن به مرور به شکل واضحی کیفیت کاری تیم و بعد کیفیت نرم افزار افت می‌کنه.تجربه کسب کردننقطه مقابل تسلط داشتن، تکنولوژی هایی هستند که به شدت ترند می‌شن و علاقه شدیدی توی برنامه نویس ها وجود داره که اون ها رو تجربه کنند و اکثر مواقع هم همین امروز دوست داریم که شروع کنیم و اگر نکنیم حس می‌کنیم عقب موندیم.این موضوع به نظر من حقیقت داره و شرکت ها و تیم ها باید به سمت استفاده از تکنولوژی های روز حرکت کنند اما مرز هایی وجود داره توی این موضوع و طبق تجربه من جزو بخش هاییه که کمترین توجه بهش می‌شه.ما به عنوان برنامه نویس ها یا معمار های نرم افزار نباید فراموش کنیم که توی کارهای رسمی و سازمانی هدف نهایی ایجاد ارزش برای محصوله و صرف علاقه و عجله ما برای استفاده از یه تکنولوژی بروز تر لزوما ارزشی برای محصول و سازمان تولید نمی‌کنه.بسیاری مواقع من با این موضوع مواجه شدم که فرد جدیدی به عنوان مدیر تکنولوژی یا معمار وارد سازمانی می‌شه و یا به دلیل علایق شخصی ، یا به دلیل علاقه اعضای تیم برنامه ریزی فوری برای تغییر کامل تکنولوژی و بازنویسی با زبان یا فریم ورک مورد نظر رو شروع می‌کنه و این بازنویسی رو علاج تمام مشکلات موجود ارائه می‌ده. تجربه من نشون داده که توی درصد بالایی از موارد (و البته که نه همیشه) این تغییر و بازنویسی ها منجر به تولید نرم افزاری جدید تر، نه چندان بهتر از نسخه قبلی می‌شه که البته با رفع خیلی از مشکلات قبلی، مسئله‌های جدیدی برای سازمان ایجاد می‌کنه. نکته ای که نباید فراموش کنیم اینه که نرم افزار بی اشکال و ایده آل وجود نداره و هر اندازه هم که همه ی نکات قبلی رورعایت کنیم همیشه مسائل جدیدی که راه حلش رو از قبل نمی‌دونیم سر راهمون قرار می‌گیرند.برای جمع بندی این بخش می‌گم که به نظر من تغییر به سمت تکنولوژی های بروز تر یک امتیاز برای هر تیمی محسوب می‌شه اما این کار نیازمند رعایت کردن نکاتیه که باید بهش توجه کنیم:تجربه کسب کردن برابر با تحمیل ریسک به محصول و سازمانه و بین این ریسک و دستاورد های سازمان باید تعادل برقرار باشه. عادلانه نیست که ما تکنولوژی که برای سازمان ارزشی تولید نمی‌کنه رو با صرف کردن زمان و بودجه سازمان تجربه کنیم.توی نقطه مقابل، مقاومت بیش از حد سازمان در برابر تغییر و بهبود تکنولوژی در مواردی که دلایل کافی برای اون ها وجود داره نشونه خوبی نیست و باید حتما ریشه یابی و حل کرد این مشکل رو.اگر بخوام کل این پاراگراف رو در یک کلمه خلاصه کنم اون کلمه تعادل ‌هست.تیمآخرین موضوعی که راجع بهش صحبت می‌کنم توی این بحث، تیم نرم افزار هست. نکته هایی که در مورد تیم وجود داره توی بخش های قبلی هم راجع به بعضی هاش صحبت کردم اما به نظرم لازمه که جداگانه و دقیق بهش بپردازم.در نهایت مجری هر محصولی تیم نرم افزار اون هست و یکی از مهم ترین فاکتور های انتخاب تکنولوژی در نظر گرفتن تیم هست.آیا تیم تشکیل شده یا در حال تشکیل هست؟ بعد از تشکیل شدن تیم که به هرحال با نگاه به تکنولوژی‌های مورد استفاده انجام می‌شه تغییر دادن تکنولوژی سخت تر از قبل اونه و بهتره که نسبت معقولی از تجربه در باره تکنولوژی های پایه ای مورد استفاده داخل تیم وجود داشته باشه.برای استفاده از بعضی روش ها یا معماری ها نیاز به تیم های با ظرفیت و تجربه های مشخص هست و باید این موضوع در نظر گرفته بشه. به طور مثال زمانی که با یک تیم کوچک در حال تولید یک نرم افزار با حداکثر سرعت برای یک استارتاپ هستیم، استفاده از معماری میکروسرویس یکی از غلط ترین انتخاب های ممکن هست که زیاد هم انجام می‌شه!‌ (بیشتر مواقع به دلیل موضوع پاراگراف قبلی)توی تصمیم گیری برای تغییر تکنولوژی یا وارد کردن یه تکنولوژی جدید، باید اطمینان پیدا کنیم که یا تجربه کافی بین اعضای تیم وجود داره، یا ظرفیت کافی برای یادگیری از سمت تیم و سازمان وجود داره.من تلاش کردم به طور خلاصه به مهم ترین موضوع های ذهنیم در این باره اشاره کنم اما حتما موارد خیلی بیشتری توی این موضوع وجود داره اما پیشتهاد نهاییم اینه که موقع انتخاب تکنولوژی:حتما برای خودتون یک ساختار تصمیم گیری مشخص داشته باشین و از تصمیم گیری های احساسی دوری کنین.یادتون باشه که موقعی که برای یک سازمان کار می‌کنین، باید منافع سازمان رو در تغییرات و انتخاب ها در نظر بگیرین.یادتون نره که شما تنهایی کار رو اجرا نمی‌کنید و تمام اعضای تیم تون از این انتخاب ها تاثیر می‌گیرن.تعصب به تکنولوژی های خاص و تنفر از بقیه تکنولوژی ها فقط جلوی پیشرفت و تعالی خودتون رو می‌گیرهاگر مسئولیت نرم افزار تولید شده ای رو به عهده گرفتید در مرحله اول تغییرات رو در پایین ترین میزان حفظ کنین و کوبیدن و از نو ساختن رو هیچ وقت به عنوان اولین گزینه در نظر نگیرید.در نهایت خوشحال میشم اگر نکته هایی در این زمینه دارید مطرح کنید.