Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – https://t.me/programming_tales/662
а разве игровые студии заботит фпс? :))
Так жирно, что тонко :)
А если серьёзно, то ещё как! Как раз с Сергеем уже цикл вебинаров есть на тему GameDev и оптимизации:
в эпоху переизбытка мощностей по большей части не заботит, но кого это заботит? /s Ж) Это один из вопросов в студии, нужен ли нам перформанс инженер, часто он поднимается когда чинить уже поздновато. Но в целом стараются все же следить за этим.
Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме, потому что к моменту выхода игры они станут массовыми конфигурациями. Люди, которые попали в эти 20% играют без проблем, консоли играют без проблем, люди которые к моменту выхода не попали... испытывают затруднения
Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме,
Дать разработчикам компьютеры действующего среднего уровня, а не как они привыкли топового, вот тогда и начнут писать код который работает быстрее.
Дать разработчикам компьютеры действующего среднего уровня
Так ведь два последних поколения консолей - это они и есть. Это раньше были какие-то MIPS, PowerPC и прочие извращения, а с восьмого поколения везде AMD64 (ну, кроме Switch).
Просто на ПК дают настройки покрутить и рендерить в каком угодно разрешении, отчего сразу видно "косяки" в производительности, а на консолях будешь жрать что разработчики выставили.
Например, в Dragon's Dogma 2 (как пример не самой оптимизированной игры) на консолях есть два режима: "плавающий" FPS (который не ниже 30, но и до 60 никогда не дотягивает) или жёсткие 30 FPS, и реальное разрешение игры меньше того, что оно выдаёт на выходе (1920x2160 для "4К" и 1280x1440 для "2К").
нужен ли нам перформанс инженер
а что такое перформанс инженер? Промт-инженер слышал! перформанс инженер - это что-то новенькое, даже в IPP которое Intel Performance Primitives, 25+ лет назад, такого не было.
Просто надо чтобы кто-то умел померить эти ФПС, но уже никого не осталось кто их померить правильно может. Консоли пока играют и ладно. И Clean Code тут, как бы особо, тоже не причем, надо просто уметь измерить, остальное приложится.
А это одно из ответвлений билд-инженера (CI/CD) или tool/engine-программера, отвечает за то, чтобы игра держала бюджеты памяти/времени кадра на таргет платформах. В небольших студиях эту роль часто тащит техлид/техдир или кто-то из принципалов по совместительству, в более крупных это отдельная команда внутри engine-подразделения и отдельный человек.
Определение Clean Code разное в разных контекстах. В контексте корпоративной разработки Clean Code - это организация кода таким образом, чтобы внесение изменений в одном месте не ломали фичи в другом + реализуемая логика важнее производительности. В контектсе системного ПО Clean Code - это производительность превыше всего. В контексте субъективной вкусовщины Clean Code - это про красоту кода, который ототбражен на экране (название классов, переменных, расположение открывающих и закрывающих кавычек etc.). А ещё, вполне возможно, есть и другие контексты для Clean Code. Выбирай тот контекст, который тебе подходит, ну или нравится. Среди них нет плохих или хороших. Мартин написал книгу про одно, вы написали статью про другое. И то, и то имеет право на существование.
Это ваше представление о понимании словосочетания чистый код. А статья о том, что словосочетание стало брендом единственного подхода, который из-за популярности книжки получил поколения программистов выросших на ней которые тащат этот подход во все области, даже туда, где он вредит, оправдываясь оным словосочетанием.
Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
большая существующих интерфейсов одинаково неудобны человеку, например потому что писать на бумаге, рисовать или говорить более естественно, чем выражать мысль через ограниченный набор букв, плюсиков и амперсандов
Напомнило: "у меня не хватило слов чтобы это описать, поэтому я подготовил танец!"
Как раз сформулировать мысль удобнее через набор буковок и амперсандов, чем рисовать, писать на бумаге и даже говорить. Правда, не для всех...
Как сказал один из хороших разработчиков, если вы не можете это сказать словами и нарисовать на одной стороне листа, то написать это хорошо, тоже не сможете.
"A specification that will not fit on one page of 8.5x11 inch paper cannot be understood."
"Спецификация, которая не помещается на одном листе формата 8.5x11 дюймов, не может быть понята."
Mark Ardis
Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем астракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата.
Ну да, основная фича КлинКода для энтерпрайз приложений в том, что можно заменить любого на любого и он поймет что там происходит. Таким образом можно выгнать гения, когда он написал и отладил систему и посадить макаку её поддерживать.
for (Entity* e : scene.getAllEntities()) e->getTransform()->update(dt);
Справедливости ради, это не чистый код от слова вообще. Как минимум нарушен принцип Деметры, ну и в целом, это сделал какой то диверсант.
Непонятно, в чем претензия. Clean code разве обещает высокую производительность в играх? Нет. Код в таком стиле является более поддерживаемым? Является. В чем проблема-то?
Если что, я не согласен со многими советами из этой книги. Но логика статьи всё равно непонятна.
Чего ж тут непонятного? Дядя Боб же испортил все программирование на годы, а сам развлекается там в омериках на пенсии. А у нас тут в геймдеве разброд и шатание из-за его книжек 20 летней давности. От того, что мы доверчивые бездумно. Привыкли под авторитеты безоговорочно ложиться.
идеи то правильные, но не надо бездумно тащить в дом все что найдено, иначе дом превращается в свалку
Главное достоинство его книги, это не про чистый код, тестируемость, расширяемость и поддержку, это про то, что большинство разрабов пишут убогий и страшный код, который поддерживать невозможно. Объяснять им как писать правильно: для начала хотя бы выделять функции , долго муторно и все равно не поймут.
В этот момент можно взять «чистый код» пихнуть в «морду» и сказать пиши вот так. Если побежит жаловаться менеджеру- то тут ПР Товарища Мартина тоже поможет- мы же не против, сложившихся практик, мы за расширяемость … - нужное подчеркнуть.
Для человека который боле -менее нормально пишет ничего нового/интересного в в книге нет. Но таких, к сожалению не много …
Спасибо за статью. Возник вопрос по поводу сайта на github pages: почему именно итальянский был выбран третьим языком для статей? Из чистого любопытства интересуюсь, выбор показался весьма неожиданным
самое интересное, что у вас всего 2 маленьких примера, и буквально всё.
нет ни замеров, ни конкретных примеров почему тот или иной подход не совсем приятный.
у Кейси Муратори свой клин код, у Дяди Боба свой клин клод. у них у обоих клин код.
они оба говорят об одном и том же, Кейси говорит за минимализм без оверинжинирга, но на С писать не удобно, значит чуть по-выше это классы/деструкторы.
Статья хорошая, я бы сказал проблема даже шире.
Она не только с чистым кодом (дедушка Мартин вызывает сомнения своими советами со стартом), но в целом к границам применимости подходов и методологий.
У всего есть границы применимости и проблемы, которые оно решает.
И вот уже у людей странные требования к ООП, абстрактные зависимости, идеально быстрый ECS везде, нет синглтонам, AoS, SoA, паттерны, интерфейсы, браузер внутри, блеать, всего, виртуальные машины на виртуальных машинах и своя собственная, Тьюринг полняя, но плохая реализация LISP.
Причем все сразу.
Потому что эти рекомендации перешли из пространства решений в пространство ритуала и потеряли связь с ограничниями.
Потеряли важный фактор того, что оно не бесплатно, и если ты делаешь что-то просто так, ты платишь без отдачи.
Сами по себе рекомендации не бесполезны конечно, мысль про то, что хорошая архитектура может чего то стоить, как и то, что ультра оптимизированный код хер прочитаешь и логичная и подтверждается опытом.
Но все хорошо в меру.
спорить приходится уже не про абстрактную “чистоту”, а про конкретные наборы приёмов конкретного автора
Да, про конкретные приёмы можно спорить, но это не так интересно. Интереснее вопрос, должен ли код быть чистым в принципе или нет. Я считаю, что да, хотя конкретика конечно не как у апологета. Как считаете вы я не совсем понял.
Проблема в том что большинство программистов, последнее время пафосно направо и налево называющих себя инженерами, никакого отношения ни к понятию инженерного дела ни к понятию прагматизма не имеют. Уже давным давно балом правит хайп.
По хорошему, человек который прочитал Clean Code и думающий его внедрять, должен задаться вопросами: а кто такой автор книги и какой у него опыт и можно ли посмотреть его проекты, а если ли доказательства эффективности предлагаемых им методик, наконец провести мозговой штурм с коллегами проверяя это все на прочность. И тогда неожиданно выясниться что Мартин - обычный хайпожор, завирусившийся на книгах и статья без каких либо серьезных достижений, серьезные работы которого особо негде посмотреть. Ну т.е. типичный советчик. Далее, каких нибудь ну хоть сколько то объективных доказательств просто нет. А многие его советы не выдерживают критики. Но так должны думать нормальные инженеры, а для большинства нужен вайб и хайп. Clean Code модный - значит будем его внедрять. Это касается не только данной темы.
Удивляет только что такой хренью начали страдать в геймдеве. В энтерпрайзе то это все расцвело потому что так программист мало за что отвечает. Будет тормозить не вывозить - это проблема заказчика, пусть серверов докупает. А мы художники, мы высокими архитектурами занимается по книжками.
Здесь как в том анекдоте: и ты прав, и ты прав, и ты прав.
Это практически как пример из классической философии. Положим программа в ходе своей работы нарисовала кучу квадратиков. Что делает код? Кто-то скажет, что код рисует кучу квадратиков. А кто-то скажет, что код решает (условно) бизнес-задачу. Кто прав? Что же код делает на самом деле? А есть еще третий кто-то, четвертый и т.д. И, оказывается, все правы и код на самом деле все это и делает. Проблема в том, что хотя классическая философия и говорит, что, ну, да, оно как-то все вот так, она ничего не говорит, что же делать когда разные "на самом деле" приходят в конфликт. Точнее, она нас научила тому, что в непрекращающихся войнах вокруг этих конфликтов и происходит движение, но жить от этого не проще.
Перекос в сторону идей "Чистого кода" произошел потому, что дядя Боб разговаривает на языке пиджаков, со всеми вытекающими. Спорить с этими идеями с позиций производительности непродуктивно, потому что это другая категориальная система. У пиджака всегда есть железный аргумент: знаете, какой код самый быстрый? который не выполняется, он требует нулевого времени. В частности код, который не выполняется, потому что его никто и не собирается выполнять.
Помимо общих аргументов, у высокоуровневых идей есть более конкретный резон. Например, выражается в виде максимы "скороспелая оптимизация - корень зла". Разумеется, пытаться ее пропихивать как некую абсолютную идею - неосмотрительно, но, я думаю, мы все сталкивались с ситуацией, когда заоптимизированный код превращался в дикую занозу, потому что условия выполнения слишком кардинально изменились. Очень легко показывать ускорение, когда данные реализуются в виде просто индексируемого массива. А что делать, если в новых условиях данные оказались серией пользовательского ввода? Переписывать простыни кода, которому функционально вообще до фонаря была природа реализации данных? Разумеется, пример утрированный, но, надеюсь, проблему иллюстрирует.
Проблема со скороспелой оптимизацией в том, что не всегда легко сказать, когда же наступил тот момент, что она перестала быть скороспелой. Утрируя, позиция дяди Боба в том, что такой момент никогда не наступает. Другое дело, что инженеры на то и инженеры, чтобы не слушать, какого-то дядю, который сидит неизвестно где, а видеть то, с чем им приходится работать собственными руками. Видеть то, что Кнут назвал критическими тремя процентами. С этих перспектив "чистый код" представляется довольно небесполезной системой почти формализованных ограничений. По крайней мере, с такими ограничениями проще справляться, чем когда доступны только такие-то и такие-то марки стали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жертвы чистого кода