И читал и понял, и применял, и могу сравнить разные подходы. Мартин про управление сложностью через ооп-абстракции, но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится "вонючим" как вы выразились и невыносимым для поддержки через год. Когда у вас граф зависимостей разрастается до такой степени, что никто не понимает, как данные текут через систему, это и есть результат слепого следования букве книги, а не реалиям разработки. Задача хорошего разработчика найти баланс, чтобы код остался понятным и расширяемым, не превращаясь в "лапшу" из виртуальных вызовов и аллокаций. И это не всегда ООП и не всегда чисто в редакторе. Про устаревшние способы тоже верно, и это один из аргументов не тащить наследие. Есть более современные авторы Фабиан и Найстром, которые пишут как выбраться из этого оопешного ада, и книга Оустерхаута, которая показывает недостатки стиля Мартина.
А это одно из ответвлений билд-инженера (CI/CD) или tool/engine-программера, отвечает за то, чтобы игра держала бюджеты памяти/времени кадра на таргет платформах. В небольших студиях эту роль часто тащит техлид/техдир или кто-то из принципалов по совместительству, в более крупных это отдельная команда внутри engine-подразделения и отдельный человек.
в эпоху переизбытка мощностей по большей части не заботит, но кого это заботит? /s Ж) Это один из вопросов в студии, нужен ли нам перформанс инженер, часто он поднимается когда чинить уже поздновато. Но в целом стараются все же следить за этим. Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме, потому что к моменту выхода игры они станут массовыми конфигурациями. Люди, которые попали в эти 20% играют без проблем, консоли играют без проблем, люди которые к моменту выхода не попали... испытывают затруднения
Как сказал один из хороших разработчиков, если вы не можете это сказать словами и нарисовать на одной стороне листа, то написать это хорошо, тоже не сможете.
"A specification that will not fit on one page of 8.5x11 inch paper cannot be understood." "Спецификация, которая не помещается на одном листе формата 8.5x11 дюймов, не может быть понята." Mark Ardis
Не знаю как там яндекс, а мost vexing parse случился на прошлой неделе. В прошлом месяце были проблемы с перфом от std::mt19937, который вдруг стал показывать 2% в топе функций на фрейме после минорного обновления компилятора, а сегодня я пробую понять откуда взялись столлы от недавно закомиченных статик переменных в функциях. Так что про реальную работу тут не угадаешь, когда это понадобится.
да там тоже жизнь особо мёдом не была, как вспомню проекты начала нулевых, аж зубы болеть начинают. Немного лучше стало с приходом 11 стандарта, боле менее устаканилось в 17, или я просто стал спокойнее и перестал сильно агриться на новые фичи
Да пишите, никто не мешает. Хорошая игра не та, что идеально сделана, а та в которую играют.
промахнулся, ответ чуть ниже.
И читал и понял, и применял, и могу сравнить разные подходы. Мартин про управление сложностью через ооп-абстракции, но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится "вонючим" как вы выразились и невыносимым для поддержки через год. Когда у вас граф зависимостей разрастается до такой степени, что никто не понимает, как данные текут через систему, это и есть результат слепого следования букве книги, а не реалиям разработки. Задача хорошего разработчика найти баланс, чтобы код остался понятным и расширяемым, не превращаясь в "лапшу" из виртуальных вызовов и аллокаций. И это не всегда ООП и не всегда чисто в редакторе. Про устаревшние способы тоже верно, и это один из аргументов не тащить наследие. Есть более современные авторы Фабиан и Найстром, которые пишут как выбраться из этого оопешного ада, и книга Оустерхаута, которая показывает недостатки стиля Мартина.
А они так не умеют, так умеют некоторые экспериментальные нейронки от Intel, но они стоят запредельно дорого.
А это одно из ответвлений билд-инженера (CI/CD) или tool/engine-программера, отвечает за то, чтобы игра держала бюджеты памяти/времени кадра на таргет платформах. В небольших студиях эту роль часто тащит техлид/техдир или кто-то из принципалов по совместительству, в более крупных это отдельная команда внутри engine-подразделения и отдельный человек.
идеи то правильные, но не надо бездумно тащить в дом все что найдено, иначе дом превращается в свалку
тут врядли, желающих не нашлось
все просто, треть команды итало-испано говорящие, поэтому есть возможность проверить перевод через носителей языка.
это сделал человек, который принес красную книгу, после чего и зашла дискуссия про него. Про диверсанта мысль интересная :)
в эпоху переизбытка мощностей по большей части не заботит, но кого это заботит? /s Ж) Это один из вопросов в студии, нужен ли нам перформанс инженер, часто он поднимается когда чинить уже поздновато. Но в целом стараются все же следить за этим.
Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме, потому что к моменту выхода игры они станут массовыми конфигурациями. Люди, которые попали в эти 20% играют без проблем, консоли играют без проблем, люди которые к моменту выхода не попали... испытывают затруднения
Как сказал один из хороших разработчиков, если вы не можете это сказать словами и нарисовать на одной стороне листа, то написать это хорошо, тоже не сможете.
"A specification that will not fit on one page of 8.5x11 inch paper cannot be understood."
"Спецификация, которая не помещается на одном листе формата 8.5x11 дюймов, не может быть понята."
Mark Ardis
Не знаю как там яндекс, а мost vexing parse случился на прошлой неделе. В прошлом месяце были проблемы с перфом от
std::mt19937, который вдруг стал показывать 2% в топе функций на фрейме после минорного обновления компилятора, а сегодня я пробую понять откуда взялись столлы от недавно закомиченных статик переменных в функциях. Так что про реальную работу тут не угадаешь, когда это понадобится.как правильно отметили хабровчане выше, 95% этих нюансов вам понадобится очень не скоро. Поэтому, просто пиши код
https://habr.com/ru/articles/904208/
Это к Свиридкину и @Andrey2008 лучше я не силен в UB, в смысле написать могу, но с починкой хуже
блин, еще забыл про final и пачку проблем с ним
но это везде порицаемо, спецсимволы не должны пролезать в имена, с $ видимо недоработка вышла
да там тоже жизнь особо мёдом не была, как вспомню проекты начала нулевых, аж зубы болеть начинают. Немного лучше стало с приходом 11 стандарта, боле менее устаканилось в 17, или я просто стал спокойнее и перестал сильно агриться на новые фичи
автор писал про свою боль, чужой мне не надо :)
зря вы так, языки бывают двух типов: которые ругают, и на которых не пишут.