سوال مصاحبه‌ای که نحوه تفکر من درباره طراحی سیستم را تغییر داد 📝💡

<Milan Jovanović>

حدود شش یا هفت سال پیش، در یک مصاحبه برای یک موقعیت سطح میانی NET. شرکت کردم.

💡یکی از سوال‌ها از آن زمان تا الان با من مانده است:

یک کاربر روی یک دکمه در UI کلیک می‌کند تا یک گزارش Excel یا PDF تولید شود. تولید گزارش حدود پنج دقیقه طول می‌کشد (زمان می‌تواند دلخواه باشد). کاربر باید منتظر بماند تا فرایند کامل شود. شما چگونه این جریان را بهینه می‌کنید؟

در آن زمان، تمرکز من روی چیزی بود که بیشترین تسلط را داشتم: performance ⏱️. شروع به فکر کردن درباره بهینه‌سازی تولید گزارش کردم. شاید بتوانم SQL queries را بهینه کنم، تبدیل داده‌ها را کاهش دهم یا بخش‌هایی از نتیجه را cache کنم. اگر می‌توانستم فرایند را از پنج دقیقه به یک دقیقه برسانم، احساس موفقیت بزرگی می‌کردم.

اما حتی اگر پنج برابر سریع‌تر هم می‌شد، کاربر همچنان مجبور بود منتظر بماند. اگر browser کرش می‌کرد، همه چیز از دست می‌رفت. اگر شبکه قطع می‌شد، فرایند متوقف می‌شد. اگر تب را می‌بستند، تمام پیشرفت از بین می‌رفت.
در واقع این یک مشکل performance نبود، بلکه یک مشکل design بود. 🛠

چیزی که آن زمان از دست دادم ⚠️

با نگاه به گذشته، متوجه می‌شوم که ذهنم درگیر این بود که "کد را سریع‌تر کنم". نه که اشکالی داشته باشد، بهینه‌سازی عملکرد یک مهارت ارزشمند است. آنچه که آن موقع به وضوح نمی‌دیدم، مشکل بزرگ‌تر بود. برنامه همه این کارها را synchronously انجام می‌داد و کاربر را تا پایان فرایند در حالت انتظار نگه می‌داشت. نهایتاً با چند راهنمایی از مصاحبه‌کننده متوجه شدم.

سوال بهتر این نبود که "چگونه می‌توانم سریع‌تر کنم؟"

سوال واقعی این بود که: "چرا کاربر در وهله اول منتظر است؟" 🤔

اگر چیزی دقایق (یا حتی ساعت‌ها و روزها) طول می‌کشد، نباید کاربر را بلاک کند. این کار باید در background و خارج از جریان اصلی درخواست انجام شود، در حالی که کاربر به کارهای خود ادامه می‌دهد.

نکته مهم 🔑

باز هم فراموش نکنید که کد را بهینه کنید. Database queries، پردازش داده‌ها و تولید فایل همگی اهمیت دارند. شاید indexی جا افتاده باشد، حلقه‌ای ناکارآمد باشد یا کتابخانه بهتری برای ایجاد Excel وجود داشته باشد. اما این بهینه‌سازی‌ها فقط بخشی از راه‌حل هستند، نه کل آن.