Комментарии к статье

Обзор лучших
agile-практик применительно к разработке игр

Михаил Дубаков из TargetProcess и Вадим Гайдукевич из Wargaming.net рассказывают о применении в геймдеве практик, связанных с гибкой разработкой ПО. В обзорной статье рассматриваются следующие методики: итеративная разработка, юнит тестирование, разработка через тестирование, рефакторинг, парное программирование, постоянная интеграция.
+9
Отправлено 15.08.2007 в 21:23
Отвечает на сообщение 213086
+1
Комм: Обзор лучших agile-практик применительно к разрабоке игр
Статья неплохая. Таких нужно больше. И подробнее.
Естественно, она не идеальна, критиковать есть что. ;-)
Но не буду, хотелось бы в комментариях пообсуждать некоторые вещи из реальности...

Для начала - несколько ссылок:

Extreme Programming Explained (Экстремальное программирование)
http://www.piter.com/book.phtml?978594723032
"Библия XP" (да и вообще как букварь в Agile - стоит её читать первой)

Extreme Programming Applied: playing to win (Экстремальное программирование: постановка процесса. С первых шагов и до победного конца)
http://shop.piter.com/book.phtml?978531800132
масса интересного из реальной жизни - попытки внедрения и трудности

Agile на коленках
http://m-bykov.livejournal.com/1711.html
понравилось про Tipa Agile Development

Дальше будут вопросы:
- Как донести ЭТО до команды?
- Где взять команду, которая готова воспринять ЭТО?
- Что делать, если представители делают заявления в стиле "Нас всё устраивает, мы по другому не умеем и не хотим учиться новому"?
- Где взять [...], знающий преимущества Agile?
- ...?
- ...?

короче,
- КАК СОБРАТЬ ТАКУЮ КОМАНДУ, ДЕЛАЮЩУЮ УСПЕШНЫЕ ПРОЕКТЫ? :-)

p.s. надеюсь, смысл вопросов понятен ;-)

p.p.s. вообще подумал - имеет смысл сделать цикл статей по мотивам этой, с более подробным разбором каждой практики: пусть они будут маленькие - по одной-две страницы, но чтобы очень подробно разобрано...
А то, честно говоря, не понятно из введения и заключения - о чём это вообще: ведь всё гибкое придумано для того, чтобы сделать заказчика счастливым. "Покупатель должен уходить из магазина не просто купившим товар, а счастливым!" (с) кто-то западный...
Отправлено 15.08.2007 в 22:13
Отвечает на сообщение 213087
0
Евгений Белоглазов wrote:
> - Как донести ЭТО до команды?


Простыми, четкими директивами.

> - Где взять команду, которая готова воспринять
> ЭТО?


Создать самостоятельно.

> - Что делать, если представители делают заявления
> в стиле "Нас всё устраивает, мы по другому не
> умеем и не хотим учиться новому"?


Увольнять.

> - КАК СОБРАТЬ ТАКУЮ КОМАНДУ, ДЕЛАЮЩУЮ УСПЕШНЫЕ
> ПРОЕКТЫ? :-)


Ты определись: тебе таки успешные проекты или таки внедрение agile?
fil
Отправлено 16.08.2007 в 09:00
Отвечает на сообщение 213090
+1
> Простыми, четкими директивами.
> Создать самостоятельно.
> Увольнять.


Да ладно!

не верю
Andrew Aksyonoff  16.08.2007 10:31
fil  16.08.2007 21:28
Andrew Aksyonoff  16.08.2007 21:49
В ветке ещё 93 сообщения
Alexey Vlasov  16.08.2007 12:43
fil  16.08.2007 21:27
Отправлено 15.08.2007 в 21:44
Отвечает на сообщение 213086
0
Re: Обзор лучших agile-практик применительно к разрабоке игр
Так, попробуем для завтравки осилить несколько замечаний

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

Возможно, есть. А есть и печальный факт, что 80% работы делается за 20% времени. А вот оставшиеся 20% занимают все остальное время. Причем я знаю очень немного грамотных менеджеров, которые подобный факт могут предвидеть и грамотно спланировать.

> Снижается время и стоимость исправления каждого дефекта
> за счет раннего тестирования. Увеличивается
> предсказуемость проекта и сроки его завершения.

Если в тестирование включаются стресс-тесты на финальном уровне (пусть даже и со вставленными "болванами"), то есть шансы получить какую-то предсказуемость. На практике у многих команд, практикующих Agile методики, наблюдаются грандиозные проблемы с производительностью проекта, вплоть до откатывания на самое начало разработки в тот момент, когда кажется, что релиз уже близок.

Вообще следует отметить два немаловажных момента, которые не всегда договаривают:
1. Наличие коротких итераций совершенно не исключает необходимости грамотного водопадного планирования общей архитектуры и идеологии системы. Наоборот, без опытного руководителя, который может направить вектор развития системы в правильном направлении agile становится более опасным и непредсказуемым, чем тяжелые методики.
2. Agile очень хорош для проектирования бизнес приложений, но не для приложений реального времени, к которым относятся и большинство компьютерных игр

Далее по тексту.
Тестировать можно и нужно. Но не надо ставить это во главу угла и полагаться только на них. Потому что даже в вашем примере "Сделать таблицу рекордов..." допущено несколько ошибок, которые не проверены тестами. например, "topscore.sav располагается в каталоге ОС, который доступен пользователю с ограниченными правами".
Юнит тесты тоже имеют несколько нюансов. Если мы делаем func(2,2), которая должна давать результат 4, то конечно можно написать на это тест. Но есть еще например граничные варианты func(3,0), где возвращается 0, а также запрещенные вызовы func(-1, -1), при которых тоже возвращается 0.
После рефактора func(2,2) остается равным 4 (естественно, ведь это - правильное предсказуемое поведение функции). А вот func(3,0) стало возвращать 3, а func(-1, -1) теперь падает.
Отсюда есть несколько аспектов:
а) писать unit tests для правильных значений конечно же надо
б) писать unit tests для проверки поведения на граничных значениях надо еще тщательнее, так как именно она чаще всего изменяется при рефакторе и именно она приводит к удивленным возгласам "а как оно вообще когда-то работало"???
в) писать unit tests для проверки поведения на запрещенных значениях надо еще тщательнее, причем требуется интеграция системы unit tests с вашими механизмами ассертов, с контролем AV и т.п. приблудами.
Все это сильно увеличивает объемы юнит тестов, а без вариантов а и б сильно снижается их эффективность.
И последнее про Unit tests. Ими надо пользоваться разумно - нет нужды проверять 2*2=4 - это можно доказать видуальным анализом кода.
Примеду простой пример: на GDC в прошлом году одна команда, горячие поклонники TDD, рассказывали как все у них круто. В качестве примера приводили процесс разработки класса Shield, в котором value может меняться от 0 до 100. Далее делали тесты на set/get, добавление и удаление армора и типа доказали, что value не может принимать значения < 0 и больше 100. Но! При помощи конструктора shiled(int value) можно было занести в него отрицательное значение и оно нигде не проверялось! Вопрос: какой смысл в 5700 написанных тестов?

Про рефакторинг ничего говорить не буду. Ведущие программисты на последнем открытом форуме КРИ спорили про плюсы и минусы рефактора. Вроде даже аруслан смог убедить присутствующих в опасности увлечением рефактора. "Простой и легко читаемый код" в следующей итерации запросто превращается в кровавое месиво.

Заключение.
Agile методики хороши. В них есть огромное количество плюсов. Например, планирование итерациями действительно сильно удобнее для геймдева, нежели тяжелые диаграммы MS Project. При этом должно быть общее грамотное планирование на проект, а не на итерацию. Рефактор не должен противоречить глобальному планированию. Unit tests тоже необходимы, но в меру.
Использовать разные подходы Agile - безусловно можно и нужно. Но брать необдуманно полный список перечисленных методологий и внедрять их на проекте - крайне безрассудный подход.
Отправлено 15.08.2007 в 22:18
Отвечает на сообщение 213088
0
dDIMA wrote:
> можно и нужно. Но брать необдуманно полный список
> перечисленных методологий и внедрять их на проекте
> - крайне безрассудный подход.


Пропущено слово "все"
Отправлено 15.08.2007 в 22:20
Отвечает на сообщение 213091
0
> Пропущено слово "все"
да да, точно.
Извините, был напуган (Ц)
Отправлено 15.08.2007 в 23:28
Отвечает на сообщение 213088
0
> Так, попробуем для завтравки осилить несколько замечаний

Кстати...
Мне кажется, что зацикливаться именно на Agile не стоит, т.к. правда одна - "у Соломона" (с)...
Вообще лучше представлять себе всякое: от МакКоннелла и Спольски до Демарко и Листера. А выбирать что именно подойдёт в конкретной ситуации - это дело тех. лида.
А вообще - практически любое Agile подразумевает периодическое process review, на котором неработающее - адаптируется чтоб работало или выкидывается, более подходящее - внедряется, так что оптимально что-то "типа Agile" = Tipa Agile Development из третьей ссылки первого моего коммента ;-)

p.s. У Спольски есть на эту тему... Про "5 миров"...
Отправлено 16.08.2007 в 00:47
Отвечает на сообщение 213097
0
Евгений Белоглазов wrote:
> Мне кажется, что зацикливаться именно на Agile не


Зацикливаться вообще ни на чем не стоит.
Отправлено 17.08.2007 в 02:48
Отвечает на сообщение 213088
0
> 1. Наличие коротких итераций совершенно не исключает
> необходимости грамотного водопадного планирования общей
> архитектуры и идеологии


Eto imho po umolchaniu. Nazivaetsya preproduction :)

> 2. Agile очень хорош для проектирования бизнес
> приложений, но не для приложений реального времени, к
> которым относятся и большинство компьютерных игр


Eto pochemu ? Vot pro unit tests ya soglasen chto oni v printsipe ne osobo nuzhni i ne pomogaut. A iterativnoe planirovanie ( ie sprints ) pri nalichie high level plana - ochen pravilnaya vesch schitau.
Отправлено 17.08.2007 в 09:26
Отвечает на сообщение 213226
0
Сергей Титов wrote:
> Eto pochemu ? Vot pro unit tests ya soglasen chto
> oni v printsipe ne osobo nuzhni i ne pomogaut. A
> iterativnoe planirovanie ( ie sprints ) pri
> nalichie high level plana - ochen pravilnaya
> vesch schitau.

ПЛАНИРОВАНИЕ - должно быть итеративное, не спорю.
А вот итеративное ПРОЕКТИРОВАНИЕ системы  может крайне плохо сказаться на окончательном результате. То есть даже на ранних этапах разработки надо представлять себе, что у нас может получиться в конце (с точки зрения технологии).
Сергей Титов  17.08.2007 09:30
Alexey Vlasov  17.08.2007 12:29
В ветке ещё 104 сообщения
Отправлено 16.08.2007 в 01:40
Отвечает на сообщение 213086
0
Не знаю почему, но мне приверженцы ХР, с которыми доводилось общаться почему то напоминают свидетелей игровых,
может из-за формы подачи материалов (типа юзай ХР и все сразу станет афигенно):)

Если честно я не так уж много читал о этой методологии разработки, всего пару книг + какие-то статьи и обсуждения на форумах, но почему то ни где не приводят примеры реальных продуктов при разработке которых была бы использована эта методология. Особенно это касается игр, интересно есть ААА да еще что бы под несколько платформ?

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

А так, до сих пор и не представляю как использовать техники ХР в геймдеве.

Вот например пресловутые юнит тесты. Могу себе представить только как обернуть ими например мат либу,
только зачем, она и так нормально работает, а если вдруг не работает, то посмотрю по соурс контролю последние изменения, если выясниться что никогда нормально не работала - то ошибку будет найти всеравно не трудно - допустим 1 час отладки, такие ситуации/ошибки (в мат либе или каких-то других базовых вещах) достаточно редки и смею даже предположить что время что бы найти и исправить ошибки суммарно будет меньше чем суммарное время прогонки юнит тестов, и для таких вещей асертов хватает за глаза. Понятно что хочется знать что код систем и модулей более высоких уровней функционирует правильно, как этого добиться? На вашем примере все просто, но как правило в реале все сложнее, создание того же юнита ведет к созданию и инициализации многих систем и подсистем (мне каждый раз ждать прогона всех их тестов?), многие неправильные ситуации в игровой логике как правило происходят при определенных и достаточно редких условиях, их нужно смоделировать что бы проверить правильность работы кода, получается что нужно создавать специфичные игровые уровни и пр. а потом их поддерживать? Как быть с тестированием
чего-то чью неправильную работу можно заметить на экране монитора (мертвый персонаж "прирегдолился" к стене), или понять (по логам или опять же визуально) что произошла ошибка после N минут после начала исполнения и при возникновении определенных условий? Как гарантировать правильность работы, простоту, поддержку тестов для многопоточного кода? Тоже самое для кросплатформенного кода (особенно актуально в условиях нехватки девкитов, и возможности проверить и отладить тесты). Если ответ "никак", то получается что всегда будет тестироваться тот код который как правило и так всегда работает. И опять же, код часто и так загрязнен всевозможными ассертами и чеками, #ifdef'ами, профайл кодом и платформ-специфик кодом, и тут еще добавлять юнит тест код.

По другим техникам тоже много вопросов по их применению в геймдеве.
Отправлено 16.08.2007 в 08:51
Отвечает на сообщение 213104
0
Алексей Иванов wrote:
>
> Не знаю почему, но мне приверженцы ХР, с которыми
> доводилось общаться почему то напоминают
> свидетелей игровых,


Возможно, Свидетелей Иеговы? ;-)

> может из-за формы подачи материалов (типа юзай ХР
> и все сразу станет афигенно):)


Ну надо читать не про их фантазии, а про реальность. Например, моя вторая ссылка - про реальность: там порядка сотни примеров введения XP на практике.

> почему то ни где не приводят примеры реальных
> продуктов при разработке которых была бы
> использована эта методология. Особенно это
> касается игр, интересно есть ААА да еще что бы
> под несколько платформ?


Обычно это касается не игровых проектов. А игры чаще всего "делаются по методологии Crunch" (c)


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

Если не про игры, то типично - это разработка какой-нибудь внутренней системы силами 6-8 программистов в течение 6-12 месяцев. Если про игры, то мне тоже интересно ;)


> Вот например пресловутые юнит тесты. Могу себе
> представить только как обернуть ими например мат
> либу,
> только зачем, она и так нормально работает,

Unit test используются не совсем для тестирования, точнее - не только для тестирования. Они одновременно документируют поведение модуля или подсистемы.
Типично всё равно пишется код, чтобы проверить нетривиальные классы - часто в отдельных маленьких проектах. При Unit test'ах - этот же код пишется в едином проекте и прогрессирует вместе с развитием класса.
Ещё польза от UT - повышение уверенности в работоспособности модуля. (важно!)

> вещей асертов хватает за глаза. Понятно что
> хочется знать что код систем и модулей более
> высоких уровней функционирует правильно, как
> этого добиться? На вашем примере все просто, но
> как правило в реале все сложнее, создание того же
> юнита ведет к созданию и инициализации многих
> систем и подсистем (мне каждый раз ждать прогона
> всех их тестов?),

Для этого придуманы mock-объекты (см. wiki или т.п.).

> многие неправильные ситуации в
> игровой логике как правило происходят при
> определенных и достаточно редких условиях, их
> нужно смоделировать что бы проверить правильность
> работы кода,

Для этого есть тестовые уровни для определённых тестов.

> получается что нужно создавать
> специфичные игровые уровни и пр. а потом их
> поддерживать?

Да.

> Как быть с тестированием
> чего-то чью неправильную работу можно заметить на
> экране монитора (мертвый персонаж "прирегдолился"
> к стене), или понять (по логам или опять же
> визуально) что произошла ошибка после N минут
> после начала исполнения и при возникновении
> определенных условий?

Сложно ;)

> Как гарантировать
> правильность работы, простоту, поддержку тестов
> для многопоточного кода?

Для произвольного кода - никак не гарантировать. Модульные тесты - типично однопоточные.
Многопоточный код - часто это скорее Интеграционные, чем модульные. Или тесты подсистем...

> Тоже самое для
> кросплатформенного кода (особенно актуально в
> условиях нехватки девкитов, и возможности
> проверить и отладить тесты). Если ответ "никак",
> то получается что всегда будет тестироваться тот
> код который как правило и так всегда работает.

Да (см. выше про "повышение уверенности")

> И
> опять же, код часто и так загрязнен всевозможными
> ассертами и чеками, #ifdef'ами, профайл кодом и
> платформ-специфик кодом, и тут еще добавлять юнит
> тест код.

