چند وقت پیش یک دوستی اومد بهم یه پیام داد و پرسید که همه کارایی که با ری-اکت میشه انجام داد رو میشه با JS معمولی هم انجام داد، پس چه لزومی داره از ری-اکت استفاده کنیم؟
احتمالا شما اگر چند سال کار کرده باشید، هم خود سوال براتون مسخره به نظر میرسه هم جوابش به نظر واضحه. ولی گمان می کنم خالی از لطف نیست یکبار به طور کامل به این دست سوالا پاسخ بدیم. من از نگاه خودم موضوع رو بررسی میکنم و جواب میدم ولی خیلی دوست دارم شما هم اگر نگاه متفاوتی دارید حتما توی نظرات بهش اشاره کنید.
ببینید توی برنامه نویسی به طور کل میتونیم مهارت هامون رو به ۲ دسته کلی میکرو و ماکرو تقسیم کنیم.
دسته ماکرو مهارت های پایه ای برای ما هستند که به ما کمک میکنن بهتر بتونیم یاد بگیریم یا مباحث رو بتونیم تعمیم بدیم به زبون های دیگه، فارغ از زبان و تکنولوژی. به عنوان مثال مهارت های حل مساله، Data Structure، الگوریتم، معماری و چیز هایی از این قبیل که به تکنولوژی ربطی ندارند.
مباحث میکرو، مستقیما ارتباط پیدا میکنن به تکنولوژی ها و فریمورک ها و زبون ها. پس بنابراین اینجاست که سینتکس و مسائل شبیه بهش مهم میشه. مثل Laravel و React و Rails و Django و ...
نکته مهم اینه که درسته که این دسته بندی وجود داره ولی در واقع هر دو این مباحث مکمل همدیگه هستند. توجه کنید که البته هر چقدر شما توی ماکرو قوی تر باشید یا مهارت بیشتر داشته باشید، انتقال مفاهیم از یک زبون به زبون دیگه یا یک فریمورک به یک فریمورک دیگه براتون کار ساده تری میشه. صرفا نحوه پیاده سازی هاتون متفاوت میشه.
خب اینجا دوباره به اون سوال اول اشاره میکنم: چرا باید ری-اکت یاد بگیرم وقتی میتونم خودم با JS معمولی همون کار ها رو انجام بدم؟
سوالات دیگه مشابه:
و در جواب این سوال باید بگم شما لازم نیست چرخ رو از اول اختراع کنید. این جواب کلی به سوالاتی که اشاره کردم هست ولی برای اینکه خیلی عمیق جواب سوال رو بررسی کنیم در پایین به چند نکته خیلی مهم اشاره میکنم.
دلیل اول: تیم
شما باید با توجه به تیمی که دارید، از تکنولوژی ای بهره ببرید که میدونید باقی اعضای با اون اوکی هستند. حالا ممکنه بگید شاید من تنها کار میکنم، در ادامه بیشتر این مورد رو توضیح میدم. ولی به طور کلی وقتی میگم تیم یعنی شما بهتره انتخاب تکنولوژی ها و ابزار هاتون متناسب باشه با تیمی که دارید، مثل این میمونه شما ۱۰ نفر بسکتبالیست باشید و بخوای برید مسابقه والیبال، میتونید؟ قطعا! بازدهی چطوره؟ خوب نیست.
دلیل دوم: Maintainablity
استفاده از تکنولوژی های شناخته شده نگهداری از اپلیکیشن رو براتون ساده تر میکنه. چون مفاهیم اون تکنولوژی یا فریم ورک شناخته شده هست (توسط کامیونیتی) و طوری طراحی شده که نگهداری رو در اولیت قرار داده.
دلیل سوم: Onboarding
اگر شما از یک فریمورک پر استفاده و محبوب استفاده کنید، قطعا افراد جدید راحت تر میتونن بیزنس لاجیک شما رو متوجه بشن چون توی فهمیدن سینتکس و اجزای سیستم مشکلی ندارند. بنابراین وقت و انرژی شون به جای اینکه صرف فهمیدن سینتکس به سمتی میره که سریع تر میتونن عضو تاثیر گذار تیم باشند.
دلیل چهارم: زمان
اگه شما یه اپلیکیشنی رو به هر نحوی تونستید پیاده سازی کنید قطعا زمان زیادی رو صرف مسائلی کردید که از قبل توسط خیلی افراد دیگه حل شده بوده و عملا شما اون زمان رو از دست دادید! خب چرا باید اینکارو بکنید؟
دلیل پنجم: هزینه
تا اینجا که در مورد تیم و زمان و Onboarding و ... صحبت کردیم، واضحه که همه اینها روی هزینه توسعه اپلیکیشن تاثیر گذاره. کاری که ممکن بود توی یک هفته انجام بشه، الان با ۲ ماه داره انجام میشه. هزینه یک هفته کجا و ۸ هفته کجا.
دلیل ششم: ریسورس
مثالم برای جاواسکریپته، ولی از عمد این مثال رو میزنم چون احساس میکنم مثال بهتری وجود نداره. فرض کنید شما یک تیم ۸ نفره از توسعه دهنده های جاواسکریپت دارید که هر کدوم توی یک فیلد خاص مهارت دارند. تنوع افراد و مهارت ها به این شکله: Node, Front-end (React), Mobile (React Native). پس همه جاواسکریپت دوولوپر هستند ولی تو زمینه های مختلف. با توجه به دانش کافی همه این افراد در مباحث ماکرو، سوییچ کردن این افراد بین تکنولوژی های مختلف کار راحتی هست. بنابراین میشه گفت استفاده کاملا بهینه ای داره میشه از ریسورس.
علاوه بر این، در فرایند جذب و استخدام هم افرادی که به یک تکنولوژی تسلط و مهارت داشته باشند و به طور کل بتونن کار رو جلو ببرن خیلی ساده تر هست.
دلیل هفتم: کامیونیتی
تکنولوژی هایی مثل React و Laravel و Django به طور وسیع توسط شرکت های مختلفی توی سر تا سر دنیا دارن مورد استفاده قرار میگیرن. قطعا خیلی مسائلی که شما ممکنه درگیرش شده باشید قبلا توسط افراد دیگه ای حل شده باشه. این راه حل ها میتونن در قالب یک جواب کوتاه توی Stackoverflow باشند یا حتی کتابخونه های open-source که میتونن سرعت انجام کار های شما رو خیلی بالاتر ببرند.
از طرفی شما مطمئن هستید که چیزی که دارید استفاده میکنید کاملا تست شده و اگر باگی یا مشکلی هم داشته باشه با سرعت خیلی بالایی توسط افراد دیگه حل میشه. تازه از نظر پرفورمنس هم خیلی خیلی بهتر از کاری هست که خودمون بخوایم انجام بدیم.
خب چی از این بهتر؟ چرا چرخ رو خودمون اختراح کنیم وقتی قبلا اینکارو برامون کردن؟
دلیل هشتم: تجربه توسعه (DX)
یه اپلیکیشن پیچیده رو در نظر بگیریم، خییلی بخش های مختلفی میتونه داشته باشه که هر کدوم یک دنیا چالش دارند (اگر بخوایم همه اش رو با Vanilla JS) انجام بدیم. بنابراین روش هایی که اون چالش ها رو برطرف می کنیم علاوه بر اینکه خیلی Reliable نیستند، در زمان توسعه هم پدرمونو در میارن. خب چرا سری که درد نمیکنه رو دستمال ببندیم؟ تجربه توسعه یا Development Experience رو نباید قربانی این موضوع بکنیم.
دلیل نهم: پروداکت
اگه پروداکتی که داریم شامل چند پروژه مختلف میشه، و همه این پروژه ها با React نوشته شده باشن، طبیعی هست که توسعه دهنده ها خیلی راحت میتونن بین این پروژه ها سوییچ کنن و Context شون رو عوض کنن بدون اینکه Effort و زمان اضافه ای بخوان صرف کنن. بنابراین میشه گفت حتی برای استارت پروژه های جدید، پروژه های قبلی هم توی تصمیم گیری در مورد تکنولوژی هاش تاثیر مستقیم دارند.
این مطلب قرار نبود خیلی طولانی بشه، و فقط دوست داشتم این موضوع رو توضیح بدم. اگر شما هم نظری دارید که فکر میکنید من اشاره نکردم یا اشتباه گفتم حتما توی کامنت ها بهش اشاره کنید. دمتون گرم و مثل همیشه میدونید که میتونید از طریق لینکدین باهام در تماس باشید.
موفق باشید.
