Что значит пофиксить баги
Пропустить нельзя пофиксить: баги в играх и почему их не избежать
Баги это дефекты и сбои, влияющие на пользовательский опыт, без которых редко обходится любой программный продукт. Чего уж греха таить, даже в играх VOKI Games встречаются эти мелкие вредители, несмотря на многоэтапное тестирование профессионалами.
Некоторые из багов безобидны и вызывают лишь улыбку, а другие приводят к катастрофическим последствиям для имиджа разработчиков. Далее мы расскажем о классификации багов, работе тестировщиков и о том, почему баги все-таки доходят до конечного пользователя.
Что такое баги в игре: цели тестирования продукта
Каждая игра представляет собой компиляцию различного программного кода. Она подчиняется математической модели и включает в себя кучу функциональных элементов. Багами называют непредсказуемые последствия кода и прочие неприятности, в большей или меньшей мере влияющие на игровой процесс.
Выявление «жучков», а именно так переводится английское слово bugs, – основная цель тестирования продукта. Оно проводится не только перед релизом игры, а и при мажорных (с серьезными изменениями) и даже минорных (с незначительными исправлениями и дополнениями) обновлениях, чтобы команда разработчиков могла найти баги, проанализировать их и устранить (т.е. пофиксить).
Недостатки есть в каждом продукте, особенно в первых версиях, которые, пережив только тестирование, еще не подвергались изучению обычными пользователями. Проблема в том, что игровой код – это миллионы и миллиарды функций и сценариев, предугадать взаимосвязь которых очень сложно, а значит, фактически баги никак нельзя исключить.
Поэтому давайте немного переиначим мысль, озвученную абзацем ранее. Цель тестирования продукта – поиск критических багов, которые делают использование игры невозможным. То есть, мелкие сбои вполне могут остаться, и это нормально как для разработчиков, так и для игроков, но вот критическую ошибку пропустить непозволительно.
Тестирование игр: особенности работы тестировщиков
В роли энтомологов, которые отлавливают программных «насекомых», выступают тестировщики. Это специалисты, знающие как искать баги в играх, работающие по специальным тест-кейсам. Для тестировщика важны определенные качества:
Тестировщики ищут баги в играх с позиции конечного пользователя, именно от них зависит, насколько качественным будет приложение и останутся ли в нем критические ошибки. При этом требуется знание хотя бы базовых принципов программирования, технологий разработки ПО и скриптовых языков.
Результаты наблюдений и испытаний тестеры заносят в отчеты и направляют команде. Лично они никак не влияют на код и его качество, но при этом позволяют разработчикам получить полноценное видение ситуации и принять меры для улучшения продукта.
Как искать баги в мобильных играх
Тестирование мобильных игр – многоступенчатый процесс, особенности которого зависят не только от уровня приложения, а и от его реализации. Если говорить коротко, то испытания игрушек проводятся так:
В помощь тестерам – многочисленные сценарии, воспроизводящие разные условия работы. К примеру, для зависимых от интернета игр тестирование проводится в стрессовых условиях. Тестировщики следят за тем, что происходит при проседании скорости, переподключении к сети, ее недоступности на протяжении определенного времени. Так происходит и с другими аспектами развлекательного ПО.
Каждая проблема, найденная тестерами, заносится в отчет вместе с данными о ситуации, приведшей к ней, проявлениях сбоя и оценкой рисков. Да, тестировщик должен уметь оценивать степень серьезности проблемы, чтобы команда разработчиков могла грамотно расставить приоритеты.
Одну и ту же игру могут тестировать месяцами и даже годами, если речь идет об огромном проекте. Чаще на тесты отводят 1–2 месяца, этого вполне достаточно для устранения основных уязвимостей и выпуска игры.
Уровни и категории багов
Чтобы наглядно показать команде степень серьезности бага, тестирование игр проходит по четко заданным критериям. При этом каждой найденной ошибке присваивается уровень. Всего есть пять вариантов серьезности багов:
Приоритетом для команды являются блокирующие и критические ошибки, значительные угрозы тоже правятся. Минорные баги часто остаются в релизных версиях, их фиксят в регулярных обновлениях.
Кроме уровня серьезности, баги делятся на категории по типу ошибки:
Гейм-тестировщики последовательно прорабатывают каждую категорию игры и составляют один полноценный отчет. По его итогам разработчики определяют приоритетные пункты и работают над улучшением приложения.
Пользователи = тестировщики: как недоработки попадают в массы
После выхода большинства игр начинается шквал сообщений об обнаруженных пользователями багах. Возникает вопрос: неужели нельзя все исправить до релиза, на альфа- и бета-стадиях тестирования? У этой ситуации есть несколько причин:
У разработчиков всегда есть дедлайн, который нужно соблюсти, поэтому большую часть тестирования передают игрокам. Это как открытый тест в альфа- и бета-версиях, так и использование релизного варианта игры, в котором пользователи часто находят недостатки.
Если тестировщики работают над выявлением критических погрешностей, то юзеры способны реализовать самые безумные сценарии. Их эффективность гораздо выше, но, к сожалению, из-за отсутствия системного подхода фиксить такие баги могут месяцами.
Самые скандальные баги геймдева
Периодически геймерское сообщество взрывается новостями и гневными сообщениями о недоработанности игровых продуктов. На деле все оказывается не так плохо, а имеющиеся недостатки неторопливо и обстоятельно фиксят в процессе обновлений. Но есть и своеобразные баголидеры, которые стали продуктом непредсказуемости кода и поспешного релиза:
Машины телепортировались, ключевые персонажи начинали циклично ходить, не реагируя на пользователя, а сама игра беспощадно фризила и вылетала. Методом обновлений и заплаток многие из проблем уже убрали, но релиз был действительно провальным.
Монстры отображались с искажениями, сервера постоянно выходили из строя, а багоюзеры становились игровыми богами. В течение нескольких лет игру привели в порядок, но все же Bethesda потеряла многих участников из-за ужасного качества релиз-версии.
Даже среди легендарных игр есть провальные тайтлы, которые запомнились всем. Но стоит отметить, что такие ситуации чаще всего возникают у игр с открытым миром и проработанной механикой – уследить за всем не могут даже профессионалы. В то же время казуальные жанры редко имеют критические ошибки, но создатели все равно выпускают периодические обновления.
Баги, плавно переходящие в фичи
Итог подведем своеобразно – баги могут стать фичами. Серьезно, это хоть и не происходит повсеместно, все равно имеет место в геймдеве. Стоит вспомнить хотя бы баг с поведением полицейских в Grand Theft Auto, которые не объезжали игрока, а старались проехать сквозь него. Копы-психопаты понравились разработчикам и юзерам, прочно войдя в последующие игры серии.
Легендарная «распрыжка» тоже изначально была багом, который появился в Quake. Ее оставили и в других играх (к примеру, Counter-Strike), поскольку запустить режим быстрого движения могли далеко не все игроки, а сам по себе он не был убер-плюшкой. То же касается и рокетджампа, который был замечен случайно, когда игрок выстрелил ракетой себе под ноги. Так родилась обновленная механика, до сих пор юзаемая прогеймерами.
Таким образом, игровой процесс не обходится без багов, которые могут быть как серьезными проблемами, так и безобидными нюансами. Чтобы исключить ошибки, работают целые команды тестировщиков, а также обрабатывается обратная связь от игроков после релиза. Но все равно баги иногда проскакивают и даже превращаются в фичи, это тоже стоит учитывать.
Пофиксить
В своей жизни каждому человеку приходится сталкиваться с массой других людей, употребляющих в своей речи различные профессиональные термины, общаться с ними, но не всегда с первого раза можно понять, что за непонятные слова употребляет собеседник и что он имеет в виду?
Особенно ярким примером служит разговор представителей старшего поколения с младшим или не посвященного в тонкости профессионального жаргона человека с товарищем из какой-либо компетентной сферы. «Пофиксить» — как раз такое слово. Итак, что же оно обозначает?
Значение термина
Для этого иностранного слова, широко распространенного среди молодежи существует два основных значения:
Происхождение
Слово имеет свои корни в английском языке: глагол «to fix» дословно обозначает «исправлять», «налаживать», «приводить в порядок», «чинить», «ремонтировать», «регулировать», «останавливать», «устанавливать».
Существуют и другие значения: фиксировать, усваивать, закреплять, решать, определять, назначать, решать, вводить, внедрять, расправляться, разделываться, привлекать, оседать, получать поддержку, устраиваться. В американском английском слово может обозначать «временное решение проблемы», «взятка», «давать наркотики».
Так же существуют другие разговорные обороты: «to fix a problem» — «решить проблему», «to fix a game» — «договор о выигрыше в игре за взятку».
В русском языке это термин «пофиксить» имеет несколько синонимов:
Употребление слова
Данный англицизм прочно прижился и активно используется в среде профессиональных программистов, в основном тогда, когда обнаружены какие-либо ошибки в программном коде.
О том, что термин плотно вошел в нашу жизнь говорит еще и то, что он фигурирует в названии со временного детского мультфильма «Фиксики», снятого по мотивам комиксов. Фиксики – это умные, маленькие человечки, живущие внутри техники, которые ремонтируют ее в случае поломки, все знают и все умеют.
Примеры употребления в разговорной речи
Дополнительно следует привести несколько примеров употребления данного термина:
Что значит «пофиксить» и «фиксить» в интернет-сленге?
В разговорах геймеров, программистов и других продвинутых юзеров мышки и клавиатуры часто проскакивают непонятные слова: фича, лаги, баги, фиксить… При этом человеку, далёкому от сферы, трудно сориентироваться в теме. Tакая терминология озадачивает, в то же время подогревая интерес и желание так же лихо форсить айтишным арго, как это делают профессионалы. Так давайте разберёмся!
Происхождение и значение
Основная часть интернет-сленга – результат русификации английских слов, и «фиксить» не стало исключением.
В переводе с английского, «tofix» означает «чинить». Среди русскоязычной аудитории прижился вариант «фиксить» или «пофиксить».
Английский язык, а также всевозможные русифицированные производные от английских слов или фраз, наполняют интернет-сленг. Что же касается общих чатов в MMORPG играх, то там сленг превалирует, и нубу (в том же сленговом выражении – «зелёному» новичку или неудачнику), не понятно ни единого слова. И в тех же играх это слово, кстати, имеет двоякое толкование.
Как «фиксят баги» в MMORPG
Помимо общепринятого, «пофиксить» может иметь негативный характер. Зачастую это значит, что определенную категорию лишат значительной части умений. Для примера, возьмем World of Warcraft с его многомиллионной армией подписчиков и почитателей по всему миру. Бывает, очередные обновления приносят не только улучшения и решения по самой игре, но и отдельные решения по игровым классам.
Так, в последнем обновлении игры разработчики сочли нужным «пофиксить» вопросы, связанные с превалированием одного из ведущих составляющих игры, а именно Орды, над Альянсом. И такое решение разработчиков полностью изменило игру! Игроки, которые годами играли за одну из фракций, стали покидать ее из-за того, что разработчики «пофиксили баги» – внесли изменения, убирающие преимущества одной из противодействующих сторон.
Мировая паутина не ограничивается одними играми, есть и более серьезные, уж простите нас, геймеры, занятия, в которых фиксить необходимо.
Игровые баги и лаги
Как фиксить системные баги?
Интернету на днях исполнилось 30 лет. Представить современный мир без него невозможно. Все, от мала до велика, начинают день с просмотра новостной ленты, свежих фотографий у друзей в Instagram или обновления статуса в «Одноклассниках». Всё привычно, никто не задумывается о том, что нужно залогиниться, войти в программу, каждое действие обыденно и производится автоматически. Всё идет хорошо, пока вместо привычной стартовой страницы экран не начинает показывать системные сообщения об ошибках.
Чтобы «починить», пофиксить, сбои приходится обращаться к профессионалам, для которых понятие «курить мануал» – не просто смешное словосочетание, а образ жизни. Невидимый для простого пользователя мир программного обеспечения довольно хрупок, и зачастую, достаточно внести небольшое изменение в системе, чтобы нарушить весь отлаженный рабочий цикл. Для восстановления же нормальной рабочей среды порой приходится затратить большие усилия, фикся, исправляя пустяшные, казалось бы, баги.
Значительная часть сбоев происходит на уровне реестра ОС, для корректировки которого идеально подходит небольшая утилита Hijackthi.
Hijackthi – инструмент, помогающий фиксить баги
Это знакомая и привычная утилита для всех, кому понятие «админка» не режет слух. Фиксить сбои в среде Windows с её помощью удобно, и при понимании дела, абсолютно безопасно. Однако, если написание поста в Facebook – предел знаний IT-технологий, фиксить сбои самому лучше не браться, а обратиться к специалистам.
Багфикс человека: как фиксить баги, которые мешают работать
Почему у людей не получается взять — и выполнить задачу? Откуда берутся заминки, неправильные оценки и прокрастинация? Почему люди не понимают друг друга, хотя вроде бы не дураки и общаются на одном языке?
Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.
Когнитивные искажения — баги в психике человека, которые мешают объективно воспринимать реальность. Их много и они водятся в каждом — на странице Википедии в списке когнитивных искажений под 130 пунктов, и 129 вы, скорее всего, обнаружите у себя. К ним относится сила первого впечатления, желание оправдываться и даже причина, почему мы не можем дать адекватную оценку по задаче.
Когнитивные искажения — как вредные привычки. Жить можно, но лучше бы с ними покончить. И тут с вредными привычками даже проще: мы хотя бы знаем, что курить или точить пиццу под покровом ночи — грешновато, и надо бы в один прекрасный день это прекратить. А когнитивные искажения если в лицо не знаешь — то даже не представляешь, с чем бороться. Сам мозг против этого (но об этом ниже).
Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно 🙂 Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.
Генерализация частных случаев
Генерализация частных случаев — когнитивное искажение, из-за которого человек расширяет поставленную задачу. При этом он даже не осознает, что её можно выполнить проще и быстрее. Чаще всего встречается у программистов и редко фиксится самостоятельно. Чтобы вправить это когнитивное искажение, нужна помощь менеджера. Как минимум один раз ему придётся включить режим варан-менеджмента.
Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера. В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — дело делается, а варан остается голодным 🙂 Кстати, программистам это только поначалу неприятно (ну и неприятна сама идея, что с ними так поступят). Дальше, как ни странно — человек втягивается и выравнивается.
Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
Это невозможно!
Среди когнитивных искажений можно выделить целую группу тех, которые мешают приступить к выполнению задачи. Они тоже чаще встречаются у программистов и дизайнеров, хотя иногда проскакивают и у менеджеров в ответах на хотелки клиентов. И обычно выражаются категоричным: «Это невозможно!».
У такой реакции несколько причин:
Этот баг уже легче отловить самому. Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.
Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.
Проклятие знания
Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.
Проклятие знания устраняется самодрессировкой. Нужно отлавливать своё нелогичное поведение и наступать себе на хвост. Пытаться выстроить конструктивный диалог, даже если очень не хочется. А то всю жизнь можно прожить, думая, что все вокруг глупые, а ты один в пальто стоишь красивый. А на деле окажется, что всё совсем наоборот.
Личное оскорбление
Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.
Это искажение часто встречается у личностей творческих. Особенно если они не выспались и в плохом настроении. За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями. Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
Эффект генерации
Отдаю должное: не все когнитивные искажения — причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит её сам, а не воспринимает извне. Поэтому если вы сомневаетесь, что правильно поняли задачу, или боитесь забыть — просто повторите её вслух.
Нечто похожее есть в авиационных регламентах. Когда диспетчер на земле передает какую-то информацию, пилот в самолете должен всю её повторить. В такой ситуации высока цена ошибки, поэтому повторение необходимо, во-первых, чтобы исключить помехи и другие лажи со связью. Во-вторых, чтобы пилот успел выставить нужные параметры, пока слушает, и просто считал их с приборов, когда отвечает. И, в-третьих, чтобы закрепить полученную информацию эффектом генерации — бонусом.
Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.
Слепое пятно
Это как раз то, о чем я упоминал в начале статьи — мозг не хочет замечать свои несовершенства. Поэтому существует слепое пятно в отношении когнитивных искажений. Даже если человек знает о них, то вряд ли согласится, что они влияют на его поведение. А последствия спишет на обстоятельства и на глупость окружающих. И, соответственно, не сделает ничего, чтобы пофиксить свои когнитивные искажения.
Поэтому если вы замечаете, что задачи делаются с сучками и задоринками, и хотите это изменить — попробуйте оценить объективно, может, причина тому — когнитивные искажения? Если вам кажется, что конечно нет — лучше на всякий случай спросите коллег. Слепое пятно не действует в отношении чужих багов 🙂
Теперь, когда вы знаете про когнитивные искажения, и даже понимаете, в каких именно местах они выпирают и мешают работать, вы сможете с ними бороться. Конечно, будет трудно поначалу, да ещё и слепое пятно будет мешаться. Но со временем оно уменьшится. И тогда и вам, и вашим коллегам станет проще жить и работать — в процессах станет меньше необъяснимых лаж и больше конструктива, мира, дружбы и жвачки.
То, что описано в этой статье — верхушка айсберга когнитивных искажений и аномалий в работе нашего мозга. Если тема вас зацепила и хочется ещё — рекомендую почитать эти книги:
Задача: баг или фича?
Сколько времени потребуется программисту, чтобы запилить весь проект?
В работе у программиста есть проект, в котором нужно пофиксить три бага и добавить три фичи. За час программист может пофиксить 1–2 бага или добавить 1–2 фичи. Но он постоянно отвлекается на форумы и соцсети, поэтому каждый час работа идёт так:
Сколько минимально времени потребуется программисту, чтобы сдать проект без багов и с пустым трекером задач?
Единственное действие, при котором не появляется новых багов и фич — это когда программист за час добавляет сразу две фичи. Получается, что для успешного завершения нужно сделать чётное количество фич подряд — 2, 4, 6, 8 или что-то подобное.
Получается, что задача программиста — своими действиями как можно быстрее прийти к тому, чтобы в проекте остались ненаписанными только фичи и чтобы их число делилось на 2. На старте ему нужно сделать 3 фичи, значит, новая цель — из трёх багов получить нечётное количество фич-заданий в трекере. В итоге это даст программисту их чётное количество, и он их попарно выполнит.
Нечётное количество фич — это 1, 3, 5 и так далее. Если мы закроем сразу два бага, то это даст нам только одну новую фичу в трекере, и останется ещё один баг. Делаем это за первый час:
Исходные данные: 3 бага, 3 фичи.
Час 1: 1 баг, 4 фичи (пофиксили 2 бага, получили +1 фичу в трекере).
У нас появилось чётное количество фич, которые можно сразу попарно закрыть. Тратим ещё 2 часа.
Час 2: 1 баг, 2 фичи (реализовали сразу 2 фичи, новых заданий не появилось).
Час 3: 1 баг (реализовали сразу 2 фичи, новых заданий не появилось).
Уже хорошо. Теперь единственное, что остаётся программисту — отработать этот баг.
Час 4: 2 бага (пофиксили 1 баг, получили 2 новых).
А вот тут можно попасть в ловушку, если сразу пофиксить 2 бага и получить фичу. Дело в том, что если остаётся только одна фича, то после её выполнения в трекере появляется запись, что нужно сделать ещё одну. Получается бесконечный цикл. Значит, нам нужно фиксить по одному багу по очереди.
Час 5: 3 бага (пофиксили 1 баг, получили 2 новых).
Ага, у нас уже 3 бага, а это значит, что можно сделать одновременно 2 из них, и не попасть потом в замкнутый круг. Проверим.
Час 6: 1 баг, 1 фича (пофиксили 2 бага, получили +1 фичу в трекере).
Но мы уже встречали ситуацию, когда был только один баг, и знаем, как из него получить 2, а из двух — фичу. Делаем.
Час 7: 2 бага, 1 фича (пофиксили 1 баг, получили 2 новых).
Час 8: 2 фичи (пофиксили 2 бага, получили +1 фичу в трекере).
И снова появилось чётное количество фич, которые нужно сделать. Закрываем проект финальным шагом.
Час 9: всё сделано (реализовали сразу 2 фичи, новых заданий не появилось).
Ответ: программисту потребуется минимум 9 часов.