Они добавляются типично в отдельных каталогах отдельными файлами. Пример:
/project_root/src/class.cpp
/project_root/test/test_class.cpp


> По другим техникам тоже много вопросов по их
> применению в геймдеве.


Да, в статье тема не раскрыта (про применение в геймдеве)...
Отправлено 16.08.2007 в 12:54
Отвечает на сообщение 213109
0
Евгений Белоглазов wrote:


> Возможно, Свидетелей Иеговы? ;-)


Да, иеговы. Ошибся Ж)

> > может из-за формы подачи материалов (типа юзай
> ХР
> > и все сразу станет афигенно):)
>
> Ну надо читать не про их фантазии, а про
> реальность. Например, моя вторая ссылка - про
> реальность: там порядка сотни примеров введения
> XP на практике.


Да, почитаю. Хотя с бизнесс приложениями и так все представляется понятным.

> > почему то ни где не приводят примеры реальных
> > продуктов при разработке которых была бы
> > использована эта методология. Особенно это
> > касается игр, интересно есть ААА да еще что бы
> > под несколько платформ?
>
> Обычно это касается не игровых проектов. А игры
> чаще всего "делаются по методологии Crunch" (c)


Да, наверное пока самая эффективная технология :)
Отправлено 16.08.2007 в 09:05
Отвечает на сообщение 213104
0
Алексей Иванов wrote:

>  но
> почему то ни где не приводят примеры реальных
> продуктов при разработке которых была бы
> использована эта методология. Особенно это
> касается игр, интересно есть ААА да еще что бы
> под несколько платформ?


Я постараюсь уточнить у коллег, и назвать эти тайтлы. Они точно есть.



> Вот например пресловутые юнит тесты. Могу себе
> представить только как обернуть ими например мат
> либу,
> только зачем, она и так нормально работает, а
> если вдруг не работает, то посмотрю по соурс
> контролю последние изменения, если выясниться что
> никогда нормально не работала - то ошибку будет
> найти всеравно не трудно - допустим 1 час
> отладки, такие ситуации/ошибки (в мат либе или
> каких-то других базовых вещах) достаточно редки и
> смею даже предположить что время что бы найти и
> исправить ошибки суммарно будет меньше чем
> суммарное время прогонки юнит тестов, и для таких
> вещей асертов хватает за глаза.


Вообще говоря, Юнит Тесты должны были писаться до разработки МатЛибы. Это как минимум сократило бы время разработки и отладки. Кроме того, обезопасило любые исправления либы в будущем. Пост-фактум написание тестов для работающей либы - занятие не самое рациональное. Как вариант, тесты можно писать только к методам в которых
1. Найдена ошибка
2. Необходимо внести изменения
3. Новым методам


> Понятно что
> хочется знать что код систем и модулей более
> высоких уровней функционирует правильно, как
> этого добиться? На вашем примере все просто, но
> как правило в реале все сложнее, создание того же
> юнита ведет к созданию и инициализации многих
> систем и подсистем (мне каждый раз ждать прогона
> всех их тестов?),


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

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


Да, конечно. Иначе за вас эти исключительные ситуации сделает игрок, и потом будет названивать в службу поддержки/писать на форуме.

Кроме того, есть другие способы протестировать высокоуровневую логику, которую не всегда рационально протестировать ЮнитТестами.
Вот такой пример:
При разработке Massive Assault мы запускали на ночь АИ играть против АИ. При этом все ходы записывались. На следующий день человек просматривал все реплэи на предмет неадекватности поведения АИ. Как результат - АИ играет как живой человек :)


> Как быть с тестированием
> чего-то чью неправильную работу можно заметить на
> экране монитора (мертвый персонаж "прирегдолился"
> к стене), или понять (по логам или опять же
> визуально) что произошла ошибка после N минут
> после начала исполнения и при возникновении
> определенных условий?


Другими способами тестирования кроме Юнит Тестов.


> Как гарантировать
> правильность работы, простоту, поддержку тестов
> для многопоточного кода?


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



> Тоже самое для
> кросплатформенного кода (особенно актуально в
> условиях нехватки девкитов, и возможности
> проверить и отладить тесты). Если ответ "никак",
> то получается что всегда будет тестироваться тот
> код который как правило и так всегда работает. И
> опять же, код часто и так загрязнен всевозможными
> ассертами и чеками, #ifdef'ами, профайл кодом и
> платформ-специфик кодом, и тут еще добавлять юнит
> тест код.


Еще раз хотел бы обратить внимание, что юнит тесты пишуться до того, как пишеться код. В тесте вы создаете условия, которые проверяют работоспособность вашего кода. Вы создаете их один раз. В противном случае, вам придеться например несколько раз запустить игру и выставить тестовую сцену, чтобы убедиться что какие-то юниты могут загрузиться в транспорт, какие-то - нет, при этом ничего не падает и в транспорт помещается ровно столько юнитов сколько он вмещает, и они не разгружаются на головы друг-друга.
Отправлено 16.08.2007 в 10:06
Отвечает на сообщение 213113
0
Vadim Gaidukevich wrote:
> Вообще говоря, Юнит Тесты должны были писаться до
> разработки МатЛибы. Это как минимум сократило бы
> время разработки и отладки. Кроме того,
> обезопасило любые исправления либы в будущем.
> Пост-фактум написание тестов для работающей либы
> - занятие не самое рациональное. Как вариант,
> тесты можно писать только к методам в которых

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

Вообще иногда перечитывая правила TDD, появляется ощущение, что оно придумано исключительно для индусов. Была ситуация - проходя мимо компьютера, ловил за руку программиста, который 2 дня рефакторил систему, после этого запустил юнит-тест, он срубился, и программист уже собрался ревертить свои изменения.
Хотя с расстояния двух метров на мониторе была видна логическая ошибка в новом написанном им коде и достаточно было бы на 3 пункта более высокого IQ, чтобы понять причину неработоспособности.

