Това не е бъг, това е фийчър — същност, произход и разлики

Какво означава „Това не е бъг, това е фийчър”

„Това не е бъг, това е фийчър” — фраза, с която разработчикът или мениджърът обозначава, че неочакваното поведение на програмата е преднамерено, а не грешно. В класическия случай това е шега: всички разбират, че поведението е грешно, но го наричат „фийчър” за облекчаване на напрежението. В реални проекти обаче фразата се използва и сериозно — когато поведението действително съответства на спецификацията, но не съответства на очакванията на потребителя.

Разликата между бъг и фийчър често е субективна. За разработчика, написал кода, определено поведение може да изглежда логично. За потребителя — неочаквано и грешно. Субективността на възприятието — основната причина фразата да е толкова жизнена. Тя позволява преместване на разговора от равнината „кой е виновен” в равнината „така е замислено”. Според UX Collective, 40% от бъговете, докладвани от потребители, всъщност са UX проблеми, а не грешки в кода.

В agile екипите фразата често се използва като защитен механизъм по време на демо. Разработчикът показва неочаквано поведение, product owner се мръщи и се чува сакраменталното „това не е бъг, това е фийчър”. Доверието в екипа определя дали фразата ще бъде приета като шега или като опит за прикриване на проблем. В здрав екип такава шега разведрява атмосферата, в токсичен — предизвиква конфликт.

История на възникване на култовата фраза

Първата известна употреба на фразата е записана през 1976 г. в един от бюлетините на DECUS (Digital Equipment Corporation User Society). Потребител се оплаква, че текстовият процесор RUNOFF обработва неправилно празните редове. Отговорът на разработчика: „Това не е бъг, това е фийчър — така се обработват параграфите”. Оттогава фразата става символ на защита на кода, написан „какъвто е”, независимо от реалното му качество.

Популяризирането на фразата се дължи на Jargon File — речник на хакерския сленг, който през 90-те години на XX век формира основата на книгата „The New Hacker's Dictionary”. В Jargon File статията „feature” директно се отнася до бъгове, които са станали фийчъри поради невъзможност или нежелание да бъдат поправени. Пример: клавишът Caps Lock в ранните терминали нямаше индикация — това беше бъг, който стана фийчър „за сляпо писане”.

През 2000-те години фразата преминава в масовата култура чрез интернет мемета. Снимка на котка с надпис „It's not a bug, it's a feature” се разпространява из форуми и социални мрежи. В игровата индустрия фразата се използва особено често: гличовете, които не пречат на геймплея, се обявяват за „фийчъри” за атмосфера. Културният феномен е излязъл далеч извън ИТ — фразата може да се чуе във всеки контекст, в който се оправдава грешка.

Психология на оправданието: защо го казват

Психологическата основа на фразата е когнитивният дисонанс. Разработчикът е прекарал часове в писане на код и признаването, че резултатът е грешен, означава обезценяване на собствената работа. Фразата „това не е бъг, това е фийчър” намалява дисонанса: грешката се превръща в преднамерено решение, а разработчикът — от виновник в автор на идеята. Това е защитен механизъм на психиката, който запазва самочувствието.

Втората причина — страх от преработка. Ако бъгът бъде признат, трябва да се премине отново през code review, тестване и deploy. „Фийчърът” не изисква корекция — задачата се затваря, натоварването намалява. Според Microsoft Research, разработчиците съзнателно занижават сериозността на бъгове, за да избегнат преработка, в 23% от случаите. Фразата е мека форма на такова занижаване.

Третата причина — корпоративна култура. В някои компании бъговете се отчитат в KPI на разработчика, а откриването на бъг при code review се счита за грешка на автора. В такава среда фразата „това не е бъг, това е фийчър” е начин да се избегнат негативните последици за кариерата. Здравата култура на грешки (blameless culture) елиминира тази причина: ако бъговете не се наказват, по-лесно се признават.

Къде минава границата между бъг и фийчър

Ясна граница съществува само при наличие на Acceptance Criteria (критерии за приемане). Ако поведението не съответства на нито една точка от AC — това е бъг. Ако поведението съответства на AC, но не харесва на потребителя — това е UX проблем, а не бъг. Ако AC няма — всяко поведение може да бъде обявено за фийчър и това е основната причина за жизнеността на фразата.

Практическо правило: бъг — когато програмата прави това, което не трябва, или не прави това, което трябва, според спецификацията. Фийчър — когато програмата прави това, което е замислено, дори ако резултатът изненадва потребителя. Спорни случаи: undefined behavior (езикът не определя резултата), race conditions (проявяват се нестабилно), екстремни стойности (работи за 99% от данните).

За разграничаване използвайте матрица за вземане на решения:

• Поведението е описано в спецификацията и имплементирано коректно — фийчър, дори и да не ви харесва
• Поведението е описано, но имплементирано некоректно — бъг, изисква корекция
• Поведението не е описано, но логично произтича от изискванията — недокументиран фийчър, трябва да се добави към спецификацията
• Поведението не е описано и е нелогично — бъг, изисква уточняване на изискванията

Най-опасният случай — когато спецификацията липсва и разработчикът сам решава какво е фийчър. В такива проекти всяка грешка може да бъде обявена за „фийчър”, което прави кода непредсказуем за целия екип. Ясни 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 в екипа. Ясно описание на това какво означава „задачата е изпълнена”: кодът е написан, тестовете са написани, тестовете минават, code review е преминат, деплойнат е на стейджинг, тестван е от QA. Ако всички точки от DoD са изпълнени, но потребителят се оплаква — това не е бъг, а missed requirement, който отива в беклога като нов фийчър.

Третият инструмент — култура на blameless post-mortem. Ако бъг е бил обявен за фийчър и е отишъл в продукция — анализираме причините, не търсим виновен. Защо разработчикът реши, че това е фийчър? Защо QA го пропусна? Защо AC бяха непълни? Отговорите на тези въпроси подобряват процеса, не наказват хората. Системните подобрения работят по-ефективно от забрана на фразата „това не е бъг, това е фийчър”.