Comments 84
Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – 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к строк таких людей уже нет по определению
Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем астракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата.
Ну да, основная фича КлинКода для энтерпрайз приложений в том, что можно заменить любого на любого и он поймет что там происходит. Таким образом можно выгнать гения, когда он написал и отладил систему и посадить макаку её поддерживать.
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 байт памяти нужно было уложить сложнейшие алгоритмы. Хорошая была школа.
Так вот, мой текстовый редактор сначала шифровал файлы при сохранении "в лоб". И на больших текстах это стало крайне долго. Следующую версию я решил все же оптимизировать. Стало мгновенно. Да, потратил время и мозги. Но зато работает как надо!
Про книгу о чистоте кода не скажу, пишу не в команде и никому ничего объяснять не нужно. А понятия о красоте кода, наверно, у каждого свои...
Вижу некоторую путаницу в понимании "чистого кода".
У меня есть проект, работающий с биржами, который непрерывно качает и обрабатывает кучу данных. О том, чтобы держать их во время работы в БД даже речи не идёт, это будет просто провально по времени.
Но можно классически организовать хранение в виде объектов/классов - это типичный подход, который родит очень удобный и безопасный код, но он будет работать на 20-30% медленнее ручной обработки с указателями и выделением памяти.
Пример в статье с массивами будет простым, пока массив один, а когда этих массивов десятки, и размер их непрерывно растет и в каждой записи массива еще по несколько массивов и указателей и т.п., то внезапно однажды "чистый" код становится "грязным", т.к. через какое-то время там настолько всё будет наворочено, что будет сложно понять, как это работает. Хотя, при этом, этот код всё так же будет более быстрым.
Для себя я выберу более быстрый вариант, хотя он потребует в разы больше времени, но при разработке на сторону я бы 100 раз подумал.
Почему бы не решить эти проблемы по-современному. Пишите чистый код, а потом "окей нейронка, перепиши разверни эти паттерны в тупой код шоб было быстро"
А они так не умеют, так умеют некоторые экспериментальные нейронки от Intel, но они стоят запредельно дорого.
Интересно с чем связано это неумение? Сложностью разработки на ассемблере и, как следствие, небольшой кодовой базой для обучения?
После коротких тестов мне показалось, что справляются хуже. Одна и та же модель нормально реализует класс с несколькими функциями, но стоит попросить что-то вроде "напиши функцию на NASM x86_64 под Linux с соблюдением System V AMD64 ABI", как она выдает какой-то неликвид, который ещё сильно дорабатывать надо.
В итоге будущее разработки - много медленного высокоуровневого кода от ии, а люди будут вытеснены до оптимизации байтиков для быстрого кода на низких языках?
Вероятно автор статьи либо не читал, либо не понял "Чистый код". Собственно в статье нет ничего по сути чистого кодирования, кроме апелляции к частным случаям трудностей оптимизации. Попробую объяснить суть, немного утрируя. Предположим, что противоположность "чистого кода" - "вонючий код". Это когда задача решена, и может быть даже достаточная производительность была достигнута. Но, код получился настолько вонючим, что никто не захочет его трогать, даже сам автор некоторое время спустя. Код более не оптимизируется, более не поддерживается. Это как раз тот случай, когда хочется "всё удалить и переписать заново". И это проблема. Потому что удваивает стоимость *продолжения* разработки. Книга предупреждает об этом, пытается привести много способов (на данный момент немного устаревших) этого избежать. Но сам принцип всё ещё верен.
И читал и понял, и применял, и могу сравнить разные подходы. Мартин про управление сложностью через ооп-абстракции, но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится "вонючим" как вы выразились и невыносимым для поддержки через год. Когда у вас граф зависимостей разрастается до такой степени, что никто не понимает, как данные текут через систему, это и есть результат слепого следования букве книги, а не реалиям разработки. Задача хорошего разработчика найти баланс, чтобы код остался понятным и расширяемым, не превращаясь в "лапшу" из виртуальных вызовов и аллокаций. И это не всегда ООП и не всегда чисто в редакторе. Про устаревшние способы тоже верно, и это один из аргументов не тащить наследие. Есть более современные авторы Фабиан и Найстром, которые пишут как выбраться из этого оопешного ада, и книга Оустерхаута, которая показывает недостатки стиля Мартина.
как выбраться из этого оопешного ада
Я вижу у вас какую-то излишнюю избирательность в терминах. Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения. Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами). И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода. "Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать. Не бывает "излишне чистого кода", или "лучшего" с вашей точки зрения, но "не очень чистого". "Чистый код" по определению самый лучший в вашей данной конкретной ситуации.
Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения.
Очень вольное обращение со словом объект. Да, и в ФП и в процедурном программировании можно упортреблять слово объект, но это структуры сгруппированных данных не более. Подход в этих парадигмах - есть отдельно функции а есть отдельно данные. Для ООП характерен стиль совмещения данных и функций, и хоть это тоже называется объектами, по смыслу это совсем иное чем объекты (структуры) из ФП и ПП.
Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами).
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:
- получить данные от клиента
- провалидировать
- послать запрос на обновление в БД
- вернуть данные клиенту
Никаких объектов тут нет. Попытка смоделировать и натягивать объекты на реальный мир это куда более сложная и более высокая абстракция.
И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода.
Замечательно что они появились и что они были настолько удачные что несколько десятков лет все пытались писать на них нормально, да так успешно что в последнее время в новых языках отказываются от этой парадигмы как базовой.
"Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
Возможно я ошибаюсь, но мне кажется, что именно логика ООП привела к организации программ в виде цикла событий и реакции объектов на эти события. В обычной ДОС логика была совершенно другой: программа выполнялась линейно, в нужных местах запрашивая действия пользователя. Но ООП под ДОС работало уже в логике реакции на события!
Сейчас есть только логика реакций на события (ООП). А мне кажется, что каждый вариант имеет свои плюсы и минусы. Но выбора сейчас нет...
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:- получить данные от клиента- провалидировать- послать запрос на обновление в БД- вернуть данные клиенту
Если заниматься одними CRUD'ами - то да. Если у вас танк порождает снаряд, снаряд обрабатывается физикой и когда-то потом наносит урон другому игроку - то это уже сложно переложить на плоский алогритм.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
Вопрос не имеет смысла: вообще все писать хотя бы нормально никогда не начнут. Но в целом появление ООП заметно улучшило картину, иначе эта парадигма не получила бы такого распространения.
Никаких объектов тут нет.
Очень сложно объяснить в рамках коротких комментариев дух ООП специалисту, который вероятно не начинал программировать в мире без ООП, буквально в машинных кодах, когда ассемблер был роскошью (никаких макроассемблеров!). Похоже моя точка зрения практически получается диаметральной. Я видел и практиковал жёсткие оптимизации, минимальный объём памяти, жил в мире когда ООП только-только стал возможным и писать поддерживаемый код - ЭТО было целью, а вовсе не оптимизация (все программы были достаточно оптимальными, чтобы работать на 286 процессоре 🫡 ). Представьте сотни программ и библиотек, быстрых, аскетичных, но которые практически невозможно использовать далее, даже в своих собственных проектах. 😭 Книги типа "Чистый код" как раз и формализуют процесс разработки, что бы ПО развивалось, в т.ч. другими людьми, и было бы свободным во многих смыслах.
Я начинал программировать в мире без ООП, но не замечал, чтобы до этого было сложно использовать библиотеки. Конечно, в машинных кодах это затруднительно, но зачем кидаться в крайности? Модульное программирование на языках высокого уровня вошло в употребление задолго до ООП.
Широкое повторное использование библиотек сделало возможным движение свободного ПО, а не какие-то технические приёмы.
А автор учитывает что есть игры где нет 30000 сущностей и которые могут себе позволить писать нормальный код? А то прям вижу как оправдываясь этой статьей гкодеры и к goto придут, чо, сэкономит нам 1Е-250 секунды на сущность, хотя мы делаем визуальную новеллу
Да пишите, никто не мешает. Хорошая игра не та, что идеально сделана, а та в которую играют.
Кстати, "goto" - штука очень удобная и хорошая, если его правильно использовать.
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 тоже не бесплатен, он тащит инфраструктуру, обертки, вызовы и сложность. Если вам в конце кадра надо просто пройти по объектам сцены и сделать чтото простое, то ецс добавляет нагрузку а не убирает. Но вы уже не можете сделать это отдельно и приходится писать новую систему, выбирать когда он будет запускаться, Маркировать поле или заводить новое. А надо то было всего лишь использовать обычный цикл. Я про это
Жертвы чистого кода