Це не баг, це фіча — суть, походження та відмінності

Що означає «Це не баг, це фіча»

«Це не баг, це фіча» — фраза, якою розробник або менеджер позначає, що несподівана поведінка програми є навмисною, а не помилковою. У класичному випадку це жарт: усі розуміють, що поведінка помилкова, але називають її «фічею» для зняття напруги. Однак у реальних проектах фраза використовується й серйозно — коли поведінка дійсно відповідає специфікації, але не відповідає очікуванням користувача.

Різниця між багом і фічею часто суб'єктивна. Для розробника, який написав код, певна поведінка може здаватися логічною. Для користувача — несподіваною та помилковою. Суб'єктивність сприйняття — головна причина, чому фраза так живуча. Вона дозволяє перевести розмову з площини «хто винен» у площину «так задумано». За даними UX Collective, 40% багів, повідомлених користувачами, насправді є проблемами UX, а не помилками коду.

В agile-командах фраза часто використовується як захисний механізм під час демо. Розробник показує несподівану поведінку, product owner хмуриться, і лунає сакраментальне «це не баг, це фіча». Довіра в команді визначає, чи буде фраза сприйнята як жарт або як спроба приховати проблему. У здоровій команді такий жарт розряджає обстановку, у токсичній — викликає конфлікт.

Історія виникнення культової фрази

Перше відоме використання фрази зафіксоване в 1976 році в одному з бюлетенів DECUS (Digital Equipment Corporation User Society). Користувач скаржився, що текстовий процесор RUNOFF неправильно обробляє порожні рядки. Відповідь розробника: «Це не баг, це фіча — так обробляються параграфи». Відтоді фраза стала символом захисту коду, написаного «як є», незалежно від його реальної якості.

Популяризації фрази сприяв Jargon File — словник хакерського сленгу, який у 1990-х роках ліг в основу книги «The New Hacker's Dictionary». У Jargon File стаття «feature» безпосередньо посилається на баги, які стали фічами через неможливість або небажання їх виправляти. Приклад: клавіша Caps Lock у ранніх терміналах не мала індикації — це був баг, який став фічею «для сліпого друку».

У 2000-х фраза перекочувала в масову культуру через інтернет-меми. Картинка з котом, підписана «It's not a bug, it's a feature», розійшлася форумами та соцмережами. В ігровій індустрії фраза використовується особливо часто: глітчі, які не заважають геймплею, оголошуються «фічами» для атмосфери. Культурний феномен вийшов далеко за межі IT — фразу можна почути в будь-якому контексті, де виправдовують помилку.

Психологія виправдання: чому так говорять

Психологічна основа фрази — когнітивний дисонанс. Розробник витратив години на написання коду, і визнати, що результат помилковий — означає знецінити свою роботу. Фраза «це не баг, це фіча» знижує дисонанс: помилка перетворюється на навмисне рішення, а розробник — із винуватця на автора задумки. Це захисний механізм психіки, який зберігає самооцінку.

Друга причина — страх перед переробкою. Якщо визнати баг, доведеться заново проходити код-рев'ю, тестування та деплой. «Фіча» не потребує виправлення — задача закривається, навантаження знижується. За даними Microsoft Research, розробники свідомо занижують серйозність багів, щоб уникнути переробок, у 23% випадків. Фраза — м'яка форма такого заниження.

Третя причина — корпоративна культура. У деяких компаніях баги враховуються в KPI розробника, а виявлення бага на код-рев'ю вважається помилкою автора. У такому середовищі фраза «це не баг, це фіча» — спосіб уникнути негативних наслідків для кар'єри. Здорова культура помилок (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 та розробниками.

Третя небезпека — юридичні ризики. У regulated-індустріях (медицина, фінанси, авіація) поняття «баг» і «фіча» має юридичну вагу. Якщо в медичному ПЗ поведінка оголошена фічею, а вона призводить до неправильного розрахунку дозування — це не жарт, а порушення регуляторних вимог. Safety-critical системи не прощають підміни понять, тому в них завжди formal verification.

Як запобігти плутанині між багом і фічею

Головний інструмент — чіткі Acceptance Criteria у кожній задачі. AC пишуться до початку розробки: «При введенні X система має видати Y». Якщо поведінка не описана — це баг за замовчуванням, навіть якщо розробник вважає інакше. AC мають бути вимірюваними та перевірюваними: «кнопка зелена» — погано, «HEX #00FF00» — добре.

Другий інструмент — Definition of Done у команді. Чіткий опис того, що означає «задача зроблена»: код написаний, тести написані, тести проходять, код-рев'ю пройдено, задеплоєно на стейджинг, протестовано QA. Якщо всі пункти DoD виконані, а користувач скаржиться — це не баг, а missed requirement, який іде в беклог як нова фіча.

Третій інструмент — культура blameless post-mortem. Якщо баг був оголошений фічею і пішов у продакшен — розбираємо причини, а не шукаємо винуватого. Чому розробник вирішив, що це фіча? Чому QA пропустив? Чому AC були неповними? Відповіді на ці питання покращують процес, а не карають людей. Системні покращення працюють ефективніше, ніж заборона на фразу «це не баг, це фіча».