بحث «انتخاب زبان و فریمورک» برای پروژه وب معمولاً خیلی زود به یک منازعه‌ی سلیقه‌ای تبدیل می‌شود: هر کسی زبانی را که با آن راحت‌تر است پیشنهاد می‌دهد و گفتگو با جمله‌ی «فلانی هم با همین ساخته» بسته می‌شود. اما در عمل این تصمیم بیشتر مهندسی و اقتصادی است تا احساسی: چه کسی دو سال بعد این کد را نگه می‌دارد، هزینه‌ی تغییر چقدر است، و اکوسیستم چه بخشی از کار را از پیش حل کرده است. در ادامه یک چارچوب تصمیم‌گیری عملی می‌بینید که به‌جای مقایسه‌ی انتزاعی زبان‌ها، از خود مسئله شروع می‌کند.
از مسئله شروع کنید، نه از زبان
پیش از هر مقایسه‌ای، سه پرسش را پاسخ دهید. پاسخ این سه، بیشتر گزینه‌ها را حذف می‌کند:
- چه کسی می‌سازد و چه کسی نگه می‌دارد؟ اگر تیم کوچک است و بعد از تحویل هم باید خودش پشتیبانی کند، فناوری‌ای را انتخاب کنید که در همان تیم، عمق دانش دارد؛ نه فناوری‌ای که فقط یک نفر با آن آشناست.
- الگوی استفاده چیست؟ سامانه‌ای با چند صد کاربر داخلی و ترافیک پیش‌بینی‌پذیر، نیازهای متفاوتی از یک سرویس عمومی با اوج‌های ناگهانی دارد. اولی به خوانایی و سرعت توسعه نیاز دارد، دومی به مقیاس‌پذیری و پروفایلینگ.
- چه چیزهایی باید از پیش حل‌شده باشند؟ پرداخت، احراز هویت، کنترل دسترسی، گزارش‌گیری و صف کارهای پس‌زمینه؛ هر کدام که برای شما «مسئله‌ی اصلی» نیست، بهتر است در اکوسیستم候选人 آماده داشته باشد.
چهار معیار که واقعاً تفاوت می‌سازند
وقتی از سطح سلیقه عبور می‌کنیم، چهار معیار تکرارشونده باقی می‌ماند که در طول عمر پروژه هزینه‌ی واقعی می‌سازند:
- بلوغ اکوسیستم (ecosystem maturity): پرسش درست این نیست که «چند پکیج وجود دارد»، بلکه این است که «آیا پکیج‌های کلیدی نگهداری می‌شوند و مستندات دارند؟» اکوسیستمی که برای هر نیاز ده گزینه‌ی نیمه‌کاره دارد، وقت تیم را بیشتر از یک اکوسیستم کوچک اما منظم می‌بلعد.
- بازار نیروی انسانی (hiring pool): زبان محبوب در گفتگوهای آنلاین با زبانِ در دسترس در بازار کار محلی یکی نیست. اگر پروژه‌ی شما بعداً به تیم دوم یا برون‌سپاری نیاز پیدا می‌کند، این معیار وزن جدی می‌گیرد.
- ابزارهای عملیاتی و رصدپذیری (observability): دیباگر، پروفایلر، پشتیبانی از ردگیری (tracing) و ساختار لاگ، بخشی از انتخاب زبان است نه افزونه‌ی بعد از انتشار. تیمی که برای عیب‌یابی یک خطا باید ساعت‌ها حدس بزند، هزینه‌ی پنهانی می‌پردازد.
- مسیر ارتقا و نگهداری (upgrade path): پرسش را این‌طور بپرسید: «ارتقای نسخه‌ی اصلی فریمورک، چه اندازه از کد ما را دستخوش تغییر می‌کند؟» چارچوب‌هایی که تغییرات را پله‌پله و با اعلام قبلی می‌آورند، قابل پیش‌بینی‌ترند.
سه الگوی پروژه و انتظارشان از فناوری
تجربه‌ی پروژه‌های نرم‌افزاری نشان می‌دهد بیشتر پروژه‌های وب فارسی در یکی از این سه الگو جای می‌گیرند و هر الگو، اولویت متفاوتی دارد:
سامانه‌های سازمانی و داخلی
فرم‌های زیاد، سطوح دسترسی پیچیده، گردش کار و گزارش. اینجا سرعت توسعه‌ی قاعدت‌مند و ساختار پیش‌فرض فریمورک، تعیین‌کننده است؛ چارچوبی که «مسیر درست» را سخت‌گیرانه تحمیل کند، بهتر از چارچوبی است که همه‌چیز را آزاد بگذارد. همین منطق در نمونه‌ای مثل سامانه‌های تیکتینگ و مدیریت پروژه دیده می‌شود که در آن، مدل داده و مجوزها قلب پروژه‌اند، نه جلوه‌های بصری.
فروشگاه اینترنتی و پرداخت
اینجا صحت تراکنش، اتصال به درگاه و درستی محاسبات، اولویت اول است. کتابخانه‌ی پرداخت بالغ، ابزار تست قوی و امکان بازپخش (replay) رویدادها را جدی بگیرید. اگر چارچوب انتخابی، تست یکپارچه‌ی مسیر پرداخت را برایتان دشوار کند، هزینه‌ی این انتخاب را ماه‌ها بعد می‌پردازید.
محصول چندمستاجری (multi-tenant)
وقتی یک نسخه از نرم‌افزار باید به چند مشتری سرویس بدهد، جداسازی داده، صف کارهای سنگین و کنترل دسترسی به سطح «مستاجر (tenant)» می‌رسد. اینجا بیشتر از زبان، باید به بلوغ ابزارهای صف، زمان‌بندی و جداسازی داده نگاه کنید.
چهار خطای رایج در انتخاب
- مقایسه‌ی زبان با فریمورک: پرسش «پایتون یا لاراول؟» مقایسه‌ی نادرستی است؛ یکی زبان است و دیگری چارچوب. تصمیم را در دو سطح جدا بگیرید.
- انتخاب بر پایه‌ی محبوبیت: محبوبیت، تقاضای بازار و آسانی شروع را می‌سنجد، نه تناسب با مسئله‌ی شما.
- نادیده گرفتن هزینه‌ی ترک (switching cost): هر انتخاب یک قفل‌شدگی کوچک ایجاد می‌کند. حداقل بپرسید اگر شش ماه بعد نظرتان عوض شد، چه چیزی از دست می‌رود.
- تصمیم برای رزومه، نه برای پروژه: اگر تنها دلیل انتخاب یک فناوری «یاد گرفتنش» است، بهتر است آن را در پروژه‌ای جانبی امتحان کنید، نه در سامانه‌ای که مشتری دارد.
نکته‌ای که معمولاً گم می‌شود این است که کیفیت نهایی کد بیشتر به انضباط تیم بستگی دارد تا به زبان؛ اصولی مثل اصول SOLID در کد واقعی در هر اکوسیستمی قابل اجرا هستند و نبودشان در هیچ زبانی جبران نمی‌شود.
یک روند تصمیم‌گیری در پنج گام
- محدودیت‌ها را بنویسید: اندازه‌ی تیم، مهارت موجود، بودجه‌ی نگهداری، الزامات امنیتی و نیازهای یکپارچه‌سازی را در یک صفحه فهرست کنید.
- مسیرهای پرخطر را جدا کنید: دو یا سه بخش پروژه که شکست در آن‌ها گران است (مثلاً پرداخت یا احراز هویت) را مشخص کنید و فقط برای همان‌ها نمونه‌ی اولیه (prototype) کوچک بسازید؛ نه برای کل سامانه.
- هزینه‌ی نگهداری را برآورد کنید: تصور کنید سامانه سه سال در حال بهره‌برداری است؛ هزینه‌ی رفع باگ، افزودن قابلیت و ارتقای نسخه در هر گزینه چقدر است؟ اینجا صحبت از مدیریت بدهی فنی به میان می‌آید: انتخاب‌هایی که امروز سریع‌ترند، ممکن است فردا گران‌تر شوند.
- مستندات و استانداردها را ببینید: کیفیت مستندات رسمی و پایداری استانداردهای وب، شاخص خوبی برای پیش‌بینی آینده‌ی آن اکوسیستم است.
- تصمیم را ثبت و بازبینی کنید: انتخاب، دلایل و گزینه‌های ردشده را در یک سند کوتاه تصمیم معماری بنویسید تا بعداً «چرا این‌طور شد» به حافظه‌ی افراد وابسته نباشد.
جمع‌بندی
انتخاب زبان و فریمورک برای پروژه وب، پاسخ واحدی ندارد؛ چیزی که دارد، یک تصمیم قابل دفاع است: تصمیمی که از محدودیت‌های واقعی پروژه شروع شود، چهار معیار اکوسیستم، بازار کار، ابزار عملیاتی و مسیر ارتقا را وزن بدهد و هزینه‌ی نگهداری را جدی بگیرد. اگر این کار را درست انجام دهید، احتمالاً هیچ‌وقت «بهترین زبان دنیا» را انتخاب نمی‌کنید؛ اما بهترین زبان برای پروژه‌ی خودتان را انتخاب می‌کنید و دلیلش را هم می‌توانید توضیح دهید.
