مترجم: Armin Bayat

هر بار که یک سازمان مهندسی را بررسی میکنم که در مرحلهای از رشد متوقف شده است، فقط به آمارهایی مثل Latency یا تعداد Connectionهای دیتابیس نگاه نمیکنم. من رفتارها و روابط داخل سازمان را هم بررسی میکنم؛ یعنی همان فرضهای پنهان و مخربی که در فرهنگ مهندسی سازمان ریشه کردهاند و روی معماری و نحوهی کار تیمها تأثیر میگذارند.

در بعضی از اکوسیستمهای فناوری در حال توسعه، بهخصوص در ایران، یک الگوی اشتباه و تقریباً متعصبانه بهشدت دیده میشود: عقده برتری بک اند.

در چنین فرهنگی، بهصورت ضمنی فرض میشود که مهندسان بک اند، مهندسان «واقعی» هستند و طبیعتاً باید در آینده به Tech Lead یا Engineering Manager تبدیل شوند. در مقابل، با مهندسان فرانتاند مثل افرادی برخورد میشود که فقط رابط کاربری میسازند؛ کسانی که طرحهای Figma را پیادهسازی میکنند و دادههای JSON را روی صفحه نمایش میدهند.

بیایید کاملاً صریح باشیم: این تفکر، سریعترین مسیر برای شکست یک سازمان مهندسی است. تا زمانی که چنین فرهنگی در شرکت شما وجود داشته باشد، نمیتوانید محصولی در سطح جهانی و با سرعت اجرای بالا بسازید. در چرخههای محدود و تکراری باقی میمانید و دائماً از خودتان میپرسید چرا Time-to-Market شما پایین است و چرا تیمهای اجراییتان بهمرور سرعتشان را از دست میدهند.

افسانه معماری: بک اند سنگین شما تنها بخش پیچیده سیستم نیست

ریشهی این حس برتری معمولاً به یک برداشت تاریخی و اشتباه از مرزهای علوم کامپیوتر برمیگردد. برخی از مهندسان سنتی بک اند تصور میکنند چون مسئول ذخیرهسازی داده، توسعهی Microserviceها، مدیریت تراکنشهای همزمان و بهینهسازی Queryها هستند، تمام پیچیدگی فنی سیستم در اختیار آنهاست.

شاید این دیدگاه در سال ۲۰۰۵ منطقی بود؛ زمانی که بیشتر وبسایتها با LAMP Stack و بهصورت Server-Side Rendering ساخته میشدند و مرورگرها فقط HTML ساده را نمایش میدادند و چند دستور ابتدایی jQuery را اجرا میکردند.

اما امروز این دیدگاه کاملاً منسوخ شده است. مهندسی فرانتاند مدرن دیگر فقط دربارهی ظاهر و استایل نیست؛ بلکه نوعی معماری سیستمهای توزیعشده است که در سمت کاربر و داخل مرورگر اجرا میشود.

مدیریت State همان مهندسی سیستم‌های توزیع‌شده است

مدیریت حجم زیادی از State در سمت کاربر و میان چندین فرایند غیرهمزمان، کار بسیار دشواری است. یک مهندس فرانتاند که یک اپلیکیشن بزرگ را با استفاده از State Machineهای پیشرفته مانند XState یا ابزارهای مدیریت State مانند Zustand، Redux Toolkit یا Recoil طراحی میکند، در اصل با همان مسائل بنیادی روبهرو است که یک مهندس بک اند هنگام مدیریت هماهنگی Cache یا تراکنشهای توزیعشده با آنها مواجه میشود.

این مهندسان باید با مسائلی مانند موارد زیر درگیر شوند:

• Race Condition میان جریانهای غیرهمزمان HTTP و WebSocket
• بهروزرسانی خوشبینانهی رابط کاربری؛ یعنی تغییر State پیش از دریافت تأیید سرور برای حفظ سرعت و تجربهی بهتر کاربر
• ذخیرهسازی اطلاعات در سمت کاربر
• مدیریت تراکنشها در ابزارهایی مانند IndexedDB
• شناسایی و رفع Memory Leak

فرایند کامپایل و رندر در سمت کاربر

به پیچیدگی روشهای مدرن Rendering فکر کنید: Next.js App Router، React Server Components یا RSC، Incremental Static Regeneration یا ISR و Edge Middleware.

یک مهندس فرانتاند حرفهای باید درک عمیقی از پروتکلهای شبکه, HTTP/3, Streaming SSR, فرایند Hydration و مراحل پردازش صفحه در مرورگر، شامل Layout، Paint و Composite داشته باشد.

بهینهسازی Critical Rendering Path برای رسیدن به Core Web Vitals مناسب، مانند LCP، INP و CLS، به تحلیل و Profiling فنی دقیقی نیاز دارد.

اگر مسئول فنی فرانتاند شما با بهینهسازی موتور V8، الگوهای تخصیص حافظه و الگوریتمهای Tree-Shaking آشنا نباشد، محصول شما برای کاربر کند خواهد بود؛ حتی اگر Microserviceهای بک اند نوشتهشده با Go یا Rust در سریعترین زمان ممکن پاسخ 200 OK برگردانند.

همانطور که Dan Abramov (یکی از سازندگان Redux و عضو سابق تیم اصلی React) بارها در طول فعالیت حرفهای خود گفته است، فرانتاند صرفاً یک لایهی ظاهری روی بک اند نیست. فرانتاند یک محیط اجرایی بسیار پیچیده است که باید روی میلیونها دستگاه با سختافزار، سرعت شبکه و موتور مرورگر متفاوت اجرا شود.

