Это не баг, это фича — суть, происхождение и отличия

Что значит «Это не баг, это фича»

«Это не баг, это фича» — фраза, которой разработчик или менеджер обозначает, что неожиданное поведение программы является намеренным, а не ошибочным. В классическом случае это шутка: все понимают, что поведение ошибочно, но называют его «фичей» для снятия напряжения. Однако в реальных проектах фраза используется и всерьёз — когда поведение действительно соответствует спецификации, но не соответствует ожиданиям пользователя.

Разница между багом и фичей часто субъективна. Для разработчика, который написал код, определённое поведение может казаться логичным. Для пользователя — неожиданным и ошибочным. Субъективность восприятия — главная причина, почему фраза так живуча. Она позволяет перевести разговор из плоскости «кто виноват» в плоскость «так задумано». По данным UX Collective, 40% багов, reported пользователями, на самом деле являются проблемами 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, разработчики сознательно занижают severity багов, чтобы избежать переработок, в 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 были неполными? Ответы на эти вопросы улучшают процесс, а не наказывают людей. Системные улучшения работают эффективнее, чем запрет на фразу «это не баг, это фича».