Войти
ПрограммированиеФорумОбщее

Перевод Game Programming Patterns или Шаблоны игрового программирования (перевод закончен, дорабатывается) (3 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#30
0:11, 11 июня 2014

Kartonagnick
> Здесь вроде бы по-русски написано, не?
Вот я и говорю, что у тебя с контекстом худо. Там написано в переводе с английского. А в оригинале написано вот что:

Moreso, maintaining a good architecture over the life of a project takes a lot of effort.

Причем, до этого можно догадаться, не заглядывая в оригинал, и не заявлять, что автор - диванный теоретик.

#31
0:33, 11 июня 2014

Помеха
> А в оригинале написано вот что:

Оригинал я не читал. Приведенная вами ссылка по смыслу - тоже самое, что и в переводе.

Если вы согласны с автором:

Moreso, maintaining a good architecture over the life of a project takes a lot of effort.

То у меня для вас плохие новости - с логикой у вас определенно беда.

Помеха
> Причем, до этого можно догадаться, не заглядывая в оригинал

Идиотизм.

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

Шляпа в общем. Маразм крепчает. Надеюсь, вы не пишите документацию?

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

#32
0:53, 11 июня 2014

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

#33
1:03, 11 июня 2014

Kartonagnick
ты не отличешь слова "больше" и "много"? Тут это важно. И ты неправильно выделил слова в цитате

Moreso, maintaining a good architecture over the life of a project takes a lot of effort.

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

#34
4:21, 11 июня 2014

Kartonagnick
> Закономерный вопрос: нахер нужна такая архитектура, которая требует больше
> усилий и выливается в трату большего количества времени?
Блин, ну как хорошая архитектура может требовать меньше времени? Ты можешь объяснить эту логику. Потому что ты утверждаешь что именно говнокод более трудозатратен. Тогда почему все пишут говнокодом, а не идеальным кодом?

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

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

Идеальный код всегда требует больше времени

#35
13:04, 11 июня 2014

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

Ну допустим, возникла такая необходимость, и кто-то из ребят набросал говнеца и таки решил задачу в рекордные сроки. Зачем его за это бить палкой? И другой вопрос: после его коммита в репозитории откровенный говнокод, который благополучно инкапсулирован в каком то отдельном модуле. Зачем это нужно рефакторить?

war_zes
> Так по твоей логике именно последнее - идеальная архитектура.

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

+ Показать


war_zes
> Вот пример. Можно сесть за TDD, расписать всю архитектуру, начертить кучу UML,
> продумать связи, цели. Получим идеальную архитектуру

Не получите.
Вы получите говнокод.

#36
13:43, 11 июня 2014

Kartonagnick
> И другой вопрос: после его коммита в репозитории откровенный говнокод, который
> благополучно инкапсулирован в каком то отдельном модуле. Зачем это нужно
> рефакторить?
Мы как будто в разных вселенных живем, с разными людьми.
Один мой знакомый (тм) лид "на секунду отвернулся", и джуниоры тут же закоммитили в класс спрайта метод bool IsWeddingDress(). О какой инкапсуляции речь?
Кроме того, ты упорно игнорируешь тот факт, что код надо сопровождать и поддерживать. Наличие хорошо инкапсулированного говнокода задачу отнюдь не упрощает.

#37
14:16, 11 июня 2014

Kartonagnick
> Это может сделать человек, который хорошо разбирается в предметной области
> (имеет опыт).
> Уже делал это, и может сделать это быстро.
А почему ты игнорируешь тот факт, что чтобы разбираться в предметной области, нужно приложить дополнительные усилия? И программирование - это не та область, в которой ты можешь сказать что уверено разбираешься во всем. Да, хеловорды уже можно писать закрытыми глазами, но всегда будет та задача, которая потребует ее освоения. А наш опыт, это не умение решать однотипные задачи - это может и обезьяна.
Наш опыт дает нам возможность больше предвидеть, и оперировать большими фактами - по простому - с увеличением опыта, появляется возможность предсказывать больше будущих проблем до их наступления. Но при этом приходится оперировать все большим количеством фактов, и не все они сопоставимы.

То что нельзя спроектировать идеальную архитектуру, это понятно, но это не означает что этим стоит пренебрегать

#38
14:38, 11 июня 2014

Kartonagnick, ты видимо не писал сложных проектов. Тогда бы ты понимал, чем важна ХОРОШАЯ архитектура для проекта в общем и его поддержки. Лучше потратить много времени на архитектуру, чем еще больше на рефакторинги.

#39
16:51, 11 июня 2014

Kartonagnick
> Ну допустим, возникла такая необходимость, и кто-то из ребят набросал говнеца и таки решил задачу в рекордные сроки. Зачем его за это бить палкой? И другой
> вопрос: после его коммита в репозитории откровенный говнокод, который благополучно инкапсулирован в каком то отдельном модуле. Зачем это нужно рефакторить?
Решил. Класс! Задача работает.
Проходит полгода, говнокодер уже давно стал топ-менеджером и зарабатывает некислые бабки, у него все хорошо - он теперь сам ставит задачи.
И тут старая задача чуть усложняется.
Новый программист начинает копаться в коде. С виду добавление ничтожно - но что-то ломается в старых наговнокоженных дебрях, и этот новый программист помимо изменений в одной задаче вынужден ОТРЕФАКТОРИТЬ ВСЕ, ЧТО СВЯЗАНО С ЗАДАЧЕЙ.
Что заведомо сложнее, чем написать ТУ ЖЕ самую задачу с новым условием с НУЛЯ.

Вот и вся разница.

Конкретный пример из текучки.
Ранее созданное приложение делалось под iOS6. Работало идеально, но с хаками, конкретными под iOS6.
Сейчас на дворе рулит iOS7. И то, что раньше работало под iOS6, теперь сломалось. В том числе и хаки, раскиданные по всей программе.
Выгребаю третий день. Хотя задача была - плевейшая, на час работы.

#40
17:50, 11 июня 2014

CasDev
> Вот и вся разница.
Совершенно верно.
Самое интересное, что в книжке автор именно об этом и пишет.

#41
13:35, 12 июня 2014

Я его не игнорирую Помеха
> ты не отличешь слова "больше" и "много"? Тут это важно. И ты неправильно
> выделил слова в цитате

"больше" и "много" в данном контексте не принципиально. Я правильно выделил слова.

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

Я не давал повода так о себе думать.

war_zes
> Наш опыт дает нам возможность больше предвидеть, и оперировать большими фактами
> - по простому - с увеличением опыта, появляется возможность предсказывать
> больше будущих проблем до их наступления. Но при этом приходится оперировать
> все большим количеством фактов, и не все они сопоставимы.

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

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

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

Я бы перефразировал иначе: "идеалов не существует, но это не значит, что у ним не нужно стремиться".

+ Показать

Однако, предаваясь соблазнам перфекционизма, стоит подумать об уместности и целесообразности изменений.

+ Показать


kardinal
> Kartonagnick, ты видимо не писал сложных проектов. Тогда бы ты понимал, чем
> важна ХОРОШАЯ архитектура для проекта в общем и его поддержки. Лучше потратить
> много времени на архитектуру, чем еще больше на рефакторинги.

Наивная душа.

Напротив, я понимаю ЧЕМ важна хорошая архитектура - она экономит время и нервы.
Потому что хорошая архитектура - быстро и легко изготавливается. Легко поддерживается.

А вот вы понимаете, что постулируете?  "потратить кучу времени", что бы "не тратить кучу времени" ?

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

Хорошая архитектура безболезненно переносит потерю своих узлов, или их частичную/полную замену.
Поэтому её рефакторить вообще надобности не возникает.

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

+ Показать


CasDev
> Новый программист начинает копаться в коде. С виду добавление ничтожно - но
> что-то ломается в старых наговнокоженных дебрях, и этот новый программист
> помимо изменений в одной задаче вынужден ОТРЕФАКТОРИТЬ ВСЕ, ЧТО СВЯЗАНО С
> ЗАДАЧЕЙ.
> Что заведомо сложнее, чем написать ТУ ЖЕ самую задачу с новым условием с НУЛЯ.

Новый программист видимо ещё неопытный юнец. Зачем он полез в рабочий отлаженный код, который уже исправно приносит компании прибыль?
Он не должен ломать коммерческий код.

Узел - это ящик.

вход ----> узел ----> выход.

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

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

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

#42
17:11, 16 июня 2014

Kartonagnick
Так вот, в шикарной схеме

 вход ----> узел ----> выход.

хорошо укладываются изменения в узле. Однако на практике часто меняются как входные, так и выходные данные.
И далее идет веер изменений.

Пример.
Были у тебя только дефовые карты, и только атакующие. А теперь появились еще и специальные, причем разного типа. А еще есть карты, которые могут быть сыграны либо как одна, либо как вторая.

При этом если у тебя хорошо структурированный код, то даже ТАКИЕ изменения впиливаются относительно просто.
А вот ежели лапша на лапше висит и спагетти погоняет, то вешаться можно.

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

>Опытный программист легко и быстро может с нуля поднять архитектуру, поддерживать которую ему будет легко.
Тут никто и не спорит. Вот только опытный программист перед этим ПОЛНОСТЬЮ уточнит все вещи и ОБДУМАЕТ их.

#43
22:45, 17 июня 2014

CasDev
> А вот там где нет инварианта между любыми изменениями (в твоем случае - где
> данные могут поменяться не в одном узле а в нескольких) - только плакать.

У вас какие то крайности: "хорошая архитектура", которая требует уйму времени и денег на создание и уход, или спаггети, который в принципе только на выброс.

Я вам проще на примере покажу:

...
int main()
{
    ...

    PanelLogin pan_login; //<--- может быть создан где угодно. В любой точке программы

    Network net;//<--- может быть создан где угодно. В любой точке программы
    
    //служит для наглядности
    typedef Network::PasswordLogin PasswordLogin;  //  struct PasswordLogin{ string mPassword, mLogin; };
    
    //сеть слушает входящие сообщения нужного ей типа по каналу "network" 
    //она может подписаться на сообщения самостоятельно в конструкторе, или это можно сделать снаружи - не принципиально.
    //EventSystem  - инструментальный механизм общего назначения, работает по принципу делегата в многоканальном режиме. 
    //Умеет доставлять сообщения всем подписавшимся клиентам.
    //доступна из любой точки программы
    EventSystem::Subscribe<PasswordLogin>("network", net, &Net::Receiver );

    //когда игрок жмакнет на кнопку "login" в гуевом интерфейсе, панель автоматически запустит этот делегат
    pan_login.mClickLogin = [](const string& password, const string& login)
    {
         const auto data = PasswordLogin(password,login);

         //который через лямбду отправит сообщение по каналу связи "network"
         EventSystem::Post("network", data);
    };

    //итого:

    //гуй ничего не знает ни о какой сети. И понятия не имеет куда уходят данные. Ему фиолетово.
    //сеть ничего не знает ни о каком гуе, и понятия не имеет откуда приходят данные. Ей фиолетово.


    ...
}

Что мы здесь видим?
Мы видим взаимодействие двух логически не связанных друг с другом узлов.

В действительности, для работы гуя сеть не нужна. А для работы сети не нужен гуй. Здравый смысл рулит и педалит. Фишка в отсутствии хардкордных связей - зависимостей от инфраструктуры проекта.

1. Узлы не тащат в себе отпечаток среды и могут быть повторно использованы где нибудь ещё.
2. Для работы гуи не нужна сеть. Для работы сети не нужен гуй. Удобно тестировать узлы. В том числе в изолированной среде воссоздавать и обкатывать различие ситуации.
3. Удобно разрабатывать узлы в отдельном от игры проекте (например - в редакторе, или просто в отдельном проекте, где нет ничего лишнего. И можно делать все быстрее.
4. Можно распараллелить разработку Вася пилит гуй, а Петя - сеть. И при этом ни тот, ни другой не испытывают дискомфорта от отсутствия рабочей инфраструктуры.

Ну и наконец:

5. Узлы полностью изолированы друг от друга. Внутрях там может быть аццкий говнокод.  Но он инкапсулирован внутри узлов, и не может навредить другим частям проекта.
Трястись над узлами, вылизывать их нет никакого смысла. Узел работает? Работает. Ну и пускай себе работает. Кому какое дело, что там внутри?
Так или иначе, вы всегда сможете его отрефакторить или заменить полностью безболезненно для всего остального проекта.

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

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

Архитектура, которая долгая-трудная в изготовлении, да ещё к тому же требует кучу времении на постоянный уход - это говноархитектура, какой бы "вылизанной" она ни казалась на картинках, или в теории.
На практике - одни расходы, и низкая скорость разработки.

+ Показать
#44
23:03, 17 июня 2014

Kartonagnick
Ок, можете расписать работу ГУЯ магазина и прокачек без запросов?

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумОбщее

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