баг пофиксили что это
Что значит «пофиксить» и «фиксить» в интернет-сленге?
В разговорах геймеров, программистов и других продвинутых юзеров мышки и клавиатуры часто проскакивают непонятные слова: фича, лаги, баги, фиксить… При этом человеку, далёкому от сферы, трудно сориентироваться в теме. Tакая терминология озадачивает, в то же время подогревая интерес и желание так же лихо форсить айтишным арго, как это делают профессионалы. Так давайте разберёмся!
Происхождение и значение
Основная часть интернет-сленга – результат русификации английских слов, и «фиксить» не стало исключением.
В переводе с английского, «tofix» означает «чинить». Среди русскоязычной аудитории прижился вариант «фиксить» или «пофиксить».
Английский язык, а также всевозможные русифицированные производные от английских слов или фраз, наполняют интернет-сленг. Что же касается общих чатов в MMORPG играх, то там сленг превалирует, и нубу (в том же сленговом выражении – «зелёному» новичку или неудачнику), не понятно ни единого слова. И в тех же играх это слово, кстати, имеет двоякое толкование.
Как «фиксят баги» в MMORPG
Помимо общепринятого, «пофиксить» может иметь негативный характер. Зачастую это значит, что определенную категорию лишат значительной части умений. Для примера, возьмем World of Warcraft с его многомиллионной армией подписчиков и почитателей по всему миру. Бывает, очередные обновления приносят не только улучшения и решения по самой игре, но и отдельные решения по игровым классам.
Так, в последнем обновлении игры разработчики сочли нужным «пофиксить» вопросы, связанные с превалированием одного из ведущих составляющих игры, а именно Орды, над Альянсом. И такое решение разработчиков полностью изменило игру! Игроки, которые годами играли за одну из фракций, стали покидать ее из-за того, что разработчики «пофиксили баги» – внесли изменения, убирающие преимущества одной из противодействующих сторон.
Мировая паутина не ограничивается одними играми, есть и более серьезные, уж простите нас, геймеры, занятия, в которых фиксить необходимо.
Игровые баги и лаги
Как фиксить системные баги?
Интернету на днях исполнилось 30 лет. Представить современный мир без него невозможно. Все, от мала до велика, начинают день с просмотра новостной ленты, свежих фотографий у друзей в Instagram или обновления статуса в «Одноклассниках». Всё привычно, никто не задумывается о том, что нужно залогиниться, войти в программу, каждое действие обыденно и производится автоматически. Всё идет хорошо, пока вместо привычной стартовой страницы экран не начинает показывать системные сообщения об ошибках.
Чтобы «починить», пофиксить, сбои приходится обращаться к профессионалам, для которых понятие «курить мануал» – не просто смешное словосочетание, а образ жизни. Невидимый для простого пользователя мир программного обеспечения довольно хрупок, и зачастую, достаточно внести небольшое изменение в системе, чтобы нарушить весь отлаженный рабочий цикл. Для восстановления же нормальной рабочей среды порой приходится затратить большие усилия, фикся, исправляя пустяшные, казалось бы, баги.
Значительная часть сбоев происходит на уровне реестра ОС, для корректировки которого идеально подходит небольшая утилита Hijackthi.
Hijackthi – инструмент, помогающий фиксить баги
Это знакомая и привычная утилита для всех, кому понятие «админка» не режет слух. Фиксить сбои в среде Windows с её помощью удобно, и при понимании дела, абсолютно безопасно. Однако, если написание поста в Facebook – предел знаний IT-технологий, фиксить сбои самому лучше не браться, а обратиться к специалистам.
Багфикс человека: как фиксить баги, которые мешают работать
Почему у людей не получается взять — и выполнить задачу? Откуда берутся заминки, неправильные оценки и прокрастинация? Почему люди не понимают друг друга, хотя вроде бы не дураки и общаются на одном языке?
Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.
Когнитивные искажения — баги в психике человека, которые мешают объективно воспринимать реальность. Их много и они водятся в каждом — на странице Википедии в списке когнитивных искажений под 130 пунктов, и 129 вы, скорее всего, обнаружите у себя. К ним относится сила первого впечатления, желание оправдываться и даже причина, почему мы не можем дать адекватную оценку по задаче.
Когнитивные искажения — как вредные привычки. Жить можно, но лучше бы с ними покончить. И тут с вредными привычками даже проще: мы хотя бы знаем, что курить или точить пиццу под покровом ночи — грешновато, и надо бы в один прекрасный день это прекратить. А когнитивные искажения если в лицо не знаешь — то даже не представляешь, с чем бороться. Сам мозг против этого (но об этом ниже).
Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно 🙂 Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.
Генерализация частных случаев
Генерализация частных случаев — когнитивное искажение, из-за которого человек расширяет поставленную задачу. При этом он даже не осознает, что её можно выполнить проще и быстрее. Чаще всего встречается у программистов и редко фиксится самостоятельно. Чтобы вправить это когнитивное искажение, нужна помощь менеджера. Как минимум один раз ему придётся включить режим варан-менеджмента.
Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера. В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — дело делается, а варан остается голодным 🙂 Кстати, программистам это только поначалу неприятно (ну и неприятна сама идея, что с ними так поступят). Дальше, как ни странно — человек втягивается и выравнивается.
Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
Это невозможно!
Среди когнитивных искажений можно выделить целую группу тех, которые мешают приступить к выполнению задачи. Они тоже чаще встречаются у программистов и дизайнеров, хотя иногда проскакивают и у менеджеров в ответах на хотелки клиентов. И обычно выражаются категоричным: «Это невозможно!».
У такой реакции несколько причин:
Этот баг уже легче отловить самому. Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.
Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.
Проклятие знания
Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.
Проклятие знания устраняется самодрессировкой. Нужно отлавливать своё нелогичное поведение и наступать себе на хвост. Пытаться выстроить конструктивный диалог, даже если очень не хочется. А то всю жизнь можно прожить, думая, что все вокруг глупые, а ты один в пальто стоишь красивый. А на деле окажется, что всё совсем наоборот.
Личное оскорбление
Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.
Это искажение часто встречается у личностей творческих. Особенно если они не выспались и в плохом настроении. За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями. Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
Эффект генерации
Отдаю должное: не все когнитивные искажения — причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит её сам, а не воспринимает извне. Поэтому если вы сомневаетесь, что правильно поняли задачу, или боитесь забыть — просто повторите её вслух.
Нечто похожее есть в авиационных регламентах. Когда диспетчер на земле передает какую-то информацию, пилот в самолете должен всю её повторить. В такой ситуации высока цена ошибки, поэтому повторение необходимо, во-первых, чтобы исключить помехи и другие лажи со связью. Во-вторых, чтобы пилот успел выставить нужные параметры, пока слушает, и просто считал их с приборов, когда отвечает. И, в-третьих, чтобы закрепить полученную информацию эффектом генерации — бонусом.
Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.
Слепое пятно
Это как раз то, о чем я упоминал в начале статьи — мозг не хочет замечать свои несовершенства. Поэтому существует слепое пятно в отношении когнитивных искажений. Даже если человек знает о них, то вряд ли согласится, что они влияют на его поведение. А последствия спишет на обстоятельства и на глупость окружающих. И, соответственно, не сделает ничего, чтобы пофиксить свои когнитивные искажения.
Поэтому если вы замечаете, что задачи делаются с сучками и задоринками, и хотите это изменить — попробуйте оценить объективно, может, причина тому — когнитивные искажения? Если вам кажется, что конечно нет — лучше на всякий случай спросите коллег. Слепое пятно не действует в отношении чужих багов 🙂
Теперь, когда вы знаете про когнитивные искажения, и даже понимаете, в каких именно местах они выпирают и мешают работать, вы сможете с ними бороться. Конечно, будет трудно поначалу, да ещё и слепое пятно будет мешаться. Но со временем оно уменьшится. И тогда и вам, и вашим коллегам станет проще жить и работать — в процессах станет меньше необъяснимых лаж и больше конструктива, мира, дружбы и жвачки.
То, что описано в этой статье — верхушка айсберга когнитивных искажений и аномалий в работе нашего мозга. Если тема вас зацепила и хочется ещё — рекомендую почитать эти книги:
Пофиксить
В своей жизни каждому человеку приходится сталкиваться с массой других людей, употребляющих в своей речи различные профессиональные термины, общаться с ними, но не всегда с первого раза можно понять, что за непонятные слова употребляет собеседник и что он имеет в виду?
Особенно ярким примером служит разговор представителей старшего поколения с младшим или не посвященного в тонкости профессионального жаргона человека с товарищем из какой-либо компетентной сферы. «Пофиксить» — как раз такое слово. Итак, что же оно обозначает?
Значение термина
Для этого иностранного слова, широко распространенного среди молодежи существует два основных значения:
Происхождение
Слово имеет свои корни в английском языке: глагол «to fix» дословно обозначает «исправлять», «налаживать», «приводить в порядок», «чинить», «ремонтировать», «регулировать», «останавливать», «устанавливать».
Существуют и другие значения: фиксировать, усваивать, закреплять, решать, определять, назначать, решать, вводить, внедрять, расправляться, разделываться, привлекать, оседать, получать поддержку, устраиваться. В американском английском слово может обозначать «временное решение проблемы», «взятка», «давать наркотики».
Так же существуют другие разговорные обороты: «to fix a problem» — «решить проблему», «to fix a game» — «договор о выигрыше в игре за взятку».
В русском языке это термин «пофиксить» имеет несколько синонимов:
Употребление слова
Данный англицизм прочно прижился и активно используется в среде профессиональных программистов, в основном тогда, когда обнаружены какие-либо ошибки в программном коде.
О том, что термин плотно вошел в нашу жизнь говорит еще и то, что он фигурирует в названии со временного детского мультфильма «Фиксики», снятого по мотивам комиксов. Фиксики – это умные, маленькие человечки, живущие внутри техники, которые ремонтируют ее в случае поломки, все знают и все умеют.
Примеры употребления в разговорной речи
Дополнительно следует привести несколько примеров употребления данного термина:
Баг пофиксили что это
Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Тип 1. Баги, связанные с устаревшими устройствами и программами
Тип 1. Баги, связанные с устаревшими устройствами и программамиЕсли вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет.
Здесь стоит сделать оговорку: все же не стоит отсекать идею пофиксить подобный баг сразу. Все нужно соотносить с полезностью для пользователей и вашими затратами. Например, если вы потратите на фикс 10 минут, а «спасибо» вам при этом скажут десятки тысяч человек, нужно браться за работу. А вот тратить 20 часов для одного пользователя бесплатной версии, который отписался под одним из ваших постов на Хабре годичной давности, – это непродуктивное решение.
Тип 2. Баги в сторонних компонентах
У программиста может не быть компетенций для исправления ошибки, если в его решении используется сторонний компонент. Зачастую это классическая проблема «черного ящика»: три дырки на входе и три дырки на выходе, код закрыт, лицензия проприетарная. Но даже открытый исходный код не гарантирует того, что проблему в принципе можно решить. Например, разработчики ПО на основе OpenOffice не правят баги в OpenOffice, потому что знают, что просто не смогут потом его собрать.
Представим ситуацию: создавая веб-приложение, вы имеете дело с ограничениями, которые накладывает браузер (например, с неспособностью распознать текущую раскладку клавиатуры).
Вот реальная ситуация: в текстовом процессоре Microsoft Word язык проверки орфографии меняется в зависимости от того, в какой раскладке вы набираете текст, в то время как в онлайн-редакторе вам придется задать язык проверки орфографии вручную. Таким образом, пытаясь вести себя как пользователь Microsoft Word (что в общем-то логично), пользователь онлайн-редактора испытает неудобства, а вы не можете ему помочь, так как находитесь в естественных границах технологии.
Тип 3. Баги, которые никогда не воспроизведутся у пользователей
Ваша преданная талантливая команда тестировщиков смогла их найти, а вот пользователи… пользователи вряд ли будут этим заниматься. В общем, здесь речь идет о багах, которые можно воспроизвести синтетически при большом желании; в реальности пользователь никогда с ними не столкнется.
В эту же категорию попадают латентные баги, которые юзер никогда не увидит, потому что выцепить их можно только в коде.
Представим, что наше приложение – это маленький завод с двумя типами производств: низкого и высокого уровня. Производства низкого уровня не могут принимать определенные значения, и приложение падает, но производство более высокого уровня отсеивает данные, которые могут нарушить производство более низкого уровня. В том случае, когда мы вбиваем невалидные для низкоуровневого компонента значения, компонент более высокого уровня говорит: «Нет, ребята, так нельзя, вы можете ввести только что-то валидное». Тестировщик все же сможет ввести такие данные, если обратится напрямую к функции (в обход интерфейса), но у пользователя такой возможности нет, и он никогда не уронит приложение таким способом.
Тип 4. Баги, которые сложно повторить
Тип 5. Баги, которые приносят деньги
Тип 6. Баги, которые ни на что не влияют
Тип 7. Баги, за которые никто не отвечает
Если в предыдущих пунктах речь шла о багах, которые невозможно или даже не нужно править, то здесь мы поговорим о типе багов, являющихся симптомом опасной болезни. Это баги, появившиеся в процессе создания той части продукта, «на которую всем плевать» (потому что никто толком за нее не отвечает).
Абстрактный сценарий такой: несколько отделов создают общую фичу. Сначала дизайнеры нарисовали кнопку и забыли. Потом программист из отдела 1 в силу своей загруженности подготовил компонент, забыв пробросить туда кое-какие методы. Программист из отдела 2 взял готовый компонент и вставил его в продукт без исправлений. Работает? Скорее всего, работает, но при этом может, например, выглядеть уродливо. Ну а поскольку для всех героев это была всего лишь побочная задача среди сотен других, то все так и остается.
Баги, за которые никто не отвечает, могут быть довольно критичными. При этом их никто не будет фиксить до тех пор, пока пользователи молчат. И это тревожный звоночек… а может, даже целый колокол! Звонит он не только и столько по заброшенной части продукта – он звонит по организационным процессам в компании.
Как с этим жить?
Продуктов без багов не бывает, бывает лишь различная степень толерантности к ним. Последняя зависит от сферы, в которой функционирует ваше ПО. Например, если вы пишете код для бортового компьютера космического корабля, логично предположить, что толерантность к багам будет нулевой. Тем не менее, когда на гитхабе опубликовали исходный код программы для бортового управляющего компьютера «Аполлона-11», пользователи сервиса нашли места, которые можно было поправить. Пусть это были баги уровня опечатки (и расширения для спасения Мэтта Деймона, но их мы в расчет не берем), но они присутствовали.
Наличие незакрытых тикетов в багтрекере – это не свидетельство некомпетентности и не трагедия. Да, здесь автор немного драматизирует, прочитав на stackexchage трэд о том, как стать zero-bug programmer (ответ: не писать код или найти себе плохих тестировщиков).
Судьба бага
Этика и профессиональная гордость подсказывают нам, что необходимо фиксить все баги, которые мы можем найти, но реальность оказывается сложнее. Есть два типа багов:
Во втором случае вам всегда придется принимать бизнес-решение, руководствуясь как минимум двумя вещами – здравым смыслом и собственной выгодой.
В эссе основателя Source Gear Эрика Синка My life as a Сode Economist автор предлагает задавать себе по поводу каждого бага четыре вопроса:
Иногда разработчик отвечает на эти вопросы в собственной голове за считанные секунды. Бывает, что приходится собирать консилиум и расставлять приоритеты в течение нескольких часов. Но правильное решение есть всегда. Главное – помнить, что ваши баги либо приносят вам деньги (хотя бы потому, что пользователь готов с ними мириться), либо заставляют вас их терять. Впрочем, мы желаем вам поменьше жучков обоих типов!
Задача: баг или фича?
Сколько времени потребуется программисту, чтобы запилить весь проект?
В работе у программиста есть проект, в котором нужно пофиксить три бага и добавить три фичи. За час программист может пофиксить 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 часов.