پرفورمنس اپ: مسئولیت محصول یا مهندسی؟
فرانتاندخلاصهٔ کاملتر
این مقاله ادامهی بحث قبلی نویسندهست دربارهی تجربه توسعهدهنده بهعنوان یه ویژگی فنی. اما اینجا روی طرف دیگه تمرکز میکنه: پرفورمنس اپلیکیشن واقعاً مهمه و تجربه خوب توسعهدهنده، نرمافزار کند رو قابل قبول نمیکنه. نکته اصلی اینه که این دو تا دشمن هم نیستن — باید به هر دو اهمیت داد.
نویسنده تأکید میکنه که پرفورمنس یه تصمیم محصولیه، نه فقط یه مسئله فنی. «سریع باشه» یا «blazing fast» یه شعاره، نه یه نیازمندی. یه نیازمندی واقعی اینه که مثلاً «فیلتر کردن یه جدول بزرگ باید ظرف X ثانیه نتیجه بده» یا «فرم ذخیرهسازی نباید در حین اعتبارسنجی، رابط کاربری رو فریز کنه». بدون این مشخصبودن، بحثهای پرفورمنس به سلیقه و حدسوگمان تبدیل میشن.
یه نکته مهم اینه که مهندسها نباید بیسروصدا نیازمندیهای عملکردی رو از هوا اختراع کنن. این وظیفهی تیم محصوله که تعیین کنه کدوم مسیر کاربری چقدر باید سریع باشه. مهندسها باید هزینهی پیادهسازی، ریسک و عواقب تصمیمها رو شفاف کنن — اما تصمیم نهایی با محصوله.
نویسنده یه تمایز مهم هم مطرح میکنه: بهینهسازی زودهنگام (premature optimization) با طراحی آگاه از پرفورمنس (performance-aware design) فرق داره. اولی یعنی بهینه کنیم قبل از اینکه بدونیم واقعاً لازمه. دومی یعنی از انتخابهایی که پرفورمنس ضروری رو در آینده غیرممکن میکنن، پرهیز کنیم. کدبیسی که قابل تغییره، معمولاً میتونه بعداً سریعتر بشه؛ کدبیس درهموبرهم رو حتی نمیشه بهینه کرد چون کسی نمیدونه هزینه واقعی از کجا میاد.
بودجه پرفورمنس (performance budget) باید یه توافق مشترک بین محصول و مهندسی باشه. فرمول پیشنهادی اینه: محصول مسیر کاربری مهم رو تعریف میکنه، مهندسی معیارهای اندازهگیری رو مشخص میکنه، هر دو روی آستانه قابل قبول توافق میکنن و مهندسی trade-offها رو توضیح میده تا محصول تصمیم بگیره ارزشش رو داره یا نه.
نکات کلیدی:
- پرفورمنس اپ یه تصمیم محصولیه، نه فقط فنی
- «سریع باشه» نیازمندی نیست؛ باید عددی و قابل اندازهگیری باشه
- مهندسها نباید نیازمندیهای عملکردی رو از خودشون اختراع کنن
- طراحی آگاه از پرفورمنس با بهینهسازی زودهنگام فرق داره
- کد بهینهای که قابل تغییر نیست، هزینه رو جابهجا میکنه نه حذف
- بودجه پرفورمنس باید توافق مشترک محصول و مهندسی باشه