Юнит-тесты должны быть подмогой для визуального логического анализа кода, но никоим образом не заменять его. Ничего хорошего из такой затеи не выйдет.
Отправлено 16.08.2007 в 12:34
Отвечает на сообщение 213113
0
Vadim Gaidukevich wrote:
>
> Я постараюсь уточнить у коллег, и назвать эти
> тайтлы. Они точно есть.


Да, было бы интересно узнать какие.

> Вообще говоря, Юнит Тесты должны были писаться до
> разработки МатЛибы. Это как минимум сократило бы
> время разработки и отладки. Кроме того,
> обезопасило любые исправления либы в будущем.
> Пост-фактум написание тестов для работающей либы
> - занятие не самое рациональное. Как вариант,
> тесты можно писать только к методам в которых
> 1. Найдена ошибка
> 2. Необходимо внести изменения
> 3. Новым методам


Здесь я хотел сказать что как правило различные базовые вещи пишуться и отлаживаются 1 раз,
ошибки в них (по крайней мере те, которые можно выявить с помощью юнит тестов) тоже как правило заметны
сразу, и сразу исправляются. Не очень понятно что мне дадут юнит тесты для таких вещей.


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


Опять же, если я меняю что то в базовой функциональности, мне необходимо тестировать весь зависимый от нее код.
Если все это зависит от специфичных входных данных для тестов (тех же тестовых уровней и сцен), мне прихдется
перепахивать их всех и т.д. Что займет время и обещает быть не таким интересным ;)

> Да, конечно. Иначе за вас эти исключительные
> ситуации сделает игрок, и потом будет названивать
> в службу поддержки/писать на форуме.


Я тут целиком полагаюсь на тестеров :)

> Кроме того, есть другие способы протестировать
> высокоуровневую логику, которую не всегда
> рационально протестировать ЮнитТестами.
> Вот такой пример:
> При разработке Massive Assault мы запускали на
> ночь АИ играть против АИ. При этом все ходы
> записывались. На следующий день человек
> просматривал все реплэи на предмет неадекватности
> поведения АИ. Как результат - АИ играет как живой
> человек :)


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

> > Как быть с тестированием
> > чего-то чью неправильную работу можно заметить
> на
> > экране монитора (мертвый персонаж
> "прирегдолился"
> > к стене), или понять (по логам или опять же
> > визуально) что произошла ошибка после N минут
> > после начала исполнения и при возникновении
> > определенных условий?
>
> Другими способами тестирования кроме Юнит
> Тестов.


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

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


Нет не могу, я не пишу пока юнит тестов. Можно навскидку придумать что то вроде:
есть код А который работает на 1 потоке, я пишу код Б которой работает на 2м потоке, как-то должен синхронизироваться с А,
хочется убедиться что у меня не будет например дедлоков из серии "1 раз в 100 лет" и пр. Получается что юнит тест может быть нетривиальным,
и быть сложным если А и Б большие и сложные подсистемы требующие специфичной инициализации и спецефичных входных параметров для тестов. Если А
изначально был заточен под работу в одном потоке и не тред сейв и я его соотвествующим образом модифицирую, то все его тесты становятся не
валидными, я должен их тоже соотвествующе модифицировать делать тред сейв и пр. и ошибка в них может стоить мне очень дорого (а вероятность
ее у меня возрастает), получается например что легко из за неправильной модификации теста посадить какой-нить мемори корапшен и отлаживать
потом это неделю.

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

Возможно что ошибаюсь, поэтому хотелось бы почитать об применении  всего этого дела (вообще ХР практик) при разработке игровых приложений, на реальных а не на гипотетических примерах.
Vadim Gaidukevich  16.08.2007 13:04
Алексей Иванов  16.08.2007 13:36
Vadim Gaidukevich  16.08.2007 14:41
В ветке ещё 10 сообщений
Отправлено 17.08.2007 в 09:23
Отвечает на сообщение 213104
0
Алексей Иванов wrote:
>
> Не знаю почему, но мне приверженцы ХР, с которыми
> доводилось общаться почему то напоминают
> свидетелей игровых,
> может из-за формы подачи материалов (типа юзай ХР
> и все сразу станет афигенно):)


А потому что сама система такая. Где главной функцией coach явялется покупка ЕДЫ (необходимо писать большими буквами). То есть в команду впихивают заряд положительных эмоций, чтобы они не грустили без чтения баша.
Отсюда и ответ на вопрос "Как уговорить команду принять XP" - уговоривать уже неверный вариант. Форма подачи должна быть такой, чтобы все поняли "Случится явление XP и всем станет круто", ну и ЕДЫ будет много (для России - ПИВА, за границой вроде ПИЦЦУ используют).

> Если честно я не так уж много читал о этой
> методологии разработки, всего пару книг +
> какие-то статьи и обсуждения на форумах, но
> почему то ни где не приводят примеры реальных
> продуктов при разработке которых была бы
> использована эта методология. Особенно это
> касается игр, интересно есть ААА да еще что бы
> под несколько платформ?


У Бека примеры приводятся. Про игры не видел.

> Вот например пресловутые юнит тесты. <...>


