Как убрать баги и ошибки

Войти на сайт

или

Забыли пароль?
Еще не зарегистрированы?

Ликвидировать нужно не баги, а причину их появления: кейс от разработчика игр

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

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

Skillbox рекомендует: Двухлетний практический курс «Я – Веб-разработчик PRO».

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Снижаем количество багов

Поскольку все баги — в коде, то, наверное, просто достаточно попросить команду разработки допускать меньше ошибок?

Если вам смешно в этом месте, я не удивлюсь. И действительно, ведь никто (ну или практически никто) не совершает их по собственной воле. Так что же можно предложить команде, чтобы она делала меньше ошибок в коде, с тем, чтобы в нем не было багов?

Начинаем новый проект. Шаг первый — не повторяем предыдущих ошибок

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

Шаг первый — определиться, зачем все это нужно. «Зачем» верхнего уровня объясняется просто: мы хотим снизить количество времени, требуемого на ликвидацию багов, оптимизировать затраты и повысить общее качество проекта.

Речь идет о том, чтобы освободить время на выполнение интересных задач, тех, что позволяют радостно просыпаться утром и тут же браться за реализацию таска. Это то, что сделало нас всех разработчиками — возможность использоваться свое время на по-настоящему крутые штуки!

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

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

Наблюдение

Категоризация

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

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

Анализ

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

Причина проблемы

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

Работая с техническими специалистами, мы обнаружили больше fix changes. Затем составили новые списки систем, файлов и строк кода, связанных с крупными багами. В итоге мы сделали список необходимых изменений кода, который можно было обсудить с командой разработчиков.

Мы же вам говорили!

Затем мы провели встречу вместе с программистами для того, чтобы обсудить наши находки. Как оказалось, ребята знали о большинстве проблемных мест в коде. Но если это так, какой смысл был в том, чтобы проводить встречу?

Ответ: у нас получилось провести параллель между конкретными местами кода и временными потерями, связанными с этими проблемами. А это, в свою очередь, дало возможность объективно оценивать любое предложение по обслуживанию кода.

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

В самом деле, многие проблемы были системными. Многие «невидимые» аспекты приводили к цепочке событий, которые обусловливали появление ошибки. К слову, причины проблем были настолько системными, что проект пришлось начинать практически с нуля.

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

Гипотезы

Гипотеза 1. Специфические паттерны кодинга, вероятно, приведут к появлению багов в крупном программном проекте.

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

Давайте определимся с тем, что такое большой проект. Это около 25 программистов, 12 месяцев разработки. Для него справедливы следующие утверждения:
А. Любой код будет жить достаточно долго, так что стоимость обслуживания в итоге превысит стоимость самой разработки.
Б. Сложность соединения отдельных систем проекта выше, чем сложность конкретно взятой системы.

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

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

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

Теперь приступаем к практической реализации.

Тестирование

При создании нового проекта необходимо избегать идентифицированных паттернов багов. У нас это были:

• Перегрузка операторов и неудачное именование.
• Auto, полиморфные функции и пренебрежение типобезопасностью.
• Увеличение сложности кода путем, например, внедрения зависимостей и обратных вызовов.
• Использование мьютексов, семафоров и тому подобного в высокоуровневом коде.

Что дальше?

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

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

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

Skillbox рекомендует:

• Практический курс «Профессия веб-разработчик».
• Онлайн-курс «Профессия frontend-разработчик».
• Практический годовой курс «PHP-разработчик с 0 до PRO».

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

Программная ошибка: что это и почему возникает

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

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

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

Ошибки часто называют багами, но подразумевают под ними разное, например:

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

❗ Исключения. Это не ошибки, а особые ситуации, которые нужно обработать.

❗ Синтаксические ошибки. Это ошибка в программе, связанная с написанием кода. Пример: программист забыл поставить точку или неверно написал название оператора. Если не исправить, код программы не запустится, а останется просто текстом.

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

У багов есть два атрибута — серьезности (Severity) и приоритета (Priority). Серьезность касается технической стороны, а приоритет — организационной.

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

По серьезности баги классифицируют так:

• Blocker — блокирующий баг. Программа запускается, но спустя время баг останавливает ее выполнение. Чтобы снова пользоваться программой, блокирующую ошибку в коде устраняют.
• Critical — критический баг. Нарушает функциональность программы. Появляется в разных частях кода, из-за этого основные функции не выполняются.
• Major — существенный баг. Не нарушает, но затрудняет работу основного функционала программы либо не дает функциям выполняться так, как задумано.
• Minor — незначительный баг. Слабо влияет на функционал программы, но может нарушать работу некоторых дополнительных функций.
• Trivial — тривиальный баг. На работу программы не влияет, но ухудшает общее впечатление. Например, на экране появляются посторонние символы или всё рябит.

🚦 По приоритету. Атрибут показывает, как быстро баг необходимо исправить, пока он не нанес программе приличный ущерб. Бывает таким:

• Top — наивысший. Такой баг — суперсерьезный, потому что может обвалить всю программу. Его устраняют в первую очередь.
• High — высокий. Может затруднить работу программы или ее функций, устраняют как можно скорее.
• Normal — обычный. Баг программу не ломает, просто где-то что-то будет работать не совсем верно. Устраняют в штатном порядке.
• Low — низкий. Баг не влияет на программу. Исправляют, только если у команды есть на это время.

Типы ошибок в программе

🧨 Логические. Приводят к тому, что программа зависает, работает не так, как надо, или выдает неожиданные результаты — например, не записывает файл, а стирает.
Логические ошибки коварны: их трудно обнаружить. Программа выглядит так, будто в ней всё правильно, но при этом работает некорректно. Чтобы победить логические ошибки, специалист должен хорошо ориентироваться в коде программы.

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

🧨 Взаимодействия. Это ошибка в участке кода, который отвечает за взаимодействие с аппаратным или программным окружением. Такая ошибка возникает, например, если неправильно использовать веб-протоколы. Исправляется элементарно: разработчик переписывает нужный кусок кода.

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

Компиляционные баги появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».

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

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

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг. Надо лезть в код и проверять математику.

Что такое исключения в программах

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

Как это происходит:

1. Когда программист кодит, то продумывает, в какой части программы может вылезти ошибка.
2. В этой части пишет специальный фрагмент, который предупредит компьютер, что ошибка — вполне ожидаемое явление и резко обрывать программу не нужно.
3. Когда юзер запустит программу и появится ошибка, компьютер увидит заранее подготовленное предупреждение программиста. Продолжит выполнять алгоритм так, словно никакого бага и не было.

Исключения бывают программными и аппаратными:

• Аппаратные создает процессор. К ним относят деление на ноль, выход за границы массива, обращение к невыделенной памяти.

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

Как контролировать баги в программе

🔧 Следите за компилятором. Когда компилятор преобразует текст программы в машинный код, то подсвечивает в нём сомнительные участки, которые способны вызывать баги. Некоторые предупреждения не обозначают баг как таковой, а только говорят: «Тут что-то подозрительное». Всё подозрительное надо изучать и прорабатывать, чтобы не было проблемы в будущем.

🔧 Используйте отладчик. Это программа, которая без участия айтишника проверяет, исправно ли работает алгоритм. В случае чего сообщает об ошибках. Например, отладчик используют для построчного выполнения программы. Вместе с тем проверяют значения переменных: фактические сравнивают с ожидаемыми. Если что-то не сходится, ищут баги и исправляют.

🔧 Проводите юнит-тесты. Это когда разработчик или тестировщик описывает ситуации для каждого компонента и указывает, к какому результату должна привести программа. Потом запускает проверку. Если результат не совпадает с ожидаемым, появляется предупреждение. Дальше программисты находят и устраняют проблему.

Ключевое: что такое ошибки в программировании

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

1. А что такое баг? Объясните понятно.

В своей основе мобильное приложение — это код. Баг — это ошибка в коде. Из-за неё приложение ведёт себя некорректно, например зависает, вылетает или не откликается на действия пользователя.

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

2. Ну, а разве нельзя сразу писать код без ошибок?

Это возможно только в идеальном мире. А в нашем — нет. Приложение — сложная комплексная система, разработка которой делается долго и стоит дорого. С каждым новым элементом взаимодействие её частей усложняется, и это приводит к возникновению ошибок в мобильном приложении. Всё как в общении: чем больше людей, тем сложнее договориться. Разработчик «соединяет» разные элементы в единый код. Если элемент неизвестный (сторонняя библиотека или сервер, с которым на проекте ещё не работали), разработчик не сможет предвидеть, получится ли у этого элемента найти «общий язык» с существующими частями кода.

К тому же ошибки могут появляться из-за банальных «опечаток» в коде мобильного приложения. Написание кода можно сравнить с набором сообщения. Мы делаем это каждый день, но всё равно ошибаемся. По десять раз перечитываем текст и замечаем опечатку, только когда отправили сообщение собеседнику. От этого не страхует ни проверка орфографии, ни Т9. Все мы люди и не можем быть сконцентрированы 24/7.

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

3. Получается, что ошибки возникают из-за разработчика?

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

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

4. Так если разработчик всё проверяет, то почему мы вообще об этом говорим?

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

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

Тестировщик проходит определённый пользовательский сценарий. Это нужно делать на разных устройствах с разными версиями ОС и разной диагональю, чтобы удостовериться, что приложение будет вести себя правильно на всех моделях. Если что-то не работает или работает не так, тестировщик фиксирует баг и отправляет сборку на фикс (доработку), чтобы разработчик его починил.

5. Отлично! Тестировщик нашёл все баги, разработчик их починил — можно расслабиться.

Подождите, не всё так просто. Нужно быть готовым к тому, что баги будут обнаружены не только во время разработки приложения, но и после релиза, то есть когда приложение появится в сторе — магазине приложений, например в App Store или Google Play.

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

6. А как баг может повлиять на работу приложения?

Зависит от такого, насколько этот баг серьёзен. Условно ошибки, которые выдаёт приложение, можно разделить на три вида: критические, значительные и несущественные.

Критические баги мешают человеку использовать приложение. Они блокируют основную функцию приложения и не дают ему работать на бизнес-цель клиента. Значительные баги для бизнес-цели не опасны, но они могут доставлять человеку неудобства в использовании приложения. А несущественные баги — это мелкие нарушения, которые пользователь не может заметить. Вот так это выглядит на примере приложения-магазина:

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

7. И что делать, если в моём приложении произошла ошибка?

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

8. Хорошо, значит критический баг починят первым?

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

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

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

9. Значит я могу не бояться багов?

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

10. А если я передам приложение на поддержку другой команде?

Чинить чужие баги сложнее. Дело в том, что чем дольше разработчики работают на конкретном проекте, тем глубже они погружены в его контекст и тем быстрее сориентируются, если обнаружат ошибку. Новым разработчикам придётся изучать всё с нуля. Но опытная команда, в которой налажена коммуникация и рабочие процессы, может быстро понять новый проект. Если вы ищете студию мобильной разработки на поддержку — звоните +7 495 204-35-03 или пишите нам. Спасать ваше приложение от ошибок — наша работа.