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