انتخاب زبان و فریمورک برای پروژه وب معمولاً با یک پرسش فنی شروع می‌شود: «با چه چیزی بنویسیم؟» اما این پرسش در واقع پایانِ کار است، نه آغاز آن. تصمیم درست از سه چیز بیرون می‌آید: جنس مسئله، عمر سیستم و توان تیم برای نگهداری آن در سال‌های بعد. در این نوشته به‌جای فهرست کردن نام زبان‌ها و فریمورک‌ها، مسیری برای تصمیم‌گیری می‌بینید که می‌توانید در جلسهٔ بعدی روی تخته بکشید.
اول مسئله را دسته‌بندی کنید، بعد فناوری را
بیشتر بحث‌های بی‌پایان دربارهٔ زبان‌ها از آنجا شروع می‌شود که دو نفر دربارهٔ دو مسئلهٔ متفاوت حرف می‌زنند. پیش از هر چیز مشخص کنید پروژه در کدام دسته است:
- سامانه‌های ثبت و گردش کار: تیکت، مدیریت ارتباط با مشتری (CRM)، انبار و حسابداری. وزن اصلی روی مدل داده، اعتبارسنجی، سطوح دسترسی و گزارش‌گیری است. زبانی که ابزار بالغی برای کار با پایگاه داده و اعتبارسنجی دارد، اینجا برنده است.
- محصولات تعاملی و بلادرنگ (real-time): داشبوردهای زنده، گفت‌وگوی درون‌برنامه‌ای و اعلان لحظه‌ای. اینجا چرخهٔ رویداد (event loop)، وب‌سوکت (WebSocket) و مدیریت وضعیت سمت کلاینت تعیین‌کننده‌اند.
- سامانه‌های داده‌بر و هوش مصنوعی: پردازش دسته‌ای، صف کار، تحلیل داده و سرویس‌دهی مدل. نزدیکی زبان به اکوسیستم علم داده، ارزشمندتر از زیبایی نحو آن است.
اشتباه رایج این است که یک دسته را با معیار دستهٔ دیگر بسنجیم؛ مثلاً برای یک سامانهٔ ثبت داخلی، زمان پاسخ میلی‌ثانیه‌ای را معیار اصلی کنیم.
چهار پرسشی که تصمیم را قطعی می‌کند
- دو سال بعد چه کسی این کد را نگه می‌دارد؟ اگر تیم فردا بزرگ یا کوچک شود، بازار نیروی کار برای آن زبان چقدر است؟ زبانی که در شهر شما متخصص ندارد، یک ریسک عملیاتی است، نه یک انتخاب فنی.
- نقطهٔ برگشت‌ناپذیر کجاست؟ مدل داده و قرارداد رابط برنامه‌نویسی کاربردی (API) چیزهایی هستند که بعداً گران عوض می‌شوند. زبان و فریمورک را می‌شود دور یک هستهٔ درست عوض کرد؛ به شرطی که منطق دامنه به چارچوب فریمورک گره نخورده باشد.
- بار عملیاتی روی تیم چقدر است؟ هر جزء اضافه، یک سطح نگهداری اضافه می‌آورد. استقرار، پشتیبان‌گیری، پایش (monitoring) و به‌روزرسانی امنیتی بخشی از تصمیم فناوری هستند، نه کاری که بعد از آن انجام می‌شود.
- چه چیزی را حاضرید قربانی کنید؟ فریمورک‌های یکپارچه سرعت شروع و انسجام می‌آورند، اما آزادی کمتری می‌دهند. ترکیب اجزای مستقل آزادی می‌دهد، اما هر انتخاب یک تصمیم نگهداری جدید است.
سبک فریمورک مهم‌تر از نام آن است
اگر از نام‌ها فاصله بگیریم، سه سبک می‌ماند:
- فریمورک‌های یکپارچه (full-stack یا batteries-included): مسیرهای از پیش تعیین‌شده برای احراز هویت، مهاجرت پایگاه داده، صف و تست دارند. برای تیم کوچک و سامانه‌های سازمانی که باید سریع به نتیجه برسند، انتخاب کم‌هزینه‌ای است؛ سامانه‌هایی مثل سامانهٔ تیکتینگ و مدیریت پروژه بر پایهٔ لاراول نمونهٔ همین مسیرند.
- فریمورک‌های سبک و ترکیب‌پذیر (micro-framework): تصمیم را به شما برمی‌گردانند. قدرتشان در انعطاف است و هزینه‌شان در تعداد تصمیم‌هایی که خودتان باید بگیرید و مستند کنید.
- پلتفرم‌های تایپ‌شده با کامپایل (statically typed): بخشی از خطاها پیش از اجرا گرفته می‌شود. در دامنه‌های پیچیده با قواعد زیاد و تیم‌های بزرگ، این ویژگی به‌سرعت خودش را برمی‌گرداند.
هیچ‌کدام از این سه سبک «بهتر» نیستند؛ هر کدام برای شکلی از تیم و مسئله بهینه‌اند. بخشی از تصمیم هم مستقل از فریمورک است: استانداردهای وب، دسترسی‌پذیری (accessibility) و رفتار مرورگرها را باید از مرجع‌های معتبر وب یاد گرفت، نه فقط از مستندات یک فریمورک.
هزینهٔ واقعی، بعد از تحویل اول ظاهر می‌شود
سرعت رسیدن به نسخهٔ اول، بدترین معیار برای سنجش یک انتخاب فناوری است. هزینهٔ واقعی در سه جا ظاهر می‌شود: وقتی می‌خواهید قابلیت جدید اضافه کنید، وقتی باگ در محیط عملیاتی پیدا می‌شود، و وقتی نفر تازه‌وارد به تیم اضافه می‌شود. هر تصمیم فناوری در واقع یک بدهی فنی بالقوه است که سودش را در آینده می‌گیرد.
به همین دلیل، پیش از انتخاب، ارزش دارد مرز اجرای سیستم را هم روشن کنید: کجا اپلیکیشن به کانتینر و ماشین مجازی نیاز دارد و کجا یک سرویس مدیریت‌شده کافی است. این تصمیم، مستقل از زبان، به اندازهٔ خود زبان روی هزینهٔ نگهداری اثر می‌گذارد.
یک راه میانبر: نمونهٔ اولیهٔ عمودی
هیچ جدول مقایسه‌ای جای یک آزمایش کوچک واقعی را نمی‌گیرد. یک برش عمودی (vertical slice) بسازید: یک قابلیت واقعی از ورودی تا خروجی، شامل احراز هویت، یک فرم ثبت، یک گزارش و استقرار روی محیط آزمایشی. این کار در یکی دو هفته انجام می‌شود و چیزهایی به شما می‌گوید که هیچ مقاله‌ای نمی‌گوید:
- چه مقدار کد تکراری می‌نویسید و کجا کار خسته‌کننده می‌شود.
- نوشتن تست چقدر آسان است و بازخورد خودکار چقدر سریع می‌آید.
- وقتی خطا رخ می‌دهد، چقدر سریع علت را پیدا می‌کنید.
- استقرار و برگرداندن تغییر (rollback) چقدر دردناک است.
اگر تیم شما دو گزینهٔ جدی دارد، همین برش را با هر دو بسازید و کد را کنار هم بگذارید. معمولاً بعد از این مرحله، بحث به نتیجه می‌رسد.
نشانه‌های هشدار
- انتخاب بر اساس محبوبیت در شبکه‌های اجتماعی یا آخرین کنفرانسی که دیده‌اید.
- آوردن هم‌زمان چند فناوری تازه در یک پروژه؛ ریسک‌ها روی هم جمع می‌شوند.
- وابستگی کل سیستم به دانش یک نفر.
- انتخاب ابزاری که برای مسئلهٔ شما ساخته نشده و باید مدام خلاف جهت آن شنا کنید.
- تصمیم‌گیری بدون نوشتن دلیل؛ بعداً کسی یادش نمی‌آید چرا این مسیر انتخاب شد.
جمع‌بندی
انتخاب زبان و فریمورک برای پروژه وب بیشتر شبیه یک تصمیم مدیریتی است تا یک بحث فنی. مسئله را دسته‌بندی کنید، بپرسید دو سال بعد چه کسی این کد را نگه می‌دارد، مرزهای برگشت‌ناپذیر را از تصمیم‌های قابل بازبینی جدا کنید و پیش از تعهد نهایی، یک برش عمودی واقعی بسازید. تصمیم را با دلیلش مکتوب کنید تا اگر روزی برگشتید، بدانید از کجا برگشته‌اید.
