Какие методы гибкой разработки совместимы с разработкой игр? [closed]

Закрыто . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы на него можно было ответить фактами и цитатами, редактируя это сообщение .

Закрыт 2 года назад .

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

Такие концепции, как рефакторинг выглядят как они вполне могли совместиться с небольшой и неопытной командой. Идея «принять перемены» также сочетается с неопытными командами, идеи которых постоянно меняются. Но такие вещи, как TDD, довольно проблематичны.

Трудно и неоптимально тестировать, например, класс, который взаимодействует с Direct3D. В этом нет особого смысла.

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

Заранее спасибо.

edit -

Плюс, моя команда состоит из 3 человек: один программист, один графический дизайнер и один программист / графический дизайнер combomix. У нас нет клиента, поэтому мы должны принимать все решения в одиночку.

Я читал в статье Фаулера, что agile зависит от взаимодействия разработчика и клиента, но он также упомянул, что клиенты нежелание придерживаться гибкой разработки все же может быть полезно для гибкой разработки (статья называлась Новая методология ). Как это применимо к моему случаю?

Выводы -

Я думаю, что вопросы на StackOverflow могут помочь и другим, поэтому я постараюсь здесь обобщить свои мысли по этому поводу.

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

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

Таким образом, медленная часть (на самом деле открытие окна и т. д.) выполняется только один раз при проверке верности макета реализации, а все остальное просто проходит гладко над макетом. [спасибо Кэмерон ]
A Мышление BDD помогает облегчить параноидальный поиск тщательного тестирования модулей, «заменяя» тестирование путем спецификации фактического поведения, а не сжатых единиц, которые во многих случаях лучше оставить непроверенными (или только косвенно протестированными, если вы предпочитаете это так), чтобы избежать слишком большого количества индивидуального тестирования по сравнению с единицей (класс, метод , переменная и т. д.), что увеличивает хрупкость теста (теперь «спецификация»). [спасибо Kludge ]

задан Community 23 May 2017 в 11:55

0 ответов

Другие вопросы по тегам:

refactoring tdd agile

Какие методы гибкой разработки совместимы с разработкой игр? [closed]

0 ответов

Похожие вопросы: