Как исправить баг

Как исправить баг

Когда баг стабильно воспроизводится, а его причина понятна, пора исправлять код.

У этого процесса две задачи: исправить баг и не добавить новых. Чтобы проверить, что баг исправлен и исправление ничего не сломало, понадобятся автоматические или ручные тесты.

В общем виде алгоритм исправления бага выглядит так:

Убедиться, что текущие тесты в чистой копии проекта проходят без ошибок.

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

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

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

Заменить решение

Если код опирается на технологическое решение, из‑за которого и появляется баг, можно заменить решение:

В Школьном кабинете

Преподаватели жалуются, что при выставлении оценок пропадают ссылки на работы студентов:

У Андрея Головина видны оценки, но нет ссылки на саму работу

Проблема оказывается в панели поиска, которая появляется в Сафари. Она влияет на высоту экрана, но не на стили. Из‑за этого 100vh (100% высоты экрана) равны старой высоте, а ссылка на работу залезает под оценки.

Заменяем решение: вместо 100vh используем ЦСС ‑переменную , которую сами считаем и обновляем Яваскриптом.

На новом сайте бюро

Дизайнер нашёл баг: при ресайзе форма оплаты уезжает за границы экрана:

Проблему сначала искали в прокрутке и фиксированном позиционировании

Проблема оказывается в ЦСС ‑анимации формы оплаты: при ресайзе Сафари обновляет координаты формы, но не перерисовывает её.

Заменяем решение: вместо ЦСС ‑анимации берём транзишен.

Побороть последствия

Если баг никак не исправить, остаётся бороться с его последствиями:

В Издательстве бюро

Читатели жалуются на подсветку результатов поиска в Хроме: при переходе к найденному развороту Хром прокручивает его за пределы экрана.

Проблема оказывается в Хроме: браузер неправильно считает расстояние до залипающей страницы, возвращая высоту разворота вместо ноля.

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

На новом сайте бюро

Иногда в Сафари форма оплаты после появления перестаёт прокручиваться: не реагирует на скролл и изменение scrollTop . Проблема исчезает после ресайза.

Боремся с последствиями: заставляем браузер пересчитать и перерисовать форму оплаты. Сразу после появления формы очищаем её transform , а через 50 миллисекунд применяем transform: scale(1) . Браузер перерисовывает форму и скролл начинает работать правильно, но визуально для пользователя ничего не меняется.

Что запомнить

Баг мало исправить, нужно ещё и не добавить новых исправлением. Подтвердить это помогают тесты.

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

Как исправить баг

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

Прежде чем что‑то исправлять, нужно понять, что произошло и как должно было быть. Без понимания вы рискуете потратить время впустую или даже ухудшить ситуацию.

Без понимания проблемы

Разработчик видит в отчёте об ошибках, что одна из связей проекта пуста и этим ломает экран с настройками проекта.

Разработчик не вникает в проблему, а добавляет if, чтобы экран настроек пропускал пункт с проблемой.

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

Расследование показывает, что проблема глубже, а отсутствующие записи — просто симптом. Оказывается, дело в коде, который создаёт проекты по шаблону: из‑за ошибки некоторые связи в проектах создаются пустыми. За две недели проблемный код успел создать около двухсот битых проектов, с которыми клиенты не могут нормально работать.

Разработчики исправляют код, создававший проекты; готовят миграцию для битых данных и при следующем деплое аккуратно восстанавливают проекты.

Так исправление бага замаскировало проблему и ухудшило ситуацию.

Без понимания, как должно быть

Когда перезапускали книжный билинг, заметили, что у нескольких читателей подписки не продлевались два‑три месяца. Причину быстро обнаружили и устранили.

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

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

В общем виде алгоритм исправления ошибок выглядит так:

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

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

Когда причина обнаружена, остаётся устранить баг и порефлексировать: что пошло не так, почему, как сделать так, чтобы в будущем таких багов не было.

О каждом из этих шагов я расскажу отдельно в следующих советах.

Что такое баг: поговорим об ошибках в программировании

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

Что такое баг?

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

1. Появилось сообщение об ошибке, программа продолжает работу.
2. Приложение зависает или вылетает без каких-либо предупреждений.
3. Происходит одно из событий с одновременной отправкой отчета разработчику.

Сложнее всего работать с компьютерными играми, в которых чаще используют термин «краш» (crash). Он означает критическую проблему при запуске или использовании программы. Когда говорят о багах, то чаще имеют в виду сбои графики, например, если игрок «проваливается в текстуры».

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Классификация багов

Точка зрения пользователей часто не совпадает с мнением программистов. Так, для первых всего лишь произошел сбой, «приложение перестало работать». Кодеру же предстоит головная боль с определением источника проблемы. Ведь ошибка в программе, вероятно, проявляется лишь на конкретном железе или при сочетании с другим софтом (часто с антивирусами).

Баги делят на категории в зависимости от их критичности:

1. незначительные ошибки,
2. серьезные ошибки,
3. showstopper.

Последние указывают на критическую программную или аппаратную проблему, из-за которой ПО теряет свою функциональность практически на 100%. Например, не удается авторизоваться через логин-пароль или перестала работать кнопка «Далее». Поэтому таким ошибкам отдают приоритет.

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

Есть вариант, когда проблема возникает только на машине конкретного клиента. Здесь приходится либо заказывать индивидуальную «работу над ошибками», либо менять компьютер. Потому что ПО для массового пользователя никто не будет редактировать из-за «одного». Только если наберется некая критическая масса одинаковых случаев.

Разновидности ошибок

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

Кодеры делят ошибки по сложности:

1. Борбаг (Bohr Bug) – «стабильная» ошибка, легко выявляемая еще на этапе отладки или при бета-тестировании, когда речь еще не идет о выпуске стабильной версии.
2. Гейзенбаг (Heisenbug) – периодически проявляющиеся, иногда надолго исчезающие баги с меняющимися свойствами, включая зависимость от программной среды, «железа».
3. Мандельбаг (Mandelbug) – ошибка с энтропийным поведением, почти с непредсказуемым результатом.
4. Шрединбаг (Schroedinbug) – критические баги, чаще приводящие к появлению возможности взлома, хотя внешне никак себя не проявляют.

Последняя категория ошибок – одна из основных причин регулярного обновления операционных систем Windows. Вроде бы пользователя все устраивает, а разработчик раз за разом выпускает новые пакеты исправлений. Наиболее известный баг, попортивший нервы многим кодерам, это «ошибка 2000 года» (Y2K Error). Про нее успешно забыли, но уроки извлекли.

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

Логические

Наиболее серьезная из ошибок. Такие баги приводят к изменению функционирования программы вопреки техническому заданию. К чему это приведет, никто не знает – могут записаться на диске «не те данные», некорректно измениться важные документы или предоставиться доступ к коммерческой информации без авторизации. Исправить их получится только при знании изначальной логики.

Синтаксические

Ошибки синтаксиса существуют на уровне конкретного языка программирования: C, Java, Python, Perl и т.д. Что на одной платформе работает максимум с ворнингами, для другой будет серьезной проблемой. Такие баги легко исправить на этапе компиляции, потому что инструмент не позволит «пройти дальше» некорректного участка кода.

Компиляционные

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

Среды выполнения

Так называемые ошибки Run-Time. Проявляются в скомпилированных программах, при запуске. Например, из-за нехватки ресурсов на машине, в результате аварийной ситуации (поломка памяти, носителя, устройств ввода-вывода). Такое происходит, если разработчик не учел реальных условий работы; придется вернуться к стадии проработки логики.

Арифметические

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

Ресурсные

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

Взаимодействия

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

Что такое исключение

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

Существуют программные и аппаратные исключения. Первые генерируются самой программой и ОС, под которой она запущена. К аппаратным относятся те, что создаются процессором. Например, деление на 0, переполнение буфера, обращение к невыделенной памяти. Исключениями кодеры охватывают наиболее серьезные, критические баги.

Как избежать ошибок?

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

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

Выводы

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

Что такое баг и как с ним бороться

В современном мире nothing is perfect — ничто не безупречно. Мелочь, влияющая на фидбек от пользователя или существенная проблема, замедляющая разработку?

Експертний курс від mate.academy: Fullstack Web Development.
Відкрийте світ розробки у свій вільний час.

Да, сегодня мы поговорим о багах. Что это такое и почему его обязательно нужно фиксить? Будем разбираться.

С технической точки зрения баг — это ошибка, возникающая при разработке программного обеспечения (ПО).

Баг — от английского bug, то есть «жук». Осенью 1947 года инженеры Гарвардского университета никак не могли понять, в чем причина поломки ЭВМ Mark II, пока не обнаружили застрявшего между контактами реле мотылька. Один из них записал в документации это как «Первый случай обнаружения бага». Таким образом с тех пор ошибки выполения ПО стали называть багами.

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

Ефективний курс від skvot: Режисура відеороликів.
Творча магія кінематографу.

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

Чтобы проверить, что баг исправлен и ничего нового в процессе не сломалось, нужно будет провести автоматические или мануальные тесты.

Алгоритм исправления бага выглядит следующим образом:

убедитесь, что тесты в финальной версии проекта проходят без ошибок;

Почему возникают баги?

С учетом статистики возникновение ошибок связано с написанием или изменением кода. И чаще всего это ответственность разработчика.

Професійний курс від mate.academy: Python Вечірній.
Поглиблене вивчення Python.

К вышеперечисленным причинам добавим следующие:

• ошибки и невнимательность при написании кода;
• непонимание логики определенного участка кода;
• незнание особенностей языка программирования;

Давайте немного подробнее поговорим о каждой из причин, приведенных выше.

Невнимательность при написании кода

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

Пример: вся команда не могла понять, почему не работает текст, проверяли в поле значение Сontact . При проверке кода теста (с включенным spellchecker) обнаружили, что буква «С» написана кириллицей.

Ефективний курс від laba: Фінансовий менеджер.
Оптимізуйте фінансовий розвиток компанії.

В примере ниже в missKey пропущена буква «s»:

В таких случаях на помощь придут:

Непонимание логики кода

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

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

Непонимание особенностей языка программирования

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

К примеру, для входного параметра value = 10 условие будет выполняться. Нужно добавить сравнение === .

Тесты

Как мы уже писали выше, тесты делятся на мануальные и автоматизированные.

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

Иногда таких специалистов называют «манки-тестерами» От англ. monkey — обезьяна , как бы намекая на то, что подобная работа вроде как не слишком интеллектуальна, хотя на самом деле это не так.

Мануальный тестировщик должен обладать усидчивостью, внимательностью, логикой и любовью к исследованиям, иначе ему не удастся найти все ошибки.

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

Автотестер должен уметь:

• работать с командной строкой;
• работать с языком программирования;
• пользоваться инструментами разработчиков.

Отсутствие взаимодействия с ошибками

Чтобы познать дзен и научиться эффективно взаимодействовать с багами, нужно уметь обезопасить свой код от внешнего воздействия:

• проверять входящие параметры;
• обрабатывать исключения;
• применять паттерн Null-object.

Копирование чужих ошибок

Копирование чужого кода может сократить время разработки вдвое и в четыре раза увеличить время фиксинга багов. В интернете можно найти много готовых решений. Что ж, будьте внимательны к деталям!

Классификация багов: какими они бывают?

Существуют две главные классификации багов: по степени критичности и приоритетности.

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

• блокирующие, исключающие дальнейшую работу с приложением;
• важные, из-за которых система должным образом не функционирует;
• незначительные, которые существенно не влияют на функционал.

По приоритетности выделяют баги:

• fix in release — можно исправить в новой версии продукта. Как правило, это баги, обнаруженные при тестировании нового функционала системы.
• must fix — срочно исправить. Часто это блокирующие баги, устраняющие выход новой версии в специальном сервисном пакете.
• fix if time — исправить, если позволяет время.
• never fix — никогда не исправлять, например, баги найдены в уже не поддерживаемом продукте.

Как избежать появления багов?

Можно ли избежать появления багов? Это практически невозможно. Любая ошибка — это опыт. Главное своевременно ее заметить и исправить.

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

Заключение

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

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