Войти
ФлеймФорумПрограммирование

Почему хабр торчит от TDD? (38 стр)

Страницы: 135 36 37 38 39 40 Следующая »
#555
0:00, 16 фев. 2013

Kartonagnick
> Вах вах! Кто там вякал про "стандарт решений" безотносительно к задаче?
> но ваши "примеры теней" - это кони в ваккуме.

В 2D свои тени, в 3D свои. Тот алгоритм теней, о котором написано выше, используется сейчас во всех realtime движках и играх. Вот тебе и кони в вакууме.
И аппаратно ускоренная графика во всех современных 3D и 2D играх сейчас рисуется треугольниками, текстурами и шейдерами. Если вам об этом неизвестно, сочувствую.


Kartonagnick
> Вах вах! Кто там вякал про "стандарт решений" безотносительно к задаче?

Рассматриваемая задача вполне ясна. Тут видимо опять проблемы чтения у вас, сударь.


> #555

^_^

Изображение
#556
0:32, 16 фев. 2013

Kartonagnick
> ты сделаешь дизайн использования.

UberGame.DoAllCoolStuffAndMakeManyMoney();
Реализуй. Тест - производная состояния моего колешлька должна быть монтонно растущей функцией.
#557
5:11, 16 фев. 2013

Стоп стоп стоп! че за фигня?

Какие нафиг TDD и Юнит тестирование кода отвечающего за формирование изображения? Сколько раз уже говорилось что GUI и Render с помощью TDD не проектируется и тестами не покрывается - тут только человеческий глаз и мозг. Писать тесты для тестирования выводимой графики - это уже какая то шизофрения! Не позорить TDD!!! он такое не советует!

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

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

А следовательно такую модель, порой содержащую представление или сильно зависимую от классов представления, как мы уже выяснили тестировать невозможно (представление может протестировать только человек) и ненадо про Mockи, вы никогда не создадите хорошие Моки притворяющиеся классами 3Д движка или API DirectX / OpenGL - на такой труд уйдут месяцы.
Следовательно TDD не может быть использован не для создания модели, не для ее полноценного тестирования.

TDD есть только ограниченное место в геймдеве в тех областях что я говорил. DDD может с некоторыми корректировками использоваться и в геймдеве. Такие расслоения как MVC (и ему подобные) в геймдеве (во всяком случае 3Д) - недопустимы.

#558
5:19, 16 фев. 2013

ASD
TDD не такой уж ужасный метод. Просто он не везде применим и много кто его неправильно объясняет и пытается привязать к тому где он не применим. Не советую объявлять этот метод плохим, более корректно говорить о его неприменимости в некоторых областях.

#559
6:01, 16 фев. 2013

Kipter

> Писать тесты для тестирования выводимой графики - это уже какая то шизофрения! Не позорить TDD!!! он такое не советует
Не, замокать, как тут говорят, можно все. Почитай выше - мы там мокали привода/двигатели антенны и датчики углового положения.

#560
12:11, 16 фев. 2013

ASD
> И аппаратно ускоренная графика во всех современных 3D и 2D играх сейчас
> рисуется треугольниками, текстурами и шейдерами.
    Вот тесты, видимо, и проверят факт рисования треугольника (с заданными координатами), факт рисования текстуры (скажем, монотонной) и факт вызова шейдера (и то, что он действительно вычисляет заложенную в него формулу). А то что при этом рисуются тени должно обеспечиться само собой. Во всяком случае я понял аргументы сторонников TDD так.

#561
13:05, 16 фев. 2013

Kipter
> сущности прямо на уровне представления и это не просто представление сущности
> - это сама сущность. (в этом меня окончательно просветлили западные и
> американские коллеги).
Kipter
> Такие расслоения как MVC (и ему подобные) в геймдеве (во всяком случае 3Д) -
> недопустимы.

Ну вот, наконец то дошло :)
Зато пыли подняли скоко, ну думаю тролль по ходу.

#562
16:28, 16 фев. 2013

kipar
> Во всяком случае я понял аргументы сторонников TDD так.
Это неверные аргументы.

bodja
> Ну вот, наконец то дошло :)
Я прямо с первого своего поста в этой теме и в дальнейшем обозначал:
Ребята TDD и DDD и расслоение логики и представления в Энтерпрайзе очень прекрасно работает и это маст хев!
Но в геймдеве я не имею хорошего и большого опыта поэтому как бы могу в чем то ошибаться относительно него.
Вы видимо пропустили в чтении эти мои посты. В итоге нормально ситуацию мне прояснили не русские люди, что печально )
У буржуев такие темы как TDD / DDD заканчиваются спустя 4-5 постов где в итоге нормальные и краткие выводы, без бурления говн.


bodja
> Зато пыли подняли скоко, ну думаю тролль по ходу.
Если вы заметите я защищал и если потребуется дальше буду защищать ООП / DDD / TDD / Multilayered architecture как инструменты показывающие высоко-эффективные результаты в Энтерпреайз проектах (в них у меня широкий опыт).
Защищал я их потому что некоторые люди без разбору начинали кричать что это говно, лоходром, дибилизм и т д. Хотя в действительности речь идет лишь о том что не все что хорошо энтерпрайзу также хорошо геймдеву.
И еще постами ранее я уже высказал новые представления о применимости всего вышеперечисленного к геймдеву.

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

#563
17:20, 16 фев. 2013

Kipter
> Я прямо с первого своего поста в этой теме и в дальнейшем обозначал:
Да я читать умею, я не про TDD , а про то , что выделил.
А то вы как то в сильно бурных поисках архитектурных решений находитесь, понятно что пока творческий поиск, вот я и одобрямс некоторые моменты, что плохого?

А про TDD я уже сказал типа - "нафига козе баян" ,больше мне сказать нет желания.

#564
17:24, 16 фев. 2013

bodja
> А про TDD я уже сказал типа - "нафига козе баян" ,больше мне сказать нет
> желания.
То как некоторые тут представляют TDD чуть ли не как инструмент тестирования пикселей и теней :D
Я тоже могу в этих случаях сказать "нафига козе боян" ))) тоже не понимаю че это за хрень.

#565
19:37, 16 фев. 2013

Kipter
> То как некоторые тут представляют TDD чуть ли не как инструмент тестирования
> пикселей и теней :D

Это лишь попытки показать что TDD не везде применим.
Тут ведь несколько защитников ТДД кричат что раз не используешь ТДД - ты криворукий говнокодер, что ты тогда мыслишь наизнанку, тогда как ТДД несет исключительно свет и добро.

Kipter
> Хотя в действительности речь идет лишь о том что не все что хорошо энтерпрайзу
> также хорошо геймдеву.

Так сайт то не про энтерпрайз, сайт-то gamedev.ru называется. Наверное это неспроста.

#566
23:41, 16 фев. 2013

Kipter
> Если вы заметите я защищал и если потребуется дальше буду защищать ООП / DDD /
> TDD / Multilayered architecture как инструменты показывающие высоко-эффективные
> результаты в Энтерпреайз проектах (в них у меня широкий опыт).
  TDD является следствием OOП, которое как показала практика действительно не
везде применимо. Особенно для тех, кто не имеет навыков программирования в дебаггере)

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

#567
1:02, 17 фев. 2013

RenGD
> TDD является следствием OOП
TDD является следствием DDD которое не обязательно требует ООП но и допускает другие парадигмы.
Применимость DDD  - везде применимо и кстати выходит за рамки только написания кода (противопоказаний нет и для гейм дева) но применять по вкусу ) т.е. не является:  "раз не используешь DDD - ты криворукий говнокодер"
Часто вообще считается что TDD это методика проектирования с тестами над DDD.


ASD
> раз не используешь ТДД - ты криворукий говнокодер, что ты тогда мыслишь
> наизнанку, тогда как ТДД несет исключительно свет и добро.
Да тут проблема даже не в ТДД, любые попытки криков о:
"раз не используешь Х - ты криворукий говнокодер, что ты тогда мыслишь наизнанку, тогда как Х несет исключительно свет и добро"
Являются избыточными религиозными убеждениями и зацикленностью, всегда необходимо допускать множество вариантов в разных контекстах.

ASD
> Это лишь попытки показать что TDD не везде применим.
Более того TDD может быть применим для части классов проекта и неприменим для другой части классов проекта )
Дома тоже строятся не только молотками, гвоздями и досками, некоторые его части строятся другими материалами и инструментами)

#568
14:18, 17 фев. 2013

Kipter
> Да тут проблема даже не в ТДД, любые попытки криков о:
> "раз не используешь Х - ты криворукий говнокодер, что ты тогда мыслишь
> наизнанку, тогда как Х несет исключительно свет и добро"
> Являются избыточными религиозными убеждениями и зацикленностью, всегда
> необходимо допускать множество вариантов в разных контекстах.

Да, видимо так и получилось.


Изображение

#569
14:50, 17 фев. 2013

RenGD
> TDD является следствием OOП, которое как показала практика действительно не
> везде применимо.

Подробнее, где не применимо ? :)

Страницы: 135 36 37 38 39 40 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.