Ликвидировать нужно не баги, а причину их появления: кейс от разработчика игр
От переводчика: сегодня публикуем для вас статью опытного геймдев-тестировщика Ричарда Тейлора. Статья будет полезна как начинающим, так и опытным разработчикам, — обсудить тут точно есть что.
Я создал множество игр. Обычно завершающий этап разработки весьма болезненный. Ведь именно в конце мы сталкиваемся с багами, и лишь после этого можно уже окончательно наводить лоск на продукт. Ситуация ухудшается, когда у разработчика есть минимум времени на завершение проекта. Работать приходится быстро, и баги в этом случае — частые гости. Как можно справиться с ними? Очень просто: допускать меньше ошибок, только и всего (это ирония автора — примечание переводчика).
Skillbox рекомендует: Двухлетний практический курс «Я — Веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Снижаем количество багов
Поскольку все баги — в коде, то, наверное, просто достаточно попросить команду разработки допускать меньше ошибок?
Если вам смешно в этом месте, я не удивлюсь. И действительно, ведь никто (ну или практически никто) не совершает их по собственной воле. Так что же можно предложить команде, чтобы она делала меньше ошибок в коде, с тем, чтобы в нем не было багов?
Начинаем новый проект. Шаг первый — не повторяем предыдущих ошибок
Наша команда работала над несколькими ААА-проектами. Перед тем, как начать один из них, мы решили провести брейнсторминг на тему «Как допустить минимальное количество ошибок». Никто из нас не хотел провести последние пару месяцев работы над проектом в поиске багов и зачистке кода. Одна из основных задач — распределение ответственности и обязанностей. Каждому типу работ был назначен старший.
Шаг первый — определиться, зачем все это нужно. «Зачем» верхнего уровня объясняется просто: мы хотим снизить количество времени, требуемого на ликвидацию багов, оптимизировать затраты и повысить общее качество проекта.
Речь идет о том, чтобы освободить время на выполнение интересных задач, тех, что позволяют радостно просыпаться утром и тут же браться за реализацию таска. Это то, что сделало нас всех разработчиками — возможность использоваться свое время на по-настоящему крутые штуки!
Кстати, даже если есть четкая задача создавать меньше багов, она настолько общая, что может быть попросту бессмысленной. Это заявление о намерении, которое необходимо уточнить и разбить на ряд четких заданий, адресованных отдельным членам команды.
Отвечая на вопрос, как это сделать, необходимо следовать основам научного метода: наблюдение, гипотеза, тест, повторение.
Наблюдение
Категоризация
Откройте базу данных багов вашего последнего проекта и просмотрите ее. Разновидностей багов много, так что просто сказать: меньше ошибок — попросту бесполезно.
Для того, чтобы лучше разобраться в вопросе, нужно определиться со спецификой. Снизить нужно в первую очередь количество тех проблем, на обнаружение и решение которых нужна прорва времени.
Анализ
После составления списка самых трудоемких багов следующий шаг — попытка найти общее в этих ошибках, а также понять причину их появления. Анализируйте и интерпретируйте!
Причина проблемы
В конечном итоге мы создали ряд шаблонов для поиска специфических багов, что позволило понять, почему их поиск и ликвидация съедает столько времени. После этого мы были готовы перейти к исходному коду для поиска первопричины проблемы.
Работая с техническими специалистами, мы обнаружили больше fix changes. Затем составили новые списки систем, файлов и строк кода, связанных с крупными багами. В итоге мы сделали список необходимых изменений кода, который можно было обсудить с командой разработчиков.
Мы же вам говорили!
Затем мы провели встречу вместе с программистами для того, чтобы обсудить наши находки. Как оказалось, ребята знали о большинстве проблемных мест в коде. Но если это так, какой смысл был в том, чтобы проводить встречу?
Ответ: у нас получилось провести параллель между конкретными местами кода и временными потерями, связанными с этими проблемами. А это, в свою очередь, дало возможность объективно оценивать любое предложение по обслуживанию кода.
Таким образом, мы пересмотрели участки кода, которые можно было назвать приемлемо плохими. Когда мы оценили их с нашими наработками в руках, оказалось, что нужен рефакторинг. При этом инженерная команда ранее отказалась от него потому, что «работы слишком много» или «это попросту невозможно».
В самом деле, многие проблемы были системными. Многие «невидимые» аспекты приводили к цепочке событий, которые обусловливали появление ошибки. К слову, причины проблем были настолько системными, что проект пришлось начинать практически с нуля.
В итоге у нас накопилось достаточно результатов эмпирических наблюдений и анализа для того, чтобы сформировать гипотезы. В этом процессе принимала участие вся команда.
Гипотезы
Гипотеза 1. Специфические паттерны кодинга, вероятно, приведут к появлению багов в крупном программном проекте.
Гипотеза 2. Время, которое требуется на исправление ошибок в проекте, можно сократить, если избежать шаблонов поведения, определенных в первой гипотезе.
Давайте определимся с тем, что такое большой проект. Это около 25 программистов, 12 месяцев разработки. Для него справедливы следующие утверждения:
А. Любой код будет жить достаточно долго, так что стоимость обслуживания в итоге превысит стоимость самой разработки.
Б. Сложность соединения отдельных систем проекта выше, чем сложность конкретно взятой системы.
Почему это так важно? В небольших проектах вы можете справиться практически со всем, здесь программная структура не так важна. Код весь в вашем распоряжении.
Если проект большой, то все меняется. Вы можете работать с кодом, назначения которого вы не понимаете, можно даже не знать, к какой части проекта относится определенный участок.
После нашего обсуждения мы получили вот такую формулировку результатов: «Данные показывают, что эти конкретные шаблоны программирования были общим фактором, связанным с различными багами/проблемами. Мы считаем, что избегая этих паттернов, сможем сократить время, которое тратится на исправление ошибок, и одновременно улучшить качество».
Теперь приступаем к практической реализации.
Тестирование
При создании нового проекта необходимо избегать идентифицированных паттернов багов. У нас это были:
- Перегрузка операторов и неудачное именование.
- Auto, полиморфные функции и пренебрежение типобезопасностью.
- Увеличение сложности кода путем, например, внедрения зависимостей и обратных вызовов.
- Использование мьютексов, семафоров и тому подобного в высокоуровневом коде.
Что дальше?
А дальше у нас появилась возможность начать новый проект, разработку новой игры. Мы смогли создать игровой движок с нуля и завершить все в срок, причем относительно небольшой командой программистов. Багов было немного, а код получился хорошим. При этом времени на его обслуживание потребовалось немного.
Все это стало возможным, потому что мы не использовали проблемные паттерны, как будто их и не существует больше. У нас даже появилась мантра «Усложни появление ошибки».
Вся команда была рада таким результатам, работать стало интереснее, ведь снова стало возможным тратить время на то, что тебе нравится.
Skillbox рекомендует:
