| netlib.narod.ru | < Назад | Оглавление | Далее > |
К сожалению, большинство многообещающих разработчиков игр пропускают предыдущие фазы и переходят прямиком к разработке. Хотя для нас, программистов, процесс разработки наиболее интересен, это не первый этап, необходимый для успешного игрового проекта. Обратите внимание, что ключевое слово в последнем предложении: успешного.
Очевидно, что в течение фазы разработки вы разрабатываете игру. Хотя вы и знакомы с этой фазой. возможно, вы упустили из виду следующие ключевые моменты:
Поверьте мне, я не фанат контроля. Возможно, я поклонник контроля или даже повелитель контроля, но точно не фанат. Контроль исходных текстов подразумевает помещение вашего исходного кода в виртуальную библиотеку на все время процесса разработки. При каждом серьезном изменении или обнаружении ошибки, вы получаете ваш код из библиотеки, меняете его и помещаете обратно. Каждый раз, когда вы получаете код, а затем помещаете его обратно, автоматически создается новая ревизия. Благодаря этому методу вы можете вернуться назад во времени, чтобы увидеть предыдущие версии вашего кода. Это очень полезное средство!
Делали ли вы когда нибудь изменение в стабильном коде только чтобы обнаружить, что оно привело к появлению ошибки или к нестабильности? Если да, то возврат к предыдущей версии и вычисление, какие изменения привели к возникновению проблем, может быть действительно болезненным. Используя контроль версий, вы можете получить старый код, проверить его и вычислить где появилась ошибка. Это дает как минимум отправную точку для последующих поисков. Кроме того утилиты, такие как WinDiff, позволяют вам сравнивать две версии кода и точно видеть различия между ними. Это неоценимо!
На рынке существует множество программ, которые помогут вам в организации контроля исходного кода. Наиболее попуярной из тех, которые я видел до настоящего времени, является CVS. Чтобы увидеть ее в действии, посетите сайт www.sourceforge.net. На SourceForge.net существуют тысячи проектов с открытым исходным кодом, которые вы можете посмотреть. Там есть даже свободно распространяемые стратегические игры и игровые библиотеки! Информацию о CVS можно получить на сайте www.cvshome.org.
Благодаря управлению метками вы можете получать преимущества от ясно помеченных ревизий исходного кода. Достигнув какой либо вехи в разработке, вы сохраняете весь ваш код и назначаете ему метку. Это позволяет вернуться назад и проверить все различные версии кода, требуемые для построения программы в какой-либо контрольной точке. Обратите внимание на следующие два файла:
Main.cpp
Версия 1.4
Версия 1.3
Версия 1.2
Версия 1.1
Версия 1.0
Main.h
Версия 1.2
Версия 1.1
Версия 1.0
Если теперь я попрошу вас выбрать код для бета-версии, какие файлы вы предложите? Вы можете взять самые последние версии файлов, но что, если они были написаны уже после выхода бета-версии? Без меток у вас нет никакого способа получить необходимую информацию, если только вы не решите создавать документ с номерами версий в каждой контрольной точке. Вы можете представить себе записывание версий нескольких тысяч файлов? Как можно предположить, это большая трудность. Теперь взгляните на те же самые два файла с метками:
Main.cpp
Версия 1.4
Версия 1.3 BETA
Версия 1.2
Версия 1.1
Версия 1.0
Main.h
Версия 1.2 BETA
Версия 1.1
Версия 1.0
Только взгляните на это! Возле тех файлов, которые использовались при создании бета-берсии стоит метка BETA. Все, что вам теперь остается сделать — выбрать исходный код с меткой BETA. К счастью программное обеспечение для контроля исходного кода позволяет снабжать код меткой или номером ревизии, так что для вас все автоматизировано. Вы должны также отметить насколько важны метки с точки зрения стабильности. Если бы для постройки бета-версии вы взяли бы самые последние файлы, у вас оказался бы выбран неправильный файл Main.cpp. Это могло бы вызвать огромные проблемы во всем проекте. Вышеупомянутый пример проиллюстрирован на рис. 4.2.
Рис. 4.2. Версии и метки исходного кода
Предположим, во время игры вы обнаружили ошибку в вашем коде. Что делать дальше? Вместо того, чтобы сразу исправлять ее, вам необходимо ввести данные о ней в систему отслеживания ошибок. Зачем? Использование программ отслеживания ошибок приносит много выгод. Основные из них — отслеживание, привязка к исходному коду и метрики качества.
Наиболее очевидную выгоду приносит отслеживание само по себе. Объединенный список ошибок позволяет вам видеть каждую проблему, которая проявилась в ходе разработки. Это весьма полезно, поскольку вы можете вернуться назад и просмотреть любую ошибку, с которой столкнулись ранее. Вы можете воспользоваться этой информацией, чтобы не повторить те же самые ошибки в своем следующем проекте.
Отслеживание также полезно, чтобы не забыть устранить ошибку. Во время разработки вы можете сколкнуться с проблемами, которые сочтете несущественными. Конечно, они не приведут к краху игры, но они также должны быть устранены! Лучший способ помнить о необходимости их устранения заключается в том, чтобы ввести информацию в систему отслеживания ошибок. Большинство систем отслеживания ошибок позволяет вам указывать серьезность ошибки. Это позволяет располагать ошибки по их приоритетам, чтобы сначала работать над наиболее серьезными, а потом перейти к менее серьезным.
Еще одно преимущество отслеживания заключается в том, что другие пользователи или команды могут вводить в систему отслеживания данные об обнаруженных в вашем программном обеспечении ошибках. Это позволяет команде тестирования сообщать об обнаруженных в вашей игре ошибках без необходимости приезжать к вам и отчитываться лично. Даже если вы одинокий разработчик, я настоятельно рекомендую отслеживать собственные ошибки.
Большинство пакетов отслеживания ошибок позволяют связывать ошибку с исходным кодом. Это полезно в мире контроля исходного кода, так как библиотекарь исходного кода может определить, какой исходный код должен быть помечен как требующий исправления ошибок.
Одно из преимуществ наличия истории ошибок состоит в том, что на основании исторического архива вы можете создавать метрики качества. Вы можете вернуться во времени и увидеть, где было обнаружено больше всего ошибок. Была ли большая часть ошибок найдена во время тестирования? Или они были обнаружены в бета-версии? А может они были обнаружены во время производства? Ответив на эти вопросы вы сможете обнаружить дыры в ваших стандартах качества и попытаться устранить их. Если большая часть ошибок была обнаружена во время тестирования, попытайтесь выяснить, почему разработчики отправляют тестировщикам код, который содержит так много ошибок. Если большинство ошибок найдено в бета-версии, необходимо установить, почему тестировщики пропустили их. Если большинство ошибок обнаружено во время производства, вы должны выяснить, почему их пропустила команда, выпускающая бета-версию. Хуже всего, когда ошибка достигает фазы производства. Устранение ошибок на этом этапе может обойтись вам очень дорого.
Суть в следующем: метрики качества позволяют изолировать узкие места в вашем цикле тестирования и отслеживать вносимые усовершенствования.
Я не могу достаточно подчеркнуть, насколько важно тестирование отдельных частей. Тестирование частей — это испытание разработчиком его собственного изделия. Перед тем, как отправить игру команде тестировщиков, разработчики, как предполагается, проверяют ее самостоятельно. Мой лучший совет — проверьте ваш код полностью! Вы не должны передавать код тестировшикам, если в нем есть любыне известные серьезные ошибки. Если это все-таки приходится делать, удостоверьтесь, что все известные ошибки вам задокументированы.
Лично я руководствуюсь следующими принципами, прежде чем передаю свой код в тестирование:
Многопоточная часть может не применяться в вашей разработке. В действительности все зависит от того, что вы пишете. Не следуйте перечисленным правилам буквально, а используйте их для идей, применимых в вашем собственном процессе.
Суть в следующем — код, передаваемый вами тестировщикам, должне быть надежен как скала. Если он не настолько надежен, зачем вы передаете его?
| netlib.narod.ru | < Назад | Оглавление | Далее > |