Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 121
Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – 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К").
Дать разработчикам компьютеры действующего среднего уровня
У разработчиков IDE не тормозит.
Быстрее. За счёт графики уровня Doom2. Во время разработки игра тормозит даже на топовых комплектующих. Разработчики все 2-3 года созерцают своё творение, обычно, в 5-10 фпс. Давайте им ещё уполовиним.
нужен ли нам перформанс инженер
а что такое перформанс инженер? Промт-инженер слышал! перформанс инженер - это что-то новенькое, даже в 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
Имеется ввиду "не помещается", а не "напишите это перьевой ручкой на пергаменте"
Другой вариант этого же правила - функция должна помещаться в один экран
Функция должна выполнять свою работу, а не помещаться на какой-нибудь там экран. Экраны тоже бывают разные, на 5" и на 50" экраны вместится радикально разное количество строчек.
Я лично видел в своей практике функцию строк на 500, и дорабатывал её. Импорт договоров из экселевского файла. Красивее бы она стала, если её распихать на 50 отдельных функций, и вместо условного "row[inn] = (int)row[inn]; if strlen(row[inn]) != 11 throw new Exception..." было бы "checkInn(row[inn])"?
Просто в результате вместо одной легко читаемой последовательно простынки было бы 50 носовых платков, каждый из которых невозможно переиспользовать, а надо собирать их и стирать их всей кучей. Зато кому-то это покажется красиво и структурированно. Можно и "2+2" заменить на вызов функции "sum(2,2)".
А вот серваку вызов полусотни абсолютно лишних функций совсем скорости не добавит. В проде бывавает и так, что с СИ на асм соскакивают, чтобы миллисекунды выгадать.
Эге, коллега!..
Ну, не на 50, а на 5 функций можно бы и разбить.
А лучше (сильно лучше) перевести подобный импорт на систему из шаблонов, которые задаются — да хоть в текстовом файле! Потому что один человек дописывает к этой полутыще строк if{}, другой тоже... — и вот у вас через 5 лет не 500 строчек, а 2500 — и это именно наш случай. И только сейчас добрались до переделки :)
Такие функции на 500 строк имеют дурацкую привычку разрастаться до 5000 строк.
И если для функции на 500 строк может быть несколько человек, которые хоть приблизительно понимают, как она работает, где тонкие места в ее логике / производительности, какие есть баги, и так далее, то в функции на 5к строк таких людей уже нет по определению
“row[inn] = (int)row[inn]; if strlen(row[inn]) != 11 throw new Exception…” было бы “checkInn(row[inn])”
Выглядит как код на С++, написанный в стиле Си, что само по себе не очень хорошо пахнет в большинстве контекстов.
Просто в результате вместо одной легко читаемой последовательно простынки было бы 50 носовых платков, каждый из которых невозможно переиспользовать,
Смысл деления на функции не только в том, чтоб их можно было переиспользовать, но и в том, чтобы:
Декомпозировать код на части, каждая из которых выполняет свою задачу, и дать этой части внятное имя.
Ограничить контекст, в котором код выполняется.
И то, и другое нужно как раз для того, чтоб в коде было быстрее и проще понять, что происходит. Даже если код читается так же легко, как приключенческий роман, то для того, чтоб понять, что происходит в функции, (и найти место, которое ему нужно поправить) человеку придется прочитать все 500 строк кода, и к тому моменту, когда он дойдет до конца, он уже забудет, что конкретно там было в начале.
Так устроено человеческое мышление: человек не может удерживать в кратковременной памяти больше, чем 7±2 вещей. В простыне будет и сложнее найти нужное место в коде, и проще совершить ошибку из-за слишком большого контекста, о котором стоит помнить.
А вот серваку вызов полусотни абсолютно лишних функций совсем скорости не добавит.
Это на каком языке нужно писать, чтобы беспокоиться о влиянии на производительность лишних вызовах функций? В любом приличном компилируемом языке программирования компилятор сам заинлайнит вызовы функций, если это будет сулить какой-никакой выигрыш по производительности. А если писать на каком-нибудь питоне, то ты уже отказался от высокой производительности в пользу скорости разработки.
Ограничить контекст, в котором код выполняется.
Но ведь для этого не обязательно разбивать большую функцию на функции? Можно разбить функцию на кодовые блоки, чтобы в конце блока переменные выходили из видимости.
fn my_big_func() {
{
// do thing A
}
{
// do thing B
}
{
// do thing C
}
}
В простыне будет и сложнее найти нужное место в коде, и проще совершить ошибку из-за слишком большого контекста, о котором стоит помнить.
Тут зависит от того, какая задача стоит перед программистом.
Если программисту для того чтобы решить свою задачу нужно прочитать фунцию полностью, то “простыня” будет читаться проще, чем вызов большого количества маленьких функций. Ему придётся прыгать вверх-вниз по коду, читая каждую такую функцию.
Если же программисту не обязательно для своей задачи понимать функцию полностью, то ему наверное будет проще с подходом, где большая функция разбита на маленькие. Он увидит вызов doThingA() и решит “окей, тут делается вещь А, глубже читать не буду” (замечу, только при условии что имя у функции понятное и полностью отражает её содержимое!).
Вопрос в том, что чаще встречается - задачи для которых не нужен полный контекст функции или задачи для которых он нужен?
Но ведь для этого не обязательно разбивать большую функцию на функции? Можно разбить функцию на кодовые блоки, чтобы в конце блока переменные выходили из видимости.
Да, это действительно альтернативный вариант (хоть я и не так часто встречал такое в реальном коде). И это уже лучше, чем иметь непрерывную простыню.
Хотя на мой взгляд, есть у этого и минусы по сравнению с функциями. Как минимум, функциям можно дать красноречивые названия, описывающие происходящее.
Если программисту для того чтобы решить свою задачу нужно прочитать фунцию полностью, то “простыня” будет читаться проще, чем вызов большого количества маленьких функций.
Мне кажется, грамотное разбиение на функции делает код более понятным, даже если программисту нужно прочитать все. Представьте, что вам нужно изучить статью на 10 страниц текста. Вам будет проще, если у статьи будет оглавление и четкая структура, разбитая на именованные разделы, или же если статья будет сплошной простыней текста, без всякой структуры?
С кодом ведь точно так же, хорошо структурированный код проще воспринимать, по нему удобней ориентироваться.
Ему придётся прыгать вверх-вниз по коду, читая каждую такую функцию.
Это разве проблема в современных IDE/редакторах кода? Обычно для того, чтоб перейти к определению фукнции или вернуться обратно, достаточно нажать одну-две кнопки.
Как минимум, функциям можно дать красноречивые названия, описывающие происходящее.
Ну, никто не мешает перед блоком написать комментарий, который описывает что в нём происходит. ИМХО это даже лучше, потому что с функцией всегда мучение из разряда “как мне в коротком и при этом понятном английском предложении выразить суть?”. С комментарием такой проблемы нет, потому что это просто естественный текст, не ограниченный по размеру.
Вам будет проще, если у статьи будет оглавление и четкая структура, разбитая на именованные разделы, или же если статья будет сплошной простыней текста, без всякой структуры?
В этом я с вами согласен, просто разбиение на функции это не единственный способ структурирования большой функции. Как я писал выше, это может быть разбиаение на блоки+комментарий к каждому. Или более примитивное - перед каждой секцией кода писать комментарий, который объясняет что секция делает.
Обычно для того, чтоб перейти к определению фукнции или вернуться обратно, достаточно нажать одну-две кнопки.
Для меня не проблема что это долго, скорее что у вас не вся логика перед глазами. То есть в каждый момент у вас перед глазами какая-то маленькая функция и вам нужно держать в голове какая там логика в месте её вызова. И наоборот, когда вы смотрите на место вызова, выам надо держать в голове что делает каждая маленькая функция. А если у вас перед глазами “простыня”, то вся логика как на ладони.
(Ну и понятное дело что если какая-то логика повторяется, то мы её вынесем в функцию в любом случае, DRY всё такое; но это я скорее на всякий случай уточняю).
Никто вам не мешает заинлайнить вызовы функцийтипа sum в c++ для этого кстати ещё и макросы есть.
Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем астракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата.
Ну да, основная фича КлинКода для энтерпрайз приложений в том, что можно заменить любого на любого и он поймет что там происходит. Таким образом можно выгнать гения, когда он написал и отладил систему и посадить макаку её поддерживать.
del
Не посадить макаку его подерживать - а обеспечить высокую скорость внесение исправлений, при минимуме проблем которое внесет это изменение. При этом код не должен в течение 10 лет его эксплуатации стать порталом в ад. К стати если посадить макаку - то она из понятного и структурированого кода тоже портал в ад быстро сделает. Я как понял это статься относится к
В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции.
то есть там где на ради оптимизации готовы на траты времени и готовы жертвовать обслуживаемостью кода. Да там идеи дядюшки Боба несколько опасны.
PS Я не являюсь явным поборником идеалогии Clean Code - но она должна жить. Есть проекты, где ее использования (без излишнего фанатизма) приносит реальный результат. При этом я явно против тех, кто считает если ему удалось написать вычесление факториала в 1 строку, который только он понять может и на который от потратил пару человеко-месяцев рабочего времени - то остальные просто какие-то макаки.
Сам работаю с подобной системой уже почти 10 лет.
Основная проблема там зсключается в том, что через 2 года ты сам забываешь, что этот код когда-то писал ты сам (возможно в плохом настроении или болел). А узнаёшь это открывая историю коммитов ))
Но для программистов, которые за 10 лет сменят 10 работ в разных сферах толком не понять этого т.к. своего кода 10-и летней давности они не увидят толком никогда.
Проблема в том - что да код забываешь и не за 2 года - а значительно раньше. Помнишь логику или общий подход. Программисты меняются тоже не по своей воли. Они как правило ресурс. И если у всех их будет разный подход - то операции с ресурсами становится проблематичными. Но это не самое главное. У бизнеса ну просто часто меняются требования. Причем кардинально. А за 10 лет система может претерпеть такие изменения - на одной и той же команде!!!! В видео кодеках (где я работал) и играх ситуация другая. Там стандарты годами прорабатываются не менеджерами и специалистами и нарваться на какую-то дичь из-за которой приходится систему если не на 360 или 180 градусов переделывать - то 12 или 6 раз на 30 градусов практически не реально. Поймите чистый код - это не про скорость и потребление ресурсов - а просто методика по которой можно угнаться за дичью от бизнеса.
for (Entity* e : scene.getAllEntities()) e->getTransform()->update(dt);
Справедливости ради, это не чистый код от слова вообще. Как минимум нарушен принцип Деметры, ну и в целом, это сделал какой то диверсант.
Непонятно, в чем претензия. Clean code разве обещает высокую производительность в играх? Нет. Код в таком стиле является более поддерживаемым? Является. В чем проблема-то?
Если что, я не согласен со многими советами из этой книги. Но логика статьи всё равно непонятна.
Чего ж тут непонятного? Дядя Боб же испортил все программирование на годы, а сам развлекается там в омериках на пенсии. А у нас тут в геймдеве разброд и шатание из-за его книжек 20 летней давности. От того, что мы доверчивые бездумно. Привыкли под авторитеты безоговорочно ложиться.
идеи то правильные, но не надо бездумно тащить в дом все что найдено, иначе дом превращается в свалку
Главное достоинство его книги, это не про чистый код, тестируемость, расширяемость и поддержку, это про то, что большинство разрабов пишут убогий и страшный код, который поддерживать невозможно. Объяснять им как писать правильно: для начала хотя бы выделять функции , долго муторно и все равно не поймут.
В этот момент можно взять «чистый код» пихнуть в «морду» и сказать пиши вот так. Если побежит жаловаться менеджеру- то тут ПР Товарища Мартина тоже поможет- мы же не против, сложившихся практик, мы за расширяемость … - нужное подчеркнуть.
Для человека который боле -менее нормально пишет ничего нового/интересного в в книге нет. Но таких, к сожалению не много …
Так корень проблемы не в книге или её авторе. А в тех, кто относится к ней как к Библии. Не будь этой книги, они нашли бы другую.
Просто не нужно прямо следовать всем советам из книги (если мне память не изменяет, в книге так и написано).
Спасибо за статью. Возник вопрос по поводу сайта на github pages: почему именно итальянский был выбран третьим языком для статей? Из чистого любопытства интересуюсь, выбор показался весьма неожиданным
самое интересное, что у вас всего 2 маленьких примера, и буквально всё.
нет ни замеров, ни конкретных примеров почему тот или иной подход не совсем приятный.
у Кейси Муратори свой клин код, у Дяди Боба свой клин клод. у них у обоих клин код.
они оба говорят об одном и том же, Кейси говорит за минимализм без оверинжинирга, но на С писать не удобно, значит чуть по-выше это классы/деструкторы.
Статья хорошая, я бы сказал проблема даже шире.
Она не только с чистым кодом (дедушка Мартин вызывает сомнения своими советами со стартом), но в целом к границам применимости подходов и методологий.
У всего есть границы применимости и проблемы, которые оно решает.
И вот уже у людей странные требования к ООП, абстрактные зависимости, идеально быстрый ECS везде, нет синглтонам, AoS, SoA, паттерны, интерфейсы, браузер внутри, блеать, всего, виртуальные машины на виртуальных машинах и своя собственная, Тьюринг полняя, но плохая реализация LISP.
Причем все сразу.
Потому что эти рекомендации перешли из пространства решений в пространство ритуала и потеряли связь с ограничниями.
Потеряли важный фактор того, что оно не бесплатно, и если ты делаешь что-то просто так, ты платишь без отдачи.
Сами по себе рекомендации не бесполезны конечно, мысль про то, что хорошая архитектура может чего то стоить, как и то, что ультра оптимизированный код хер прочитаешь и логичная и подтверждается опытом.
Но все хорошо в меру.
спорить приходится уже не про абстрактную “чистоту”, а про конкретные наборы приёмов конкретного автора
Да, про конкретные приёмы можно спорить, но это не так интересно. Интереснее вопрос, должен ли код быть чистым в принципе или нет. Я считаю, что да, хотя конкретика конечно не как у апологета. Как считаете вы я не совсем понял.
Проблема в том что большинство программистов, последнее время пафосно направо и налево называющих себя инженерами, никакого отношения ни к понятию инженерного дела ни к понятию прагматизма не имеют. Уже давным давно балом правит хайп.
По хорошему, человек который прочитал Clean Code и думающий его внедрять, должен задаться вопросами: а кто такой автор книги и какой у него опыт и можно ли посмотреть его проекты, а если ли доказательства эффективности предлагаемых им методик, наконец провести мозговой штурм с коллегами проверяя это все на прочность. И тогда неожиданно выясниться что Мартин - обычный хайпожор, завирусившийся на книгах и статья без каких либо серьезных достижений, серьезные работы которого особо негде посмотреть. Ну т.е. типичный советчик. Далее, каких нибудь ну хоть сколько то объективных доказательств просто нет. А многие его советы не выдерживают критики. Но так должны думать нормальные инженеры, а для большинства нужен вайб и хайп. Clean Code модный - значит будем его внедрять. Это касается не только данной темы.
Удивляет только что такой хренью начали страдать в геймдеве. В энтерпрайзе то это все расцвело потому что так программист мало за что отвечает. Будет тормозить не вывозить - это проблема заказчика, пусть серверов докупает. А мы художники, мы высокими архитектурами занимается по книжками.
Уже давным давно балом правит хайп.
Полностью согласен, прагматиков один на сотню. Это вижу и с архитектурами и с методологиями и с инструментами и с ИИ. А теперь, особенно, с ИИ. Когда в меня команда кидает маркетинговые твиты, а СТО на мои вопросы о том, как мы это будем поддерживать, кто будет нести ответственность и кто вообще будет понимать, что там происходит внутри сервисов, написанных агентами, отвечает "оно сейчас везде, оно сейчас повсюду", то руки уже просто опускаются. Также было с чистой архитектурой, также было и с методологиями. Кажется, мне нужен психотерапевт
причем тут автор? идея норм если разобраться
Здесь как в том анекдоте: и ты прав, и ты прав, и ты прав.
Это практически как пример из классической философии. Положим программа в ходе своей работы нарисовала кучу квадратиков. Что делает код? Кто-то скажет, что код рисует кучу квадратиков. А кто-то скажет, что код решает (условно) бизнес-задачу. Кто прав? Что же код делает на самом деле? А есть еще третий кто-то, четвертый и т.д. И, оказывается, все правы и код на самом деле все это и делает. Проблема в том, что хотя классическая философия и говорит, что, ну, да, оно как-то все вот так, она ничего не говорит, что же делать когда разные "на самом деле" приходят в конфликт. Точнее, она нас научила тому, что в непрекращающихся войнах вокруг этих конфликтов и происходит движение, но жить от этого не проще.
Перекос в сторону идей "Чистого кода" произошел потому, что дядя Боб разговаривает на языке пиджаков, со всеми вытекающими. Спорить с этими идеями с позиций производительности непродуктивно, потому что это другая категориальная система. У пиджака всегда есть железный аргумент: знаете, какой код самый быстрый? который не выполняется, он требует нулевого времени. В частности код, который не выполняется, потому что его никто и не собирается выполнять.
Помимо общих аргументов, у высокоуровневых идей есть более конкретный резон. Например, выражается в виде максимы "скороспелая оптимизация - корень зла". Разумеется, пытаться ее пропихивать как некую абсолютную идею - неосмотрительно, но, я думаю, мы все сталкивались с ситуацией, когда заоптимизированный код превращался в дикую занозу, потому что условия выполнения слишком кардинально изменились. Очень легко показывать ускорение, когда данные реализуются в виде просто индексируемого массива. А что делать, если в новых условиях данные оказались серией пользовательского ввода? Переписывать простыни кода, которому функционально вообще до фонаря была природа реализации данных? Разумеется, пример утрированный, но, надеюсь, проблему иллюстрирует.
Проблема со скороспелой оптимизацией в том, что не всегда легко сказать, когда же наступил тот момент, что она перестала быть скороспелой. Утрируя, позиция дяди Боба в том, что такой момент никогда не наступает. Другое дело, что инженеры на то и инженеры, чтобы не слушать, какого-то дядю, который сидит неизвестно где, а видеть то, с чем им приходится работать собственными руками. Видеть то, что Кнут назвал критическими тремя процентами. С этих перспектив "чистый код" представляется довольно небесполезной системой почти формализованных ограничений. По крайней мере, с такими ограничениями проще справляться, чем когда доступны только такие-то и такие-то марки стали.
Это практически как пример из классической философии. Положим программа в ходе своей работы нарисовала кучу квадратиков. Что делает код? Кто-то скажет, что код рисует кучу квадратиков. А кто-то скажет, что код решает (условно) бизнес-задачу. Кто прав? Что же код делает на самом деле? А есть еще третий кто-то, четвертый и т.д. И, оказывается, все правы и код на самом деле все это и делает.
Это вполне хорошо формализованная задача формальной семантики. Рисование кучи квадратиков – это операционная семантика, а решение бизнес-задачи – денотационная. Они могут быть поставлены в разных эвивалентных формулировках. Но думать в эту сторону не очень поощряется, так как слетает весь маркетинг и надувание щёк авторами методик разработки, а теперь ещё и нейросети могут быть в числе пострадавших. Так и до ТеХа вместо майкрософт офиса докатиться можно, а это какие убытки для отрасли!
Не хочется менторствовать, но разработка игр не всегда равно разработке движков для игр. Для разной скриптовой логики смысл вполне имеется.
Статья интересная. Но общая суть Чистого кода гораздо проще и очевиднее. Просто книга написана для США - а там принято растекаться текстом по мысли..
Суть - программирование - это искуссстаот ограничений а не абстракций, а задача ограничений в управлении сложностью. И это все. Все остальное это сугубо личный взгляд дядюшки Боба в конкретной ситуации.
То ксть, каким образом это достигается - зависит только от знания языка и внутренней разрешительной системой программиста
писал коммент с телефона - аж читать стыдно..
Суть - программирование - это искусство ограничений а не абстракций, а задача ограничений в управлении сложностью. И это все. Все остальное это сугубо личный взгляд дядюшки Боба в конкретной ситуации.
То есть, каким образом это достигается - зависит только от знания языка и внутренней разрешительной системой программиста
Это та книга, где советовалось передавать аргументы в методы через свойства класса? )
Тут нужна небольшая поправка к тексту статьи и почему не стоит бросаться использовать примеры из красной книги у себя в проекте. Когда Мартин писал Clean Code (2008), он уже много лет занимался не только разработкой, но и консультированием команд
Тут нужна небольшая поправка к небольшой поправке. Собственно разработкой Мартин прекратил заниматься в 1991 году, и сам никогда не применял в реальном производстве ПО те принципы, которые проповедует. Они являются переосмыслением его опыта написания спагетти на Фортране 77, Коболе и PL/I.
Сапожник без сапог?.. А почему его вообще, в таком случае, кто-то воспринимает всерьёз тогда
Ну сам по себе тот факт, что одни люди пишут код, а другие - учебники, ещё ни о чём не говорит. Просто не надо воспринимать прочитанное как догму. Это всего лишь светлые утопические идеи, каких в истории было немало. С неочевидными на первый взгляд минусами.
В данном случае минусом является размывание прикладного кода по слоям абстракций. Типичный косяк неофитов ООП.
Просто не надо воспринимать прочитанное как догму.
Проблема в том что большинство думать не хотят но хотят воспринимать все проще, как догму и будут так воспринимать. Поэтому мы и наблюдаем как сообщество десятки лет безуспешно пытается научиться пользоваться ООП, веря что ну должно же оно все проблемы решить. Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом. Потом Clean code. Потом пришло безумие повального функционального программирования. Затем микросервисы. Потом DDD-шиза.
Потому что много думать - много грустный. Все хотят чудо решение.
Кстати, применение ООП, по моему опыту, резко уменьшает производительность. Везде ли стоит его применять? Вот вопрос...
Если речь про производительность программиста, то по моему опыту снижает на начальном этапе и увеличивает потом. В целом скорее увеличивает. Это всего лишь очень удобный способ структурировать модель предметной области.
Просто не следует тупо следовать заветам вроде "В методе класса не должно быть более 5 строк" или упарываться по поводу всяких SOLID до упора. А то посмотришь на структуру классов в некоторых проектах, а тем уже непонятно вообще, зачем все эти классы, и что каждый из них реализует, поскольку поделено не по смыслу, а по формальным правилам.
Если речь о производительности программы, то таки да, может сильно снижать. Но тут тоже сильно помогает отказ от тупого следования догмам и совмещение разных парадигм программирования.
Сорри, я не уточнил. Да, речь шла о производительности программы. А так вообще - лично я не люблю ООП как идеологию и стараюсь максимально уменьшить ее использование. К сожалению, под Виндовс совсем без нее обойтись не получается, но хоть как-то стараюсь...
Везде ли стоит его применять? Вот вопрос...
С одной стороны я бы ответил что однозначно нет! Но с другой стороны я совершенно не знаю что для вас значит ООП, у меня есть например такая интерпретация - воспринимайте любую сущность необходимую вам для программирования как Объект Вашего Внимания, и тогда без ориентированности на эти Объекты нам не обойтись.
Кстати, применение ООП, по моему опыту, резко уменьшает производительность. Везде ли стоит его применять? Вот вопрос...
Я пришел к тому ООП это очень местечковая история, и главная проблема - это пыпытка на нем делать все. Из того где это может быть полезно это оборачивание ресурса для управления его жизненным циклом и небольшие стейт-машины на уровне кода, где состояние не выходит за пределы объекта.
Мне кажеться что проблема ООП не только в производительности но и в самой чужеродности подхода попытки все представить объектами при исполнении программы.
Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом.
ну не скажите, там например рассматривается задача как спроектировать редактор текста как типовая задача, это что задача конкретных людей? Есть кто-то кто не пользуется редактором текста? А если знать как правильно построить редактор текста, то можно использовать это знание чтобы построить редактор чего угодно. Там рассматривались фундаментальные задачи. С таким же успехом можно говорить что Нильс Бор, например, решал какие-то конкретно свои проблемы, а Эйнштейн написал
набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени
которые тоже (непонятно почему) стали культом.
А если знать как правильно построить редактор текста
А что, есть правила построения редактора текста? От которых нельзя отступать? Редакторов уйма, все разные. Только я написал целых два текстовых редактора, совершенно разных как по функциям, так и по внутренней организации. Так что не очень понятно, о чем речь? Кстати, графические редакторы - это совсем другое. А редактор шрифтов я еще под ДОС писал - это совсем другое...
Кстати, графические редакторы - это совсем другое.
насколько я помню и понимаю, там как раз про графические редакторы, которые обладают полной функциональностью включая масштабирование и раскраску, и вариативность стилей, вы пробовали такие делать?
Тут как раз важна сложность задачи и универсальность ее решения. Действительно, если урезать эту глобальную задачу с разных сторон, то можно получить неограниченное количество более простых задач и, соответственно их решений, но решение самой общей и полной задачи задает некоторые стандарты и определяет некоторые обобщенные приемы проектирования. Это как я это понимаю и если вам действительно интересен мой ответ на ваш очень интересный (действительно!) вопрос, вопросы!
там проблема как с созданием своего УИ, походу да есть тонкости именно по удобству, но минимально допустимой ценой, текстовый редактор еще ничего.
текстовый редактор условно рисует квадратики, УИ тоже, но там есть метод кода лапши, который не хочется писать/читать, а если более оптимальный на обьектах, но с ООП, да чутка теряем в производительности, но удобство перекрывает всё в этот момент...
А из минимально вменяемых редакторов текста при этом - остался один emacs, автор которого точно этих советов не читал.
ну не скажите, там например рассматривается задача как спроектировать редактор текста как типовая задача, это что задача конкретных людей? Есть кто-то кто не пользуется редактором текста? А если знать как правильно построить редактор текста, то можно использовать это знание чтобы построить редактор чего угодно. Там рассматривались фундаментальные задачи. С таким же успехом можно говорить что Нильс Бор, например, решал какие-то конкретно свои проблемы, а Эйнштейн написал
В книге знаний людей по конкретным темам в конкретный исторический период. У автором богатый опыт создания графических редакторов теста, поэтому про редактор и писали и про остальное, а не про фундаментальную философию разработки чего угодно. И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время. Этот опыт действительно очень обобщенный и может применяться в разных ситуация но это капля в море в мире проектирования различного софта.
Это я к чему, не к тому что оно плохое а к тому что люди воспринимают это как библио которая даст ответ на все вопросы. Не даст.
опять же если вам действительно интересно:
И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время.
я думаю 23 это число действительно взятое с потолка, просто потому что это была первая попытка сформулировать! Не факт что эта работа теперь не засекречена и мы просто не знаем окончательный результат! Но то что есть фундаментальные паттерны разработки софта (а не вселенной), это не подлежит сомнению, по моему, их можно сформулировать и 15 и 45 и 23 тоже очень хорошее число на мой взгляд, вопрос в том как мы их будем формулировать! То есть есть ли кому у нас их формулировать при таком отношении. Ведь те кто их сформулировали смогли создать множество абсолютно комерчески-успешных продуктов! Заметьте до сих пор успешных! Те кто формулирует эти фундаментальные паттерны разработки софта не надеются что какое-то мифическое сообщество энтузиастов (в общем то не профессионалов) напишет за них код который они будут выгодно продавать как собственный продукт.
Не знаю, по какой причине, но сейчас фактически не принято делать оптимизацию кода. "Не тянет железо? Купи новое!". Оптимизация требует времени программиста. Продукт выйдет позже. Плохо для бизнеса. "Пусть новое железо покупают". Почему Вин10 на моем компе с 8Г ОЗУ работала нормально, а Вин11 висит до озверения?
У меня привычка к оптимизации еще со времен даже не ДОС, а советских ПМК, где в 100 байт памяти нужно было уложить сложнейшие алгоритмы. Хорошая была школа.
Так вот, мой текстовый редактор сначала шифровал файлы при сохранении "в лоб". И на больших текстах это стало крайне долго. Следующую версию я решил все же оптимизировать. Стало мгновенно. Да, потратил время и мозги. Но зато работает как надо!
Про книгу о чистоте кода не скажу, пишу не в команде и никому ничего объяснять не нужно. А понятия о красоте кода, наверно, у каждого свои...
Вы требования к win12 посмотрите, совсем весело/грустно станет.
Оптимизация - это от 'нищеты', пока проблема нехватки ресурсов существовала, оптимизировали и другого не знали, а как настало изобилие, так перестали тратить на это время.
Плюс, специалисты 'старой школы', те кто споткнулся о нехватку ресурсов, становятся все большей редкостью (точнее их изначально не хватает на стремительно растущую индустрию) вот и получаем результат.
Советы - посадить разработчиков на слабое железо, вредные, потому что там банально инструментарию требуется больше ресурсов, а если ресурсов мало, то банально работать эти инструменты начинают сильно медленно, это становится уже заметно в денежном эквиваленте. Можно конечно давать разработчику два физических устройства (условную тест машину, специально слабую) и заставлять тестировать все там,.. не уверен что это будет иметь пользу.
Вижу некоторую путаницу в понимании "чистого кода".
У меня есть проект, работающий с биржами, который непрерывно качает и обрабатывает кучу данных. О том, чтобы держать их во время работы в БД даже речи не идёт, это будет просто провально по времени.
Но можно классически организовать хранение в виде объектов/классов - это типичный подход, который родит очень удобный и безопасный код, но он будет работать на 20-30% медленнее ручной обработки с указателями и выделением памяти.
Пример в статье с массивами будет простым, пока массив один, а когда этих массивов десятки, и размер их непрерывно растет и в каждой записи массива еще по несколько массивов и указателей и т.п., то внезапно однажды "чистый" код становится "грязным", т.к. через какое-то время там настолько всё будет наворочено, что будет сложно понять, как это работает. Хотя, при этом, этот код всё так же будет более быстрым.
Для себя я выберу более быстрый вариант, хотя он потребует в разы больше времени, но при разработке на сторону я бы 100 раз подумал.
А они так не умеют, так умеют некоторые экспериментальные нейронки от Intel, но они стоят запредельно дорого.
какие это экспериментальные нейронки интеля?
если бы у них были топовые агенты кодирования, они бы уже во всех бенчмарках бы наследили, ибо деньги от сюда полезут просто огромные.
могу только общее рассказать, ибо остальное под NDA. В рамках сотрудничества с синими нам дали доступ к плагину для vtune, который оптимайзит выбранные участки. Наш гуру асма грустит, ибо он потратил на тот код две недели чтобы его ускорить в полтора раза, а нейронка его ускорила за час в два раза. Но ничего другого плагин не умеет, пока не умеет, да и оптимазить больше 2к (пока) инструкций тоже отказывается
Агенты кодирования нужно исследовать не на том чего они умеют, а на том где они ломаются.
Я в шоке от слабой qwen3.6-35b-a3b (3 миллиарда активных параметров, это почти ничего!), она в режиме агента иногда способна на чудеса, но чаще - творит дичайшую дичь...
и чем больше одно относительно второго - тем круче модель.
как мы докатились до того что нда цель ответа, на ключевые моменты самого докладчика статьи, зачем тогда вообще статью писать, о чем не можем рассказать/доказать/показать суть искажается при кусковом обзоре же...)
Вероятно автор статьи либо не читал, либо не понял "Чистый код". Собственно в статье нет ничего по сути чистого кодирования, кроме апелляции к частным случаям трудностей оптимизации. Попробую объяснить суть, немного утрируя. Предположим, что противоположность "чистого кода" - "вонючий код". Это когда задача решена, и может быть даже достаточная производительность была достигнута. Но, код получился настолько вонючим, что никто не захочет его трогать, даже сам автор некоторое время спустя. Код более не оптимизируется, более не поддерживается. Это как раз тот случай, когда хочется "всё удалить и переписать заново". И это проблема. Потому что удваивает стоимость *продолжения* разработки. Книга предупреждает об этом, пытается привести много способов (на данный момент немного устаревших) этого избежать. Но сам принцип всё ещё верен.
И читал и понял, и применял, и могу сравнить разные подходы. Мартин про управление сложностью через ооп-абстракции, но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится "вонючим" как вы выразились и невыносимым для поддержки через год. Когда у вас граф зависимостей разрастается до такой степени, что никто не понимает, как данные текут через систему, это и есть результат слепого следования букве книги, а не реалиям разработки. Задача хорошего разработчика найти баланс, чтобы код остался понятным и расширяемым, не превращаясь в "лапшу" из виртуальных вызовов и аллокаций. И это не всегда ООП и не всегда чисто в редакторе. Про устаревшние способы тоже верно, и это один из аргументов не тащить наследие. Есть более современные авторы Фабиан и Найстром, которые пишут как выбраться из этого оопешного ада, и книга Оустерхаута, которая показывает недостатки стиля Мартина.
как выбраться из этого оопешного ада
Я вижу у вас какую-то излишнюю избирательность в терминах. Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения. Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами). И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода. "Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать. Не бывает "излишне чистого кода", или "лучшего" с вашей точки зрения, но "не очень чистого". "Чистый код" по определению самый лучший в вашей данной конкретной ситуации.
Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения.
Очень вольное обращение со словом объект. Да, и в ФП и в процедурном программировании можно упортреблять слово объект, но это структуры сгруппированных данных не более. Подход в этих парадигмах - есть отдельно функции а есть отдельно данные. Для ООП характерен стиль совмещения данных и функций, и хоть это тоже называется объектами, по смыслу это совсем иное чем объекты (структуры) из ФП и ПП.
Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами).
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:
- получить данные от клиента
- провалидировать
- послать запрос на обновление в БД
- вернуть данные клиенту
Никаких объектов тут нет. Попытка смоделировать и натягивать объекты на реальный мир это куда более сложная и более высокая абстракция.
И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода.
Замечательно что они появились и что они были настолько удачные что несколько десятков лет все пытались писать на них нормально, да так успешно что в последнее время в новых языках отказываются от этой парадигмы как базовой.
"Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
Возможно я ошибаюсь, но мне кажется, что именно логика ООП привела к организации программ в виде цикла событий и реакции объектов на эти события. В обычной ДОС логика была совершенно другой: программа выполнялась линейно, в нужных местах запрашивая действия пользователя. Но ООП под ДОС работало уже в логике реакции на события!
Сейчас есть только логика реакций на события (ООП). А мне кажется, что каждый вариант имеет свои плюсы и минусы. Но выбора сейчас нет...
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:- получить данные от клиента- провалидировать- послать запрос на обновление в БД- вернуть данные клиенту
Если заниматься одними CRUD'ами - то да. Если у вас танк порождает снаряд, снаряд обрабатывается физикой и когда-то потом наносит урон другому игроку - то это уже сложно переложить на плоский алогритм.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
Вопрос не имеет смысла: вообще все писать хотя бы нормально никогда не начнут. Но в целом появление ООП заметно улучшило картину, иначе эта парадигма не получила бы такого распространения.
Никаких объектов тут нет.
Очень сложно объяснить в рамках коротких комментариев дух ООП специалисту, который вероятно не начинал программировать в мире без ООП, буквально в машинных кодах, когда ассемблер был роскошью (никаких макроассемблеров!). Похоже моя точка зрения практически получается диаметральной. Я видел и практиковал жёсткие оптимизации, минимальный объём памяти, жил в мире когда ООП только-только стал возможным и писать поддерживаемый код - ЭТО было целью, а вовсе не оптимизация (все программы были достаточно оптимальными, чтобы работать на 286 процессоре 🫡 ). Представьте сотни программ и библиотек, быстрых, аскетичных, но которые практически невозможно использовать далее, даже в своих собственных проектах. 😭 Книги типа "Чистый код" как раз и формализуют процесс разработки, что бы ПО развивалось, в т.ч. другими людьми, и было бы свободным во многих смыслах.
Я начинал программировать в мире без ООП, но не замечал, чтобы до этого было сложно использовать библиотеки. Конечно, в машинных кодах это затруднительно, но зачем кидаться в крайности? Модульное программирование на языках высокого уровня вошло в употребление задолго до ООП.
Широкое повторное использование библиотек сделало возможным движение свободного ПО, а не какие-то технические приёмы.
Очень сложно объяснить в рамках коротких комментариев дух ООП специалисту, который вероятно не начинал программировать в мире без ООП, буквально в машинных кодах, когда ассемблер был роскошью (никаких макроассемблеров!). Похоже моя точка зрения практически получается диаметральной.
Из рассказовы вымышленного офицера: "Очень сложно объяснить военному , выступающему за гладкоствольные орудия, который вероятно не начинал воевать в мире без нарезных стволов. Буквально, с помощью бронзовых гладкоствольных пушек и ядер."
При всем уважении, не понимаю логику сравнения одного стиля программирования но с примерами из прошлого века с другим более современным, когда сейчас есть и ООП и процедурные и функциональные решения и сравнивать нужно их.
- получить данные от клиента
- послать запрос на обновление [чего?] в БД
- вернуть данные клиенту
Никаких объектов тут нет.
Клиент это объект. В коде он обычно не выражается, зато выражается объект “Пользователь”, который связан с клиентом. В строке про обновление тоже подразумевается объект, и в запросе обычно указывается первичный ключ этого объекта. Само понятие “обновление” подразумевает объект с состоянием и поведением, который мы рассматриваем как одно и то же в разные моменты времени, хотя его состояние (данные) может быть разным.
но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится невыносимым для поддержки через год
Это верно только конкретно для игр и аналогичных приложений, где есть условно однопоточный кадр, и нужно уменьшать latency. В высоконагруженных системах, где нагрузка в виде запросов по сети, удобнее запустить несколько контейнеров, чтобы увеличить throughput, а на Новый год добавить дополнительные. И там лучше иметь код, который проще поддерживать. А ваши низкоуровневые оптимизации не станут работать на Новый год быстрее в 10 раз, а останутся как были в лучшем случае в 2-3 раза.
А премию на Новый год вы предпочтёте получить или пустить на лишние инстансы?
Если использовать только ваши 3x оптимизации на одном инстансе, то никакой премии не будет, потому что система не будет справляться с потоком 10x запросов. 2/3 пользователей, которые хотели заплатить вашей компании деньги, не смогли купить товар. А скорее там будет не 3x, а 1.2x потому что на фоне одного запроса в БД оптимизации машинных инструкций занимают очень мало.
Согласен, что сетевой сервис масштабируется горизонтально, и там поддерживаемость важнее экономии трёх наносекунд в хотпасе, но «добавить контейнеры» тоже не бесплатная операция, это как раз ваша премия под НГ. И 2-3х это не про «10x на Новый год», а что на каждом уровне нагрузки нужно в 2-3 раза меньше инстансов и в базе, и когда доливаете под пик, поэтому экономия умножается на весь парк. И да, «поддерживаемый код» и «ООП по Мартина» не синонимы, ровно как «эффективный» не равно «быстрый».
А автор учитывает что есть игры где нет 30000 сущностей и которые могут себе позволить писать нормальный код? А то прям вижу как оправдываясь этой статьей гкодеры и к goto придут, чо, сэкономит нам 1Е-250 секунды на сущность, хотя мы делаем визуальную новеллу
Да пишите, никто не мешает. Хорошая игра не та, что идеально сделана, а та в которую играют.
Так вы же мешаете, своей статьей. Мне кажется здесь разговор не об идеальности игропроизводства, а об общем подоходе. Который вы вполне себе прямо призываете сделать максимально близким к железу, нет?
А вот когда напишите и пойдут фризы, а они пойдут, если вы делаете чтото сложнее крестиков-ноликоа... мы поговорим про чистый код, профайлер, и необходимость быть ближе к железу
Достойный ответ. Ну тогда пока что добавлю вас в список говнокодеров, присоединяйтесь к собратам по инфоцыганству:
https://habr.com/ru/articles/877844/
https://habr.com/ru/articles/733400/
https://habr.com/ru/articles/892320/
https://habr.com/ru/articles/1054314/ <= ваша статья.
Кстати, "goto" - штука очень удобная и хорошая, если его правильно использовать.
вы всё верно говорити, но приколы следующие и они фундаментальные.
взаимодействие кода с ОС
менеджмент памяти
подсчет ссылок, время жизни и владение, базовые примитивы/структуры/абстракции-контейнеры, покрыть это минимумом возможностей
математика не только настройка мат аппарата, а еще всё то, что даст удобство в разделе математики
всё это тестами еще покрыть, и то что ниже тоже после ввода в ядро.
апи какое-то
самое интересное это, когда сталкиваются 2 мира, стиль без абстракций и связок, но на самом деле тут идёт таже связь, просто её делает не компилятор, а человек
момент второй использование абстракций, как вы и написали пофиг на сотнютысячную наносекунду, например, в каком-то пазле.
когда происходит момент, а вот тут интересно, когда добавляется ко всем концепциям владение и менеджмент иерархией, вы же не хотите руками выбирать узлы, нет обычно хотят архитектурного удобства зарегестрировал иерархию, алгоритм её видит и учитывает позицию.
соотвтветственно получается всё зависит от задачи и желания, написать можно и DOD вы правы, а можно тоже самое написать с минимальным набором механик языка(тоесть да у языка есть механики!) и архитектурных подходов, где придётся знать какие-то тонкости!.
например, какой смысл писать готу сразу тут и щас на чистую, не имея версии без готу с подробным описанием в документации, что происходит. лично я так считаю.
так вот когда мы всё это связываем нить-концепция-смысл, укладываем в некую архитектуру, где механики языка либо изучены или подбраны. мы же не будем вводить как я выше пример привел. тоесть где-то придётся понять как согласовать стыки этих миров, например уи и клики в пазл, и прочее и прочее и чтоб удобно было, а в пазле, чтобы абстракции были удобные так скажем читаемые с докой наверно.
НО, всё это можно скипнуть и просто накатить весь пазл в одном цикле это безусловно и 3д так же можно написать, суть как раз в том, чтобы сохраняя накладные расходы, имея какие-то макеты(назовём их так) мы переиспользуем свою архитектуру и используем её лучшие качества, о которых мы позаботились в ядре так сказать, но 3д да можно тоже в дод написать, просто начать писать всё написать, и потом наверно рефакторить, потомучто дод - это очень много кода, где на словах мы делаем код для проца, а на деле окажется нужны vtable[], потомучто будут случаи с его преимуществом типо.
Итоги - всё в меру, нет смысла уходить в полный DOD, нет смысла уходить в оверООП, истина где-то посередине на стыках этих двух миров и на кончиках пальцев от механики языка типо.
А автор учитывает что есть игры где нет 30000 сущностей и которые могут себе позволить писать нормальный код? А то прям вижу как оправдываясь этой статьей гкодеры и к goto придут, чо, сэкономит нам 1Е-250 секунды на сущность, хотя мы делаем визуальную новеллу
Напомните, а за чей счет они могут себя это позволить?
Вот есть пользователь, в интересах которого, игра или вообще любое ПО должно работать оптимально. В интересах пользователя чтобы программы мало занимали, быстро и хорошо работали. В интересах пользователя, программист должен используя свои знания и умения этого достичь. Но программисту это уже давно не интересно - он пишет для себя любимого а потом идет мирится своим чистым кодом с другими программистами, потому что срать хотел как этим будет пользователь пользоваться. Ему интересно паттерны внедрять, писать хороший код и любоваться им. Именно благодаря такой философии мы сейчас имеет кучу железа огромной мощности и бескрайние просторы говеного софта который есть память не в себя и постоянно тормозит.
Как Ваш выше уже писали:
Хорошая игра не та, что идеально сделана, а та в которую играют.
На втором месте наверное это всетаки качество игры для пользователя и уже только потом удобство для самого программиста.
Pascal (и Delphi, языки Никлауса Вирта) не имеет проблемы бесконечной перекомпиляции огромных текстов связанной с включением заголовочных файлов. За счёт явного разделения интерфейсов и реализации.
https://www.alibabacloud.com/blog/42%25-boost-in-compilation-efficiency-a-practical-analysis-of-c%2B%2B-modules_601974 C++ модули решают проблему модульности довольно эффективно, но увы массово не прижилось. Особенно проблематично распространение сторонних библиотек.
"В настоящее время Alibaba Cloud Linux, или Alinux, является наиболее широко используемой операционной системой в Alibaba Cloud. В 2021 году OpenAnolis выпустила официальную версию Anolis OS 8 на основе продукта Alinux. В этой статье Цзэчжэн Ли , инженер-разработчик из Alibaba Cloud Intelligence Group, использует Alinux в качестве операционной среды, чтобы объяснить преимущества модулей по сравнению с традиционными заголовочными файлами. Он также приводит несколько примеров, демонстрирующих организацию проекта с модулями C++ и использование модулей для инкапсуляции сторонних библиотек или преобразования существующих проектов. Кроме того, он расскажет о применении модулей во внутренних проектах Alibaba Cloud, являющихся частью сообщества OpenAnolis. Код модулей C++20 стабильно работает в основной ветке Alibaba Cloud уже более полутора лет, сокращая время компиляции на 42%."
Да, в целом с посылом автора согласен. Для себя я решил так, есть места где уместны просадки скорости во благо удобочитаемости, а есть - где неуместны, причём эти места могут находиться в одном проекте в соседних файлах. Наверное, решать нужно в каждом конкретном случае индивидуально, в идеале разграничить правила в проекте на уровне договорённости с коллегами по типу: "это делаем красиво, потому что... , а это производительным потому что...", но по факту там кроме желания авторов проекта уж очень много переменных которые сказываются на качестве и красоте кода.
// "красивый" ECS-обёрточный слой добавил по 0.0008 мс на сущность
Подождите, но ECS - это же как раз и есть structure of arrays, где данные специально лежат в памяти друг за другом. Такой подход должен улучшать производительность, а не ухудшать. Особенно на большом количестве объектов.
Ecs тоже не бесплатен, он тащит инфраструктуру, обертки, вызовы и сложность. Если вам в конце кадра надо просто пройти по объектам сцены и сделать чтото простое, то ецс добавляет нагрузку а не убирает. Но вы уже не можете сделать это отдельно и приходится писать новую систему, выбирать когда он будет запускаться, Маркировать поле или заводить новое. А надо то было всего лишь использовать обычный цикл. Я про это
Жертвы чистого когда - это те, кто не понял книгу и критикуют на основании кода тех кто ее тоже не понял, но утверждает, что написал "чистый код".
В статье ни одного рецепта или метода чистого кода нет. Все примеры, либо кровавый интерпрайз, либо плохая работа програмиста.
Никто не мешает оформить и быстроработающий код по "чистому", так как "чистый код" не про решение задач программирования, а про оформление уже готовой программы.
В статье приведен пример, как художники для правки моделей запускают игру, т.е. буквально пересобирают ее с нуля что ли? особенно это актуально для архивов, где каждый ассет нужно поместить в свой контейнер, для крупных проектов это гигабайты...
Отчетливо помню из прошлого, для создания чего либо в игре, нужно брать инструмент тестирования, в идеале сам редактор, который позволяет в реальном времени править модели, текстуры, анимацию, и тут же смотреть как это будет выглядеть.
Да и для тестового запуска, нужно готовое окружение, что бы исключить всю необходимую подготовку (условно пропустить меню, не заставлять тестера вести персонажа к нужной точки в мирие, или условно - не требовать от него проходить игровой момент для достижения нужного состояния, условно боса не бить,.. помню для лентяев можно было выдать специального персонажа с админ-правами, который и телепортировался куда надо и убивал с 1 удара... так вот это неправильно, правильно - запускать игру сразу с нужным состоянием или планом его изменения).
Дядюшка Мартин красиво написал больше одной книжки. Clean Code про Java, которая тогда была исключительно про ООП в классическом его понимании. Подход для большинства вычислительных задач не применимый.
Вторая важная деталь - книжка написана и названа красиво, но куча моментов в ней очень спорные. Для того, чтобы это понять, надо много шишек набить. Попытки применять её части как обязательный шаблон череваты последствиями. Особенно при использовании других языков.
В ту же копилку мыслей
Switch case оптимизирован, и каждый кейс обрабатывается практически мгновенно
Да блин Мартин придумал ритуалы а не методологию. В конце концов ведь даже realtime код использует абстракции, да хотя бы математические, и блин все равно когда в нем есть четкая структура его проще понимать и улучшать. И он, скорее всего, будет работать быстрее.
Но Мартин всем с какого-то рожна одну структуру навязывает игнорируя контекст.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жертвы чистого кода