В Agile юни тесты служат суррогатом документации и переходный моентом между user story и code construction. Приведу в виде use case (специально приблизил к gamedev):
- Программист получает user story в виде "а ещё нам нужно реализовать алгоритм автоматической сортировки вещей в "рюкзаке" персонажа".
- П. получает сведения об реализации рюкзака и вещей (pair programming, стукание по аське, сканирование вики, изучение сорцов - не суть важно как) и начинает обдумывать алгоритм.
- П. определяет что алгоритм должен оставить прямоугольник широной с рюкзак и максимальной высоты, и заносит это условие в unit test (вместо документации). он может не делать этого сразу, а записать условие теста на бумажке, но реализовать перед завершением всех работ по реализации алгоритма.
- П. начинает реализацию алгоритма и думает не получится ли так, что алгоритм сломает существующее расположениее вещей в рюкзаке и не сможет вместить в него все вещи. Он пишет тест, где рюкзак заполнен почти полностью и проверяет влезут ли все вещи.
- П. уверен в тех частях алгоритма, которые ему очень сложно проверить "умственным интерпретатором" - ведь он написал на них тесты и алгоритм не завалил их.
- П. заканчивает алгоритм, окидывает его критическим взглядом и замечает граничные условия: вещи не влезают в рюкзак, в рюкзаке ничего нет, рюкзак полностью забит et cetera. (При большом опыте и культуре, часть условий будет замечена ещё до начала конструирования алгоритма).
- Спецификация алгоритма видна по набору тестов и может быть перенесена в документацию (но всем этого делать не хочется).

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

Ещё одна очень важная особенность - unit test fail должен сообщать об ошибке именно в этом куске кода. После чего должна быть исправленна ошибка для соответсвия с тестом. Правильность тестов должна подвергатся сомнению в последнию очередь (они же документация!) и должно требоваться полное прохождение всех тестов. Тут можно даже прийти к нарушению практики "совместного владения" и ввести ограничения на правку тестов рядовыми разработчиками.

Тут не удержусь от критики и проедусь по unit testes из статьи (поскольку тесты должны сообщать о локализации ошибки в юните):

Правильный Distance тест (также исправил неоднозначность имён методов):

UNIT_TEST DistanceTest()
{
LoadTestScene("TestScene1.scn");
Unit * tank = PutUnit(TANK, 10, 10); //ставим танк на сушу
Unit * boat = PutUnit(BOAT, 20, 20); //а корабль в море

TEST_EQUAL(tank->Distance(11, 11), map->GetTerrain(11,11).Passability()); //на соседнюю клетку за ход
TEST_EQUAL(tank->Distance(20, 20), NoWay); //в море - никогда
TEST_EQUAL(tank->Distance(15, 15), 6 * map->GetTerrain(15,15).Passability()); //а по лесу едем очень медленно (подоразумевается конкретный маршрут, заносим вычисление затрат по нему)
TEST_NOT_EQUAL(boat->Distance(30, 20), NoWay); // Корабль плавает по морю
TEST_EQUAL(boat->Distance(10, 10), NoWay); // а по суше плыть не хочет

tank->SetXY(1, 1);
TEST_NOT_EQUAL(tank->Distance(127, 127), NoWay); //зато танк может проехать всю карту
по диагонали, но не быстро
TEST_EQUAL(tank->Distance(-1, -1),  NoWay); //Интересно, упадет ли тест если отправить
танк за границу...
}

Про ExperienceTest: вряд ли цель этого теста была в проверки правильности формулы расчёта опыта. Потому IMHO считаю, что это функциональный ("мы действительно можем использовать метод и не вбивать ручной расчёт опыта?") или интеграционный ("не сломалось ли чего при взаимодействии") тест.
Отправлено 17.08.2007 в 10:30
Отвечает на сообщение 213247
0
Михаил Певзнер wrote:

> А потому что сама система такая. Где главной
> функцией coach явялется покупка ЕДЫ (необходимо
> писать большими буквами). То есть в команду
> впихивают заряд положительных эмоций, чтобы они
> не грустили без чтения баша.
> Отсюда и ответ на вопрос "Как уговорить команду
> принять XP" - уговоривать уже неверный вариант.
> Форма подачи должна быть такой, чтобы все поняли
> "Случится явление XP и всем станет круто", ну и
> ЕДЫ будет много (для России - ПИВА, за границой
> вроде ПИЦЦУ используют).


IMHO bullshit. "Втирают" процессы скорее приверженцы RUP, чем Agile.

> Видны минусы (о части уже сказали):
>  - Ошибки в тестах страшны.

Ошибки везде страшны.

>  - Документация всё равно круче для конечного
> пользователя.

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

>  - Неясности в задаче программист решает сам и не
> документирует.

Проблема организации. В непонятных местах можно и комментарий строчек на 5 написать, в том числе и в UT. Т.к. поддерживать потом это всё надо...

>  - Требует высокой культуры программирования,
> чтобы задумываться о правильности своего кода.

Её либо нету; либо есть; либо нету, но со временем будет.
Отправлено 18.08.2007 в 02:11
Отвечает на сообщение 213247
0
Михаил Певзнер wrote:
> В Agile юни тесты служат суррогатом документации
> и переходный моентом между user story и code
> construction. Приведу в виде use case (специально
> приблизил к gamedev):
>  - Программист получает user story в виде "а ещё
> нам нужно реализовать алгоритм автоматической
> сортировки вещей в "рюкзаке" персонажа".
>  - П. получает сведения об реализации рюкзака и
> вещей (pair programming, стукание по аське,
> сканирование вики, изучение сорцов - не суть
> важно как) и начинает обдумывать алгоритм.
>  - П. определяет что алгоритм должен оставить
> прямоугольник широной с рюкзак и максимальной
> высоты, и заносит это условие в unit test (вместо
> документации). он может не делать этого сразу, а
> записать условие теста на бумажке, но реализовать
> перед завершением всех работ по реализации
> алгоритма.
>  - П. начинает реализацию алгоритма и думает не
> получится ли так, что алгоритм сломает
> существующее расположениее вещей в рюкзаке и не
> сможет вместить в него все вещи. Он пишет тест,
> где рюкзак заполнен почти полностью и проверяет
> влезут ли все вещи.
>  - П. уверен в тех частях алгоритма, которые ему
> очень сложно проверить "умственным
> интерпретатором" - ведь он написал на них тесты и
> алгоритм не завалил их.
>  - П. заканчивает алгоритм, окидывает его
> критическим взглядом и замечает граничные
> условия: вещи не влезают в рюкзак, в рюкзаке
> ничего нет, рюкзак полностью забит et cetera.
> (При большом опыте и культуре, часть условий
> будет замечена ещё до начала конструирования
> алгоритма).
>  - Спецификация алгоритма видна по набору тестов
> и может быть перенесена в документацию (но всем
> этого делать не хочется).


