Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Это довольно частое выражение , и услышать его можно в диалоге «заказчик-разработчик» или «разработчик-разработчик». Связано оно с тем, что разрабатываемая программа работает не так , как изначально запланировано. Обо всем по порядку, а пока давайте разбираться, когда используется выражение : « Э то не баг, а это фича». А для этого давайте выясним различия между словами «баг» и «фича» , и тогда все станет понятно .
Что так ое «баг» в программировании?
- баги находят при тестировании или уже в процессе запуска или даже жизни программы;
- в основном они возникают случайно из-за ошибки и невнимательности программистов;
- баги нужно исправлять, чтобы программа работала так , как надо.
Что такое « фича » в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.
Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Когда употребляется выражение : « Э то не баг, а это фича» ?
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.
У заказчика есть некий образ программы, того, как она должна работать. Поэтому любое отклонение от этого «образа» в глазах заказчика будет багом. Но в то же время программист в процессе своей работы может заметить варианты того , как улучшить функциональность программы. Времени на объяснение и согласование с заказчиком нет, поэтому программист внедряет такое небольшое улучшение самостоятельно.
Естественно, что при тестировании продукта такое «улучшение» будет замечено заказчиком и для него оно будет багом. Вот тут как раз и время парировать разработчику, что это не баг, а фича , и объяснять , почему это так.
Для себя можно обобщить, что , если в программе есть ошибка, которая нарушает ее функциональность , — это баг. А если эта же самая «ошибка» не нарушает функциональности программы, а наоборот, улучшает или придает ей некую «изюминку», то это , скорее всего , фича.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Фича
Фича — это сленг, название тех или иных признаков предмета, либо явления. Другими словами, это его особенности, необычные свойства.
Слово пришло к нам от английского «feature» — особенность.
Что такое фича? Фича в IT это может быть необычное программное решение, возможности, особая функциональность, уникальные характеристики, которые привлекают внимание.
Чаще всего термин употребляется в сленге, но сегодня он уже перекочевал в обычную жизнь. Фичами называют необычные функции бытовой техники, уникальный дизайн, не стандартную функциональность. Часто слово фича в сфере, не связанной с IT заменяют на созвучную «фишка». От фичи образовалось словосочетание fetch request, хорошо известное программистам, а также появилось крылатое выражение-неологизм: «Это не баг, а фича».
Сегодня фичей называют любую характеристику продукта, которая имеет специфические особенности. Это могут быть механизмы, которые добавляют новую функциональность, элементы, превращающие продукт в уникальный. Это слово наиболее распространено в игровой индустрии, в сфере программного обеспечения, создания сайтов.
Свяжите сервисы между собой без программистов за 5 минут!
В роли фичи могут выступать различные фильтры, нестандартные слайдеры, уникальная визуализация, кардинально новое оформление интерфейса, необычная экипировка и поведение персонажей, схема диалогов, сюжетные ходы.
Фича — эффективный инструмент в позиционировании продукта, который играет важную роль в формировании уникального торгового предложения: она формирует механизм возвращения, потому что делает товар или услугу привлекательной для пользователей. Благодаря этому повышается монетизация проекта, формируется его положительный имидж, презентабельность в глазах целевой аудитории.
Баг или фича?
Баг происходит от английского «bug» и означает ошибку в программе или приложении. В результате бага вы получаете нежелательный результат. Крылатая фраза «это не баг, а фича» часто используется разработчиками для оправдания совершенных ошибок.
Как отличить баг от фичи? Если у вас что-то не работает или работает не корректно, то это точно баг. А если работает, но не совсем так как ожидалось, то возможно это фича 🙂 Понять это можно при тестировании продукта.
Настроить интеграцию без программистов ApiX-Drive
Статьи о маркетинге, автоматизации и интеграциях в нашем Блоге
Чем отличается бага от фичи?
Во-первых не бага, а баг, а во-вторых баг — это вылет игры, а фича (feature) так сказать «необычные программные возможности, особые функции, что-либо, что привлекает особое внимание» к программе, чаще к компьютерной игре. Например, в GTA фичей можно назвать свободу игрового мира.
автор вопроса выбрал этот ответ лучшим
комментировать
в избранное ссылка отблагодарить
Эл Лепсо ид [140K]
4 года назад
Оба этих слова, как и положено в современном мире, особенно связанном с программированием и вообще информатикой, пришли во все языки из английского и оба являются жаргонными словами, использующимися программистами.
Баг (английское — «bug») обозначает допущенную программистами ошибку при написании программы, которая может быть выявлена либо при отладке программы, либо уже при ее использовании.
Фича (английское — «feature») на языке программистов чаще всего означает некую возможность, заложенную программистами в код программы, но официально нигде не регламентируемую, т.е. некий сюрприз.
Так что основное отличие: если баг — это недосмотр, то фича — специально предусмотренная возможность.
комментировать
в избранное ссылка отблагодарить
Ismai ler [9.1K]
5 лет назад
Подобные вопросы стали всё чаще возникать из-за популярной среди программистов ныне фразы «Не баг, а фича». Суть данной фразы заключается в том, что баг — случайно допущенная ошибка, мешающая нормально пользоваться программой, а фича — специально сделанная функция, необычная для других программ такого типа.
комментировать
в избранное ссылка отблагодарить
РыССС и [299K]
2 года назад
Если бы не было багов, то не пользовалась бы в современном мире огромной популярностью такая профессия как тестировщик. В обязанности тестировщика и входит как раз поиск багов в новом продукте перед выходом его на рынок пользования. Для поиска багов — дается так называемый бета-период. он обычно длится ок.2х месяцев — в этот период любой пользователь может получить ООочень приличные деньги за нахождение в запущенном продукте програмной ошибки — бага — от английского словечка — bug-жук, жучок. По одной из версий выражение пошло от телеграфистов, которым насекомые замыкали электрооборудование. Ну а фича feature- совсем противоположный термин — это своего рода бонус, встроенный в игру для дополнения возможностей игрока.
Есть такое выражение
которое обозначает, что неисправленный баг — является фичей, то есть неисправленная ошибка может являться возможностью. Например, в доте один из персонажей при простом прыжке и определенном сочетании клавиш, меняет время с приумножением возможностей. Это незапланированные свойства, возникающие из-за ошибки в программе.
Баг или фича? Вот в чём вопрос!
В интернете много статей про приоритизацию (Priority) и серьезность (Severity) багов, но совершенно нет примеров. А что такое баг-то? А когда это запрос на новую фичу (”фича-реквест”, “улучшение”)? Практически у всех новичков возникает вопрос “а как вообще определить что баг, а что фича на живом проекте?”
Баги бывают разные — визуальные (некрасиво!), баги дизайна (неудобно!), функциональные (не работает!), баги в логике (работает неправильно!), баги безопасности (палим что не надо кому не следует!) и т.п. и все они могут попасть в разные градации серьезности.
Приоритеты меняются от проекта к проекту и даже в рамках самих проектов. Если нет чётких критериев что фича, а что ошибка, стоит обращать внимание на признаки косвенные и руководствоваться здравым смыслом.
Например, некрасивая опечатка или картинка котика вместо логотипа компании на странице-визитке (созданной для привлечения новых клиентов) сильно бьёт по имиджу компании. У потенциального покупателя возникнут вопросы: стоит ли нести свои деньги ребятам, которые не переживают за свой веб-сайт? А будут ли они “париться” о проблемах клиентов, если нет времени/желания проверить на опечатки свой собственный продающий сайт и залатать дырки от инъекций? В то же время, опечатка во внутренней админке проекта (куда доступ ограничен авторизацией или открыт только для “белого” списка IP адресов) совсем некритична, даже если это “Здратуйте” на главной странице.
Я искренне считаю, что если баг найден — он должен быть зафиксирован. Будут ли его чинить или посчитают исправление нецелесообразным (например, неоправданно дорогим для проекта)— решать ответственным за проект, но если проблема обнаружена, то она должна быть описана.
Зачем отличать баги от фич?
Часто про баги рапортуют одной команде, а запросы отправляют в другую. Или баги исправляют в текущем спринте, а фича-реквесты отправляют в бэклог в светлое будущее. И если определение типа запроса сделано неверно, он может в̶ы̶з̶в̶а̶т̶ь̶ ̶п̶р̶и̶г̶о̶р̶а̶н̶и̶е̶ ̶с̶т̶у̶л̶ь̶е̶в̶ потеряться или остаться без должного внимания. Давайте посмотрим на реальные примеры.
Это баг, если:
– работало, но вдруг перестало;
– работает, но неправильно;
– реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;
– нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);
– опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);
– после сохранения информация не появляется на странице, даже если в консоли 200 ОК;
– не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;
– при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;
– по переходу по прямой ссылке на услугу не проверяется какой пользователь сейчас авторизован и таким образом можно посмотреть чужие профили или детали услуг, если подобран валидный id;
– можно cURL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине (не проворачивайте такие сценарии не на своих рабочих проектах);
– информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);
– страница очень долго открывается, ну о-о-очень долго — секунд 30 на стабильном интернете (взбешённый клиент гарантирован);
– система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принёс проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);
– неудобно пользоваться. Например, чтобы посмотреть детали услуги клиента, нужно зайти на три вкладки вглубь аккаунта, а смотреть нужно 2–3 раза в день. Или неудобно копировать информацию со страницы, а по рабочим вопросам это нужно делать несколько раз в день — это баг интерфейса и он должен быть исправлен.
Это фича-реквест, если:
– нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;
– фичу сделали, но после использования видно, что есть простор для существенных улучшений. Например, по услуге не хватает мониторинга или статистических данных по использованию, а за перерасход может взиматься дополнительная плата — клиент точно будет несчастлив в неведении;
– знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;
– пользователь регулярно делает рутинные монотонные действия, которые можно автоматизировать. Например, копировать однотипную информацию с 12 страниц пагинации, когда простая выгрузка бы решила проблему;
– изобретаете велосипед из действующих фич продукта, чтобы добиться желаемого результата;
– на странице не хватает какой-то информации или возможности её добавить;
– на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;
– пользователь ведёт дополнительную отчетность в блокноте/экселе, когда проблему можно решить выводом ID на странице и несколькими фильтрами.
Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.
Поговорите с Главным По Проекту, узнайте кто ваш пользователь, спросите про критичные для пользователя и бизнеса фичи, запишите что будет “шоу-стоппером” для релиза (кроме очевидных “ничего-не-работает-памагити”), скорректируйте свои проверки в соответствии с этими знаниями и не бойтесь предлагать улучшения.