بک اند شما در یک Docker Container تمیز و کنترلشده، با CPU و RAM مشخص اجرا میشود؛ اما فرانتاند باید در شرایط کاملاً غیرقابلپیشبینی دنیای واقعی کار کند.

نقطه کور مدیریتی: چرا مدیریت کاملاً بک اند محور سرعت سازمان را از بین می‌برد؟

وقتی یک سازمان بهصورت پیشفرض فقط مهندسان بک اند را برای نقشهای Tech Lead و Engineering Manager انتخاب میکند، یک سوگیری ساختاری بزرگ ایجاد میشود.

مدیری که تفکر بک اند محور دارد، معمولاً فرانتاند را فقط مصرفکنندهی خروجیهای بک اند میبیند.

این نگاه مستقیماً باعث ایجاد گلوگاههای عملیاتی میشود؛ مشکلاتی که من بهعنوان مشاور دائماً با آنها روبهرو میشوم:

• شکست قرارداد «Black Box»: تیم بک اند بدون شناخت کافی از نیازهای سمت کاربر، API طراحی میکند. سپس پاسخهای بزرگ، یکپارچه و بهینهنشدهی JSON را در اختیار تیم فرانتاند قرار میدهد. در نتیجه، تیم فرانتاند مجبور میشود روی دستگاههای ضعیف کاربران عملیات سنگینی مانند مرتبسازی آرایهها، فیلترکردن دادهها و تغییر ساختار اطلاعات را انجام دهد.
• شکاف در پایش عملکرد: سازمان زمان پاسخگویی سرور را اندازهگیری میکند و مثلاً از Response Time ده میلیثانیهای خوشحال است؛ اما هیچ دیدی نسبت به تأخیر تعامل کاربر در سمت Client ندارد. ممکن است Interaction to Next Paint در محصول ۴۰۰ میلیثانیه باشد، اما چون فقط شاخصهای بک اند اندازهگیری میشوند، سازمان اصلاً متوجه این کندی نمیشود.
• تأخیر در اجرا: چون تیم فرانتاند جدی گرفته نمیشود، اعضای آن در جلسات اولیهی تحلیل و طراحی معماری حضور ندارند. زمانی که یک قابلیت جدید به تیم اجرایی میرسد، مهندسان فرانتاند تازه متوجه میشوند که طراحی API با مدل State سمت کاربر کاملاً ناسازگار است. نتیجه، چند هفته بازطراحی اضطراری، Refactoring و از دست رفتن Deadlineها خواهد بود.

حرکت به سمت سطح جهانی؛ تغییری فرهنگی که قابل مذاکره نیست

اگر فرهنگ شرکتهای فناوری سطح بالا را بررسی کنید؛ شرکتهایی که در رویدادهای بینالمللی مانند JSConf، React Advanced یا Next.js Conf حضور دارند، دیگر خبری از تفکیک «بک اند برتر» و «فرانتاند ضعیفتر» نیست. در این شرکتها فقط یک معیار وجود دارد: تعالی در مهندسی نرم‌افزار.

در شرکتهایی مانند Meta، Google و Stripe، بسیاری از Tech Leadها و مدیران ارشد مهندسی از مسیر فرانتاند رشد کردهاند. چرا؟ چون مهندسان فرانتاند مجبورند در کنار مدیریت محدودیتهای فنی پیچیده، درک عمیقی از نیازها و تجربهی کاربر داشته باشند. آنها دقیقاً در نقطهی تلاقی منطق کسبوکار، شاخصهای عملکرد و رفتار کاربران قرار دارند.

قرارها و الزام‌های مدیریتی

اگر میخواهید سازمان مهندسی شما رشد کند، باید این اصول غیرقابلمذاکره را از همین فردا اجرا کنید:

1. برابری واقعی در رهبری فنی: رهبران فرانتاند باید در تمام تیمهای Cross-Functional، از همان اختیار، جایگاه و قدرت تصمیمگیری رهبران بک اند برخوردار باشند.
2. بررسی مشترک RFCها: هیچ طراحی API، تغییر Schema دیتابیس یا تعیین مرز Microserviceها نباید بدون تأیید صریح مسئول فنی فرانتاند همان تیم نهایی شود.
3. حذف ادبیات تحقیرآمیز: هر رفتاری که مهندسی سمت کاربر را با عباراتی مانند «فقط HTML و CSS است» کوچک بشمارد، باید با برخورد جدی و بدون اغماض روبهرو شود. چنین حرفهایی نشانهی شناخت فنی پایین است، نه نشانهی برتری فنی.

اجازه ندهید غرور و تعصبهای محدود، جایگاه افراد در سازمان مهندسی را مشخص کند. ممکن است بک اند شما بسیار پایدار و قدرتمند باشد؛ اما اگر معماری فرانتاند به یک گلوگاه کند، مسدودکننده و بهینهنشده تبدیل شده باشد، کاربر در نهایت محصولی خراب و ضعیف را تجربه خواهد کرد. اجرای سریع و باکیفیت به یک موتور متعادل نیاز دارد؛ موتوری که هر دو سمت فرانتاند و بک اند آن به یک اندازه قدرتمند باشند. وقت آن رسیده است که بالغتر فکر کنیم، سطح استانداردهای خود را بالاتر ببریم و یک فرهنگ مهندسی واقعاً حرفهای و در سطح جهانی بسازیم.