Это понятно, так же как про документирование и спецификации, тут мне особо нечем возразить,
кроме как а нужно ли это вообще, т.к. везде где я работал доков и спеков не писали (не спорю что это плохо)
однако как то жили и как то вполне успешно работали. Плюс опять же большинство игровых объектов часто отнаследованы от какого-нить CGameObject, у которого есть виртуальные
virtual bool OnInit(...);
virtual bool OnUpdate(...);
virtual bool OnTerm(...);
т.е. при знании примерной архитектуры движка знаешь куда лезть и где смотреть.

Приведенный пример с рюкзаком думаю ломаться будет крайне редко, а если сломается ошибку будет легко найти и без тестов, пусть хоть и не сразу после модификации кода (прибегут тестеры/художники/скриптеры и т.д., и все популярно объяснят :). А вот ошибки из серии художник что то не так намоделил (пивот засунул не туда, бибокс не так нарисовал) будут довольно частыми и в билде рюкзак правильно работать не будет, а тестер придет ко мне, что я ему скажу, "мои код ЮТ проходит, идите в сад"? Врядли, буду сидеть и разбираться в чем дело. Или вот редко но метко в коде укладки рюкзака будет мемори корапшен, такой что у соседа по кабинету будет креш раз в 3 дня с непонятным колстеком, а тесты будут показывать ок. При разработке бизнесс приложений да еще на языках со строгой типизацией и безопасностью а-ля ява, юнит тесты призваны гарантировать (в т.ч.) целостность системы, т.е. покодил запустил ЮТ, если ок то значит тебе практически гарантировано что ничего не нарушено и все работает как нужно, иначе как можно делать тот же рефакторинг в слепую. При разработке игр (т.е. при большом кол-ве данных и зависимостей кода от них)
на С++ ЮТ теряют смысл. Особенно учитывая их поддержку и зависимость от внешних данных.
Допускаю правда что можно обернуть ЮТ некоторые слабосвязанные модули. Так же допускаю что использование ЮТ хорошо ляжет на тулзы, особенно на какие-то экпортеры/пакеры/конверторы которые должны работать всю ночь и любая ошибка в них оставит всю контору без нового билда на весь следующий день.
Отправлено 16.08.2007 в 11:11
Отвечает на сообщение 213086
0
Robot Verter wrote:
>
> http://www.dtf.ru/articles/read.php?id=47509


А вот есть где-нибудь чья-нибудь реальная статистика, сколько времени занимает _поддержка_ UT и сколько - исправление косяков, в следствие плохой поддержки?
UT, написанный с ошибкой, - это же вообще бомба!
Отправлено 16.08.2007 в 11:32
Отвечает на сообщение 213118
0
Александр Клименко wrote:
>
> А вот есть где-нибудь чья-нибудь реальная
> статистика, сколько времени занимает _поддержка_
> UT и сколько - исправление косяков, в следствие
> плохой поддержки?


Думаю, нету, т.к.
- проекты сильно разные от частоты и характера вносимых изменений,
- UT - это часть работы (часто - значительная: 20..40% типично, если покрывать "почти всё") и никто её как "довесок" не учитывает (из тех, кто правильно использует) - но это скорее не геймдев уже...


> UT, написанный с ошибкой, - это же вообще бомба!


Для этого придумали pair programming и пр., хотя - не панацея...
Отправлено 16.08.2007 в 11:57
Отвечает на сообщение 213120
0
Евгений Белоглазов wrote:
>

Пробежался по ссылке из ЖЖ :).
И опять попалось на глаза "появляется уверенность".
А хочется, ч0рт побери, гарантий!! :)
Отправлено 16.08.2007 в 14:48
Отвечает на сообщение 213118
0
Александр Клименко wrote:
> А вот есть где-нибудь чья-нибудь реальная
> статистика, сколько времени занимает _поддержка_
> UT и сколько - исправление косяков, в следствие
> плохой поддержки?
> UT, написанный с ошибкой, - это же вообще бомба!


Вот как раз пример про тест, правда не Unit на сколько я понимаю который был написан не правильно

http://avva.livejournal.com/1796443.html
Отправлено 16.08.2007 в 13:46
Отвечает на сообщение 213086
0
function bool ShouldIReadTheArticle(bool previousProjectSucceed)
{
return !previousProjectSucceed;
}

А это на каком языке написано?
Отправлено 16.08.2007 в 14:29
Отвечает на сообщение 213147
0
Анатолий Бобков wrote:
>
> function bool ShouldIReadTheArticle(bool
> previousProjectSucceed)
> {
> return !previousProjectSucceed;
> }
>
> А это на каком языке написано?

