Баг или фича что это значит

Не баг, а фича. Что это значит и откуда появилась эта фраза?

Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.

«Не баг, а фича!»

Что так ое «баг» в программировании?

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

Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединя ю т следующие свойства:

Что такое « фича » в программировании?

Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.

Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.

Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.

Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

«Не баг, а фича» — учимся понимать язык программистов

Понять смысл IT-терминов можно, только узнав, как они употребляются

Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.

Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).

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

Новая задача

Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.

Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).

Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).

Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.

Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.

Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.

Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).

На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.

Валидация — проверка данных, которые вводит пользователь.

До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:

— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.

— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?

— Надо проверить в гитхабе историю коммитов.

Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.

Репозиторий — хранилище исходных файлов проекта.

Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.

Говнокод — очень плохой код.

Код ревью — проверка кода.

Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.

Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.

У стола его уже ждал тимлид:

— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.

— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.

— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.

— Но у меня уже есть задача на эту неделю, я не успею всё исправить.

— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.

Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.

Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.

Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.

Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.

Исправление багов

Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.

Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.

Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.

— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.

— Но ты же написал lgtm в комментарии!

— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.

— Ладно, разберусь как-нибудь.

Апрув ( англ. approve) — подтвердить что-нибудь.

Пул реквест ( англ. pull request) — запрос на подтверждение коммита.

LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.

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

Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.

Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.

Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.

Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.

— Я разобрался с багом.

— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.

Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.

Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.

К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.

JavaScript — язык фронтенд-разработки.

Помучившись день, он всё-таки закончил. Тимлид оценил усилия:

— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.

Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.

Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.

По крайней мере на этот спринт.

Заключение

Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.

Источник

Багофича

Багофича — это, в общем-то, самый настоящий баг в игре, но только такой, который не мешает игрокам и не раздражает их, а используется ими, чтобы облегчить прохождение. Обычно приводит к эксплойту (их желательно помещать туда, поскольку это более частный случай), но иногда — к целому пласту геймплея, о котором авторы и не предполагали.

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

Также не стоит путать багофичу с давшим ей название выражением «не баг, а фича». Багофича, как замечено выше, это настоящий баг, который появился как баг, и относятся к нему соответствующе, а фраза имеет в виду намеренно сделанную особенность, которая на первый взгляд может показаться требующим устранения косяком. Также ещё одно родственное явление помимо эксплойта — совершенно законный финт ушами, которым может стать оставленная багофича (перейдя таким образом в категорию «не багов») или, в случае если разработчики не патчат игру, та, которая не ломает баланс и с которой все давно свыклись.

Багофичи породили жанр именуемый глитч, когда прикольные глюки используют как произведение искусства.

Содержание

Примеры багофич [ править ]

Частые виды [ править ]

Уникальные [ править ]

Постоянные [ править ]

Бывает, дело доходит даже до конвейера. Так, очень многие персонажи «Mortal Kombat» изначально были всего-то глюками цвета шкурки бойцов.

Источник

О том, почему багов на самом деле не существует

Прежде всего это мое мнение, я уже очень давно хочу его выразить.

Для начала нам стоит определиться с некоторыми терминами, а именно: баг, багоюз, эксплойт и читерство.

Обратимся к гуглу и посмотрим на результаты.
Баг:

В программировании баг (англ. bug — первичные значения: клоп, любое насекомое, вирус) — жаргонное слово, обычно обозначающее ошибку в программе или системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Большинство багов возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, «глючной», «глюкнутой», «забагованной», «бажной», «баг(а)нутой»).

При определение что такое «багоюз» взглянем для начала на первый всплывающий вариант из вики oxygen-not-included:

Багоюз (от английских слов «bug» и «use») — использование ошибок игры. Обычно это некритичные ошибки (не приводящие к вылетам игры) или недоработки в механиках игры.

А так же одного мудреца, который попробовал ответить на этот вопрос 11 лет назад в otvet.mail.ru:

«Баг»- программная ошибка или недоработка. «Юзать»- пользоваться. Багоюзер- человек, использующий ошибки или недоработки программы. В играх часто обнаруживаются те или ные ошибки, позволяющие игроку необоснованно получать преимущества. Например, стать неуязвимым, получить много денег, ходить и видеть сквозь стены… короче много чего. В этом случае игра становится нечестной, а посему таких игроков во всех играх не любят и наказывают.

Так же мудрец рассказал о сложности вопроса определния баг или не баг, но обо всём по порядку.

Эксплойт по мнению wikipedia:

Эксплойт (англ. exploit, эксплуатировать) — компьютерная программа, фрагмент программного кода или последовательность команд, использующие уязвимости в программном обеспечении и применяемые для проведения атаки на вычислительную систему. Целью атаки может быть как захват контроля над системой (повышение привилегий), так и нарушение её функционирования (DoS-атака).

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

И наконец перейдем к читерству! Естественно в отношении компьютерных игр wikipedia:

Читерство (англ. cheat «мошенничать, обманывать») — использование сторонних программ, обеспечивающих преимущества.

В данном случае позволю дополнить определение, так как читерство существует не только на просторах видео-игр, но и любых других игр, то считаю возможным определить:

Читерство — это нарушение правил игры.

Так как мы с вами определились что Баг это ошибка или недоработка, то играя в видео-игру у нас может возникнуть вопрос: Является ли что-то ошибкой или так и задумал разработчик?

В такой ситуации игроки начинают использовать свои субъективные понятия, например, задаваться вопросом «А можно ли так в жизни?» или «Ну я же могу взять и сделать так?», «Это логично?». Предлагаю посмотреть на примеры подобных обсуждений:

Прошу обратить ваше внимание на мысль которую выразил пользователь:
Не важно что ты думаешь, важно что думает разработчик, если разработчик сказал что не должно так быть, значит так быть не должно.
Я считаю это правильно, потому что это не игрок делал игру, не игрок создавал набор правил по которым будет работать эта игра, а разработчик. Поэтому не игрокам судить является ли что-то багом или фичей.
Однако вопрос баг или фича остаётся всё ещё без ответа т.к. вместе с нами за одним столом во время игры не сидит разработчик, как судья на футбольном поле, и не рассказывает нам что он запланировал, а что нет. А если вдруг рассказал? Предлагаю вам посмотреть данное видео из 2013 года по турниру DOTA2

На турнире The International 2013 с призовым фондом 2.874.380$ команда NAVI использовала известный багоюз, который заключается в телепортации ченом пуджа на фонтан, за счет чего пудж притягивает вражеского героя в сердце своей базы через всю карту, в разы превышая максимальную дальность хука. Почему это известный баг? Потому что его использовали обычные игроки, и сами разработчики заявляли что это баг и будет исправлено, что в итоге и произошло.

Видимо команда NAVI не знала, что багоюзить вообще-то нельзя

Чтож, с Алексеем согласился бы Джонатан «LodA» Берг, который будучи оппонентом NAVI в том турнире после данной игры поднял очень много крика о том, что NAVI надо дисквалифицировать.
К сожалению мне не удалось найти видео где LodA лично об этом говорит на турнире, но под рукой лежит упоминание этого случая которое тоже попробую разобрать.

Что мы имеем? Все знали о баге, баг применили, команду не дисквалифицировали. Почему? Наверное раз его не успели пофиксить, и проводили турнир без плашки что подобная комбинация действий не запрещена игрой, но запрещена турниром, то наказывать ребят не стали.
Значит это так работает?

Один из стримеров проверял баг на тестовом сервере в PUBG и в был забанен за багаюз так же на основном.

Для другого примера из PUBG у меня нет ссылки т.к. не удается найти ту новость и даже видео, однако если вы играли в PUBG с релиза долгое время и следили за турнирами, то возможно вспомните этот случай или баг.
В режиме от первого лица на турнире один из игроков использовал баг с анимацией во время лечения бинтами, персонаж наклонялся и голова проходила сквозь текстуру что позволяло видеть сквозь стены находясь в помещении. Игрок был дисквалифицирован за то что использовал известный баг.
Что мы имеем? Баг известный, однако игрок получил бан. Существуют ли какие-то общие критерии по которым можно наказывать за использование ошибок в игре? А игрок мог понять ошибка это или нет?
«Ну он же смотрел сквозь стену и намеренно использовал анимацию лечения для этого, всё же очевидно что это ошибка» — Если вы придерживаетесь данной позиции то предлагаю вам пролистать вверх до заголовка «Баг или фича» и начать сначала.

Возможно вы слышали о баге с тренерской камерой в CS GO? Я не очень, и речь пойдет о нём лишь косвенно.
Виталий «V1lat» Волочай в комментарии для Sports.ru сравнил хуки под фонтан с багом тренерской камеры в CS:GO

На какие принципы опирается Виталий в отделении хороших багов от плохих?

Хук-фонтан – да, необычное, да, визуально дикое, но все же комбо двух спеллов. В теории такое же могла проделать абсолютно любая команда, если бы вообще додумалась до этого.

Понятно, что некоторые мини-баги остались до сих пор. Но наказывать команду за то, что она экспериментирует, ищет новые творческие решения и использует комбо, которое не претит функциям указанных спеллов – это полный абсурд. Если такое делать, то заодно нужно убирать и эти способности, а лучше и сразу героев.

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

Если так подумать, то есть два более-менее очевидных различия.

Во-первых, сама суть преимущества. Если условный «баг» позволяет то, что в принципе противоречит механикам игры (видеть через дым или стены, летать по всей карте, проходить сквозь текстуры, наступать на птиц и летать, брать контроль над Рошаном и т.д.). Возвращаясь к хук-фонтану, там все происходящее не претит геймплейным основам Доты и особенностям каждого их двух спеллов. Другое дело если завтра внезапно Ио начнет вешать Tether на врагов и Андерлорд тоже сможет забирать всех без разбору – телепортов под фонтан будет вагон. Однако поскольку эти спеллы изначально нельзя использовать на врагах, то здесь был бы очевидный багоюз. Другое дело – если разработчики сами позволят это в будущих апдейтах.

Попробуем разобрать на конкретных примерах которые представил сам Виталий.
Прежде всего, противоречие механикам, которые создаёт разработчик и устанавливает принципы их работы. Как игрок может нарушить принципы работы механик не используя сторонних программ? Если игрок нашёл способ, не прибегая к сторонним программам, модифицированию/изменению файлов игры видеть сквозь дым, то это не он противоречит механикам игры, это он использует механики и возможности игры для достижения целей.
Отдельно отмечу «наступать на птиц и летать». Представьте, вы играете в CS GO, вы не первый игрок который замечает птиц в игре, но вы первый кто решил попробовать запрыгнуть на неё. И в этот момент согласно механикам игры которые создал разработчик, вы начинаете на ней лететь как на передвижной платформе. По мнению Виталия вас необходимо забанить т.к. вы очевидный багоюзер. Однако хук через всю карту признанный багом это взаимодействие дух механик, опять же, по мнению Виталия.
Абсолютно всё что есть в игре позволили сами разработчики, это не игрок создает механики, он их просто использует.

Отдельно стоит выделить следующее:

Во-вторых, количество причастных. Если игрок может использовать какое-то неочевидное преимущество в одиночку (см. все вышеуказанное в предыдущем абзаце) – это однозначно багоюз. А вот когда не обойтись без сторонней помощи, тем более если это требует еще и слаженной работы, соблюдения таймингов – здесь уже можно спорить, баг это или неочевидная штука.

Ну что же, согласно логике Виталия следующее не является багом:

Почему не баг по Виталию? Так как данное неочевидное преимущество, а именно приподнятая моделька над полом передвигающаяся без звука, нельзя использовать эффективно в одиночку т.к. так как требует разных таймингов и командного взаимодействия (а ещё вложение не малой суммы внутриигровых средств). К тому же, данное преимущество не является стабильным и имеет ряд серьёзных недостатков.

И всё же пару слов про баг с камерой в CS GO. Необходимо в контексте известности для разработчиков данных ошибок.

4 сентября бывший тренер Ninjas in Pyjamas по CS:GO Фарук «pita» Пита признался, что заметил этот баг ещё в 2018 году. Он узнал об уязвимости во время матча против mousesports на ESL Pro League S8. Причем эксплойт возникал на протяжении нескольких раундов. После этого Пита написал Valve в личные сообщения в твиттере, но не получил ответ. Затем он повторил свой запрос ещё через четыре месяца — снова молчание.
Источник

А кто не слышал о легендарной распрыжке и рокетджампах? Представьте себе ситуацию как 2005 году, после игры к Coller’у приходят и говорят что он использовал рокетджампы и распрыжку, а это вообще-то баги. Получается смешно.
А бывает что из бага получается целый отдельный жанр, если вы ещё не видели то предлагаю ознакомиться:

А что дота? Неужели и в ней есть баги которые воспринимаются так же как рокетджамп? Есть.
Отводы крипов когда-то воспринимались как то, что противоречит механикам игры. Ты должен стать достаточно сильным на линии прежде чем убивать лесных крипов. Крипы должны встречаться на линии, а ты их отводишь, это ломает принципы игры. Ты стопишь крипов и они приходят медленнее вражеских из-за чего вражеские быстрее умирают под башней. Ну прям багоюзер страшный, многие возможно вспомнят как собирали лобби bez otvodov bez stopa kreepov!

Источник