این باگ نیست، این فیچر است — مفهوم، ریشه و تفاوت‌ها

«این باگ نیست، این فیچر است» یعنی چه

«این باگ نیست، این فیچر است» — عبارتی که توسعه‌دهنده یا مدیر با آن نشان می‌دهد رفتار غیرمنتظره برنامه عمدی است نه اشتباه. در حالت کلاسیک این یک شوخی است: همه می‌فهمند رفتار اشتباه است اما برای کاهش تنش آن را «فیچر» می‌نامند. با این حال در پروژه‌های واقعی، این عبارت جدی هم استفاده می‌شود — وقتی رفتار واقعاً مطابق مشخصات است اما با انتظارات کاربر مطابقت ندارد.

تفاوت بین باگ و فیچر اغلب ذهنی است. برای توسعه‌دهنده‌ای که کد را نوشته، رفتار خاصی ممکن است منطقی به نظر برسد. برای کاربر — غیرمنتظره و اشتباه. ذهنی بودن ادراک — دلیل اصلی ماندگاری این عبارت. این عبارت گفتگو را از سطح «چه کسی مقصر است» به سطح «اینطور طراحی شده» منتقل می‌کند. طبق UX Collective، ۴۰٪ از باگ‌های گزارش‌شده توسط کاربران در واقع مشکلات UX هستند نه خطاهای کد.

در تیم‌های agile، این عبارت اغلب به عنوان مکانیزم دفاعی در دمو استفاده می‌شود. توسعه‌دهنده رفتار غیرمنتظره را نشان می‌دهد، product owner اخم می‌کند و عبارت مقدس «این باگ نیست، این فیچر است» به گوش می‌رسد. اعتماد در تیم مشخص می‌کند که آیا این عبارت به عنوان شوخی یا تلاش برای پنهان کردن مشکل تلقی می‌شود. در تیم سالم چنین شوخی جو را سبک می‌کند، در تیم سمی — باعث تعارض می‌شود.

تاریخچه پیدایش عبارت نمادین

اولین استفاده شناخته شده از این عبارت در سال ۱۹۷۶ در یکی از بولتن‌های DECUS (Digital Equipment Corporation User Society) ثبت شد. کاربر شکایت داشت که پردازشگر متن RUNOFF خطوط خالی را نادرست پردازش می‌کند. پاسخ توسعه‌دهنده: «این باگ نیست، این فیچر است — پاراگراف‌ها اینطور پردازش می‌شوند». از آن زمان، این عبارت به نماد دفاع از کد نوشته‌شده «همانطور که هست» بدون توجه به کیفیت واقعی آن تبدیل شد.

به رایج شدن این عبارت Jargon File — فرهنگ لغت عامیانه هکری که در دهه ۱۹۹۰ اساس کتاب «The New Hacker's Dictionary» را تشکیل داد — کمک کرد. در Jargon File مدخل «feature» مستقیماً به باگ‌هایی اشاره دارد که به دلیل عدم امکان یا عدم تمایل به رفع آنها به فیچر تبدیل شده‌اند. مثال: کلید Caps Lock در ترمینال‌های اولیه نشانگر نداشت — این یک باگ بود که به فیچری «برای تایپ کور» تبدیل شد.

در دهه ۲۰۰۰ این عبارت از طریق میم‌های اینترنتی به فرهنگ عامه راه یافت. تصویر گربه با زیرنویس «It's not a bug, it's a feature» در فروم‌ها و شبکه‌های اجتماعی پخش شد. در صنعت بازی، این عبارت به ویژه زیاد استفاده می‌شود: گلیچ‌هایی که در گیم‌پلی اختلال ایجاد نمی‌کنند برای فضا «فیچر» اعلام می‌شوند. پدیده فرهنگی بسیار فراتر از IT رفته است — این عبارت را می‌توان در هر زمینه‌ای که خطایی توجیه می‌شود شنید.

روانشناسی بهانه: چرا اینطور می‌گویند

پایه روانشناختی این عبارت — ناهماهنگی شناختی. توسعه‌دهنده ساعت‌ها صرف نوشتن کد کرده و اعتراف به اینکه نتیجه اشتباه است یعنی بی‌ارزش کردن کار خود. عبارت «این باگ نیست، این فیچر است» ناهماهنگی را کاهش می‌دهد: خطا به تصمیمی عمدی تبدیل می‌شود و توسعه‌دهنده از مقصر به خالق ایده تبدیل می‌شود. این مکانیزم دفاعی روان است که عزت نفس را حفظ می‌کند.

دلیل دوم — ترس از دوباره‌کاری. اگر باگ را بپذیرید، باید دوباره از کد-ریویو، تست و دیپلوی عبور کنید. «فیچر» نیاز به اصلاح ندارد — تسک بسته می‌شود، بار کاهش می‌یابد. طبق Microsoft Research، توسعه‌دهندگان در ۲۳٪ موارد عمداً شدت باگ‌ها را پایین نشان می‌دهند تا از دوباره‌کاری جلوگیری کنند. این عبارت شکل ملایم چنین پایین‌نشان‌دادنی است.

دلیل سوم — فرهنگ سازمانی. در برخی شرکت‌ها، باگ‌ها در KPI توسعه‌دهنده لحاظ می‌شوند و کشف باگ در کد-ریویو اشتباه نویسنده محسوب می‌شود. در چنین محیطی عبارت «این باگ نیست، این فیچر است» راهی برای اجتناب از عواقب منفی برای شغل است. فرهنگ سالم خطا (blameless culture) این دلیل را از بین می‌برد: اگر باگ‌ها مجازات ندارند، پذیرش آنها آسان‌تر است.

مرز بین باگ و فیچر کجاست

مرز واضح تنها با وجود Acceptance Criteria (معیارهای پذیرش) وجود دارد. اگر رفتار با هیچ یک از بندهای AC مطابقت نداشته باشد — این باگ است. اگر رفتار مطابق AC باشد اما کاربر را راضی نکند — این مشکل UX است نه باگ. اگر AC وجود نداشته باشد — هر رفتاری را می‌توان فیچر اعلام کرد و این دلیل اصلی ماندگاری این عبارت است.

قاعده عملی: باگ — وقتی برنامه کاری را انجام می‌دهد که نباید یا کاری را انجام نمی‌دهد که باید طبق مشخصات. فیچر — وقتی برنامه کاری را که طراحی شده انجام می‌دهد حتی اگر نتیجه کاربر را شگفت‌زده کند. موارد بحث‌برانگیز: undefined behavior (زبان نتیجه را تعریف نمی‌کند)، race conditions (ناپایدار ظاهر می‌شوند)، مقادیر مرزی (برای ۹۹٪ داده‌ها کار می‌کند).

برای تشخیص از ماتریس تصمیم استفاده کنید:

• رفتار در مشخصات توضیح داده شده و به درستی پیاده‌سازی شده — فیچر، حتی اگر دوست ندارید
• رفتار توضیح داده شده اما نادرست پیاده‌سازی شده — باگ، نیاز به اصلاح دارد
• رفتار توضیح داده نشده اما منطقی از نیازمندی‌ها ناشی می‌شود — فیچر مستندنشده، باید به مشخصات اضافه شود
• رفتار توضیح داده نشده و غیرمنطقی — باگ، نیاز به شفاف‌سازی نیازمندی‌ها دارد

خطرناک‌ترین حالت — زمانی که مشخصات وجود ندارد و توسعه‌دهنده خود تصمیم می‌گیرد چه چیزی فیچر است. در چنین پروژه‌هایی هر خطایی می‌تواند «فیچر» اعلام شود که کد را برای کل تیم غیرقابل پیش‌بینی می‌کند. Acceptance Criteria واضح برای هر تسک — تنها راه ترسیم عینی مرز است.

خطر جابجایی مفاهیم در تیم

خطر اول — محو شدن کیفیت. اگر هر باگی قابل اعلام به عنوان فیچر باشد، تیم انگیزه‌ای برای نوشتن کد با کیفیت ندارد. خطاها رفع نمی‌شوند، بدهی فنی افزایش می‌یابد و کاربران به «رفتار عجیب» عادت می‌کنند. دیر یا زود رقیب محصولی قابل پیش‌بینی عرضه می‌کند و کاربران می‌روند.

خطر دوم — تعارض در تیم. مهندس QA باگی پیدا می‌کند، توسعه‌دهنده می‌گوید «این فیچر است». اگر معیارهای عینی (Acceptance Criteria) وجود نداشته باشد، اختلاف به سطح شخصی کشیده می‌شود: «تو بد تست می‌کنی» vs «تو بد برنامه‌نویسی می‌کنی». طبق PractiTest State of Testing 2023، اختلافات «باگ vs فیچر» یکی از سه علت اصلی اصطکاک بین QA و توسعه‌دهندگان است.

خطر سوم — ریسک‌های قانونی. در صنایع تنظیم‌شده (پزشکی، مالی، هوانوردی) مفاهیم «باگ» و «فیچر» وزن قانونی دارند. اگر در نرم‌افزار پزشکی رفتاری فیچر اعلام شود اما منجر به محاسبه نادرست دوز شود — این شوخی نیست، نقض الزامات نظارتی است. سیستم‌های safety-critical جابجایی مفاهیم را نمی‌بخشند بنابراین در آنها همیشه formal verification اعمال می‌شود.

چگونه از سردرگمی بین باگ و فیچر جلوگیری کنیم

ابزار اصلی — Acceptance Criteria (AC) واضح در هر تسک. AC قبل از شروع توسعه نوشته می‌شود: «پس از ورود X، سیستم باید Y را برگرداند». اگر رفتار توضیح داده نشده باشد — این به طور پیش‌فرض باگ است حتی اگر توسعه‌دهنده طور دیگری فکر کند. AC باید قابل اندازه‌گیری و قابل بررسی باشند: «دکمه سبز» — بد، «HEX #00FF00» — خوب.

ابزار دوم — Definition of Done در تیم. توضیح واضح از اینکه «تسک انجام شده» یعنی چه: کد نوشته شده، تست‌ها نوشته شده، تست‌ها پاس شده، کد-ریویو انجام شده، در استیجینگ دیپلوی شده، توسط QA تست شده. اگر همه بندهای DoD انجام شده اما کاربر شکایت دارد — این باگ نیست بلکه missed requirement که به عنوان فیچر جدید به بکلاگ می‌رود.

ابزار سوم — فرهنگ blameless post-mortem. اگر باگی فیچر اعلام شده و به پروداکشن رفته — به دنبال مقصر نمی‌گردیم بلکه علل را بررسی می‌کنیم. چرا توسعه‌دهنده تصمیم گرفت این فیچر است؟ چرا QA عبور داد؟ چرا AC ناقص بودند؟ پاسخ به این سؤالات فرآیند را بهبود می‌بخشد نه اینکه مردم را تنبیه کند. بهبودهای سیستمی مؤثرتر از ممنوعیت عبارت «این باگ نیست، این فیچر است» عمل می‌کنند.