Да, и где тест на функцию???
Отправлено 17.08.2007 в 09:23
Отвечает на сообщение 213147
0
С++,
function это макрос на пустое место, поставленный для самопального парсера строющего схему кода.
;)
Отправлено 17.08.2007 в 10:23
Отвечает на сообщение 213248
0
>С++,
>function это макрос на пустое место, поставленный для >самопального
>парсера строющего схему кода.
>;)


Ну на макрос тоже не похоже.

обычно макросы пишут ЗАГЛАВНЫМИ буквами.
Отправлено 17.08.2007 в 09:23
Отвечает на сообщение 213086
0
Robot Verter wrote:
>
> http://www.dtf.ru/articles/read.php?id=47509



Separating practics consider harmful!
Или не для критики, а для дополнения.

Практики очень тяжело рассматривать по отлельности.

Преусловутое парное программирование - это безумная трата ресурсов двух людей на работу для одного.А ещё это плацдарм для применения Принципа Студента (до сдачи ещё далеко - успеем), Закона Паркинсона (работа заполняет все отведённое на неё время и ресурсы) и Принципа "Моя хата с краю" (пусть сосед делает, а я понаблюдаю).
В Agile предусмотренно куча правок для недопущения принципов. Например, постоянно меняющиеся пары. Подбор пары производится не по принципу "опытный и неопытный", но ответсвенный за задачу подбирает из незанятых программистов того, кто к этой задаче наиболее причастен. В результате сокращаются затраты на коммуникацию и поиск документации, а также, разработчик получает обратную связь (уже хочется (tm) написать) по использованию своего кода.

Но даже после всех этих ухищерений, парное программирование лучше заменить на систему: все сидят за круглым столом и могут на время подозвать (вызвонить по корпоративному джаберу) другого программиста для помощи в "думалке" или для объяснений.

На самом деле, парное программирование нужно для поддержки смежных практик. Например, для решения проблемы неправильных Unit Testes путём "вглядывания в код" посторонних людей. Для получения "задарма" Code Review (для рефакторинга), даже для возможности расслабится и на время отвлечся от кода, просто передав клавиатуру (XP изначально ориентированно на выжимание максимальной производительности, потому отдыхать надо).

Остальные методики также неприглядны по отдельности (и исторически были переборены более оптимальными методиками), но вкупе с остальными практиками дают большие плюсы. Отсюда главная проблема XP и иже с ними: если мы реализуем "XP without refactoring" необходимо пересмотреть все остальные практики и попробовать заменить их на более оптимальные.
Кстати целовой тип проекта (бизнес-система поставляемая конкретному заказчику) - это тоже "практика" и её замену тоже нужно сопровождать ревизией методик XP.
Отправлено 17.08.2007 в 10:41
Отвечает на сообщение 213246
0
Михаил Певзнер wrote:
> Преусловутое парное программирование - это
> безумная трата ресурсов двух людей на работу для
> одного.

Нет, это - другое. Это из области риск-менеджмента больше...

> А ещё это плацдарм для применения Принципа
> Студента (до сдачи ещё далеко - успеем), Закона
> Паркинсона (работа заполняет все отведённое на
> неё время и ресурсы) и Принципа "Моя хата с краю"
> (пусть сосед делает, а я понаблюдаю).

ПП можно применять и так, но нужны ли такие сотрудники команде?..

> В Agile предусмотренно куча правок для
> недопущения принципов. Например, постоянно
> меняющиеся пары.

Выбираются свободные. Обязательно меняться по графику особого смысла нету.

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


XP возникло в контракторских проектах, где у всех более или менее одинаковый уровень. Хотя специализацию/интересы - не отрицает.

> Но даже после всех этих ухищерений, парное
> программирование лучше заменить на систему: все
> сидят за круглым столом и могут на время
> подозвать (вызвонить по корпоративному джаберу)
> другого программиста для помощи в "думалке" или
> для объяснений.

Думаю, it depends...

> На самом деле, парное программирование нужно для ...

А ещё для:
- снижения доли мусорного времени,
- защиты от внезапной недоступности одного или большего количества членов команды (попадание в больницу, увольнение, падение астероида и т.п.)

Кстати, исследования показали, что двукратной потери скорости при ПП нету, кое-где даже рост скорости есть.
Плюс к тому, что автоматическое code review и пр., что Вы написали.

> Остальные методики также неприглядны по
> отдельности

Приглядны-приглядны... Например, про 40-часовую неделю и пр. ;-)

> оптимальными методиками), но вкупе с остальными
> практиками дают большие плюсы.

"Лучше работают вместе, но полезны и по одной" (с)

> Отсюда главная проблема XP и иже с ними:

Главная проблема Agile (как и вообще современных инструментов) - то, что многие программисты НЕ ЧИТАЮТ КНИГ, НЕ ОБЩАЮТСЯ С КОЛЛЕГАМИ, НЕ ХОТЯТ УЧИТЬСЯ НОВОМУ.
Отправлено 17.08.2007 в 13:40
Отвечает на сообщение 213257
0
Евгений Белоглазов wrote:
> Главная проблема Agile (как и вообще современных
> инструментов) - то, что многие программисты НЕ
> ЧИТАЮТ КНИГ, НЕ ОБЩАЮТСЯ С КОЛЛЕГАМИ, НЕ ХОТЯТ


Это не проблема agile, это тупо кадровый вопрос.
Отправлено 01.10.2007 в 12:36
Отвечает на сообщение 213086
0
Тут вслывал вопрос: "Покажите мне ААА игру которая была сделана с использованием Agile методологий".

вот: World in Conflict сделан с помощью SCRUM
вроде как на ААА тянет :)
Comments
Списки доступа
  • Подписчики [581]
  • Черный список [2]
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
анонимы : могут читать
новые : полный доступ
постоянные : полный доступ

Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение