что такое баг в приложении
Что такое баги, ворнинги и исключения в программировании
Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.
Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.
В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Ошибки в программировании
Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:
Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.
Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:
Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.
После восклицательного знака в треугольнике — количество предупреждений
Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:
Вот результат работы такого кода:
Баги в программах
Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:
Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.
Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.
Исключения в программах
Также во время работы программы могут возникать ситуации, которые мешают корректной работе программы. Например, если вы просите пользователя ввести число, а он вводит строку.
Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.
Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.
Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.
Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:
Вот аналогичный код на языке C#:
Однако сообщение в этот раз более конкретное:
В обоих случаях программа завершается, потому что не может дальше корректно работать.
Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.
Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):
Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.
Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.
Как избежать всех этих ошибок
К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.
Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.
Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.
Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:
Если какой-то из этих тестов не пройден, вы узнаете об этом и сможете всё исправить. Это намного быстрее, чем проверять всё вручную.
Заключение
Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.
Если вы хотите научиться писать качественный код и находить в нём ошибки, вы можете записаться на наш курс по разработке на C++.
Баги — это норма: как в приложениях возникают ошибки и почему их не нужно бояться
1. А что такое баг? Объясните понятно.
В своей основе мобильное приложение — это код. Баг — это ошибка в коде. неё приложение ведёт себя некорректно, например зависает, вылетает или не откликается на действия пользователя.
Неправильное поведение — закономерный ответ на ошибку. Представьте, что вы написали сложную инструкцию с большим количеством шагов, и в шаге № 404 непонятно объяснили, что делать. этого человек, который будет следовать инструкции, никогда не придёт к правильному результату. Так же и приложение. Оно не поймёт, как себя вести, если в его «инструкции» есть ошибка.
2. Ну, а разве нельзя сразу писать код без ошибок?
Это возможно только в идеальном мире. А в нашем — нет. Приложение — сложная комплексная система. С каждым новым элементом взаимодействие её частей усложняется, и это приводит к возникновению ошибок в мобильном приложении. Всё как в общении: чем больше людей, тем сложнее договориться. Разработчик «соединяет» разные элементы в единый код. Если элемент неизвестный (сторонняя библиотека или сервер, с которым на проекте ещё не работали), разработчик не сможет предвидеть, получится ли у этого элемента найти «общий язык» с существующими частями кода.
К тому же ошибки могут появляться банальных «опечаток» в коде мобильного приложения. Написание кода можно сравнить с набором сообщения. Мы делаем это каждый день, но всё равно ошибаемся. По десять раз перечитываем текст и замечаем опечатку, только когда отправили сообщение собеседнику. От этого не страхует ни проверка орфографии, ни Т9. Все мы люди и не можем быть сконцентрированы 24/7.
Вот и разработчик может не заметить свою ошибку. Тем более, что обычно в коде мобильного приложения около тысяч строк, и уследить за всеми знаками невозможно.
3. Получается, что ошибки возникают разработчика?
Это не так. Ошибка в приложении может произойти и на стороне интегратора — стороннего сервиса, с которым приложение «сотрудничает». Разработчик не сможет её предотвратить, потому что она находится вне зоны его влияния.
Так, например, ни одно не обходится без интеграции с платёжным шлюзом — страницей банка, на которой пользователь вводит номер банковской карты для оплаты. Для человека переход из приложения на внешнюю страницу незаметен: дизайн экрана платёжного шлюза почти не отличается от экрана оплаты, поэтому пользователь не видит разницы между ними.
Ориентируясь на ответ банка, приложение скажет пользователю: «Поздравляем! Покупка завершена» или «Упс, что-то пошло не так». Если что-то не так, то значит проблема на стороне интегратора. Единственное, что могут сделать мобильные разработчики в этом случае — «постучаться» в отдел техподдержки шлюза и предупредить о сбое.
Появление ошибок — естественный и закономерный процесс в разработке приложений. И разработчик к этому готов. За свои баги он отвечает сам: не только знает, что ошибки будут, но и знает, как их искать. Для этого разработчик пишет автотесты — части кода, которые имитируют взаимодействие пользователя и приложения. Разработчик проверяет написанный код с помощью автотестов, исправляет очевидные ошибки и продолжает работу.
4. Так если разработчик всё проверяет, то почему мы вообще об этом говорим?
Автотестов недостаточно для полной проверки. Они покрывают только формальный алгоритм работы, но не могут воспроизвести поведение и мотивацию «живого» пользователя. Это может сделать только человек. Поэтому проверкой пользовательских кейсов в команде занимается другой специалист — , или тестировщик.
Проверяя приложение, тестировщик находится в роли пользователя: открывает приложение и совершает те же шаги, которые, предположительно, должен проделать человек, установивший приложение.
Тестировщик проходит определённый пользовательский сценарий. Это нужно делать на разных устройствах с разными версиями ОС и разной диагональю, чтобы удостовериться, что приложение будет вести себя правильно на всех моделях. Если не работает или работает не так, тестировщик фиксирует баг и отправляет сборку на фикс (доработку), чтобы разработчик его починил.
5. Отлично! Тестировщик нашёл все баги, разработчик их починил — можно расслабиться.
Подождите, не всё так просто. Нужно быть готовым к тому, что баги будут обнаружены не только во время разработки приложения, но и после релиза, то есть когда приложение появится в сторе — магазине приложений, например в App Store или Google Play.
Такое происходит потому, что мы не можем покрыть все пользовательские сценарии, как бы ни старались. Мобильных устройств — очень много. Действий, которых человек совершает в приложении, тоже. Количество смартфонов, умноженное на количество действий, даёт безграничное пространство для возникновения ошибки. И нет героя, который смог бы разобрать все эти кейсы. Поэтому лучше заранее подготовить себя к тому, что в мобильном приложении будут возникать ошибки, и позволить студии разработки их исправить.
6. А как баг может повлиять на работу приложения?
Зависит от такого, насколько этот баг серьёзен. Условно ошибки, которые выдаёт приложение, можно разделить на три вида: критические, значительные и несущественные.
Критические баги мешают человеку использовать приложение. Они блокируют основную функцию приложения и не дают ему работать на клиента. Значительные баги для не опасны, но они могут доставлять человеку неудобства в использовании приложения. А несущественные баги — это мелкие нарушения, которые пользователь не может заметить. Вот так это выглядит на примере :
7. И что делать, если в моём приложении произошла ошибка?
Прежде всего сохранять спокойствие, ведь нет бага, который нельзя поправить. Если приложение вышло в релиз с критическим багом, то ответственность студия разработки берёт на себя. Это значит, что в ближайшее время после обнаружения бага мы среагируем на него и уберём ошибку приложения. А вот с несущественным багом приложение может жить, поэтому его починку студия перенесёт на следующий плановый релиз.
8. Хорошо, значит критический баг починят первым?
Не совсем так. Чтобы понять, какую ошибку приложения удалять в первую очередь, нужно определить не только серьёзность бага, но и его приоритет: средний низкий или высокий.
У критического бага не всегда будет высокий приоритет. Представим, что пользователь не может добавить в корзину штаны, потому что у этой категории товаров сломалась кнопка «В корзину». Если пользователь не может добавить штаны в корзину, значит, он не может их купить. Это критический баг, который нужно чинить. Но в то же время на главном экране приложения есть другая проблема — название магазина написано с опечаткой. Это значительный баг, но приоритет у него выше. Сейчас объясним почему.
9. Значит я могу не бояться багов?
Именно так. К разработчику баги приходят как данность. Мы ожидаем их и знаем, как их исправить. И рассказываем об этом клиентам. Иногда они тоже могут побыть в роли тестировщика — мы отдаём им готовую сборку перед релизом, чтобы они сами убедились, что приложение в порядке.