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

в 9:46, , рубрики: skillbox, баги, Блог компании Skillbox, обучение, отладка, поиск багов, Программирование, Учебный процесс в IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наблюдение

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

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

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

Анализ

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

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

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

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

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

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

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

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

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

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

Гипотезы

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

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

Автор: skillbox

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js