В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции. Звучит она примерно так: «Я хочу, чтобы сам процесс создания игр был проще, приятнее и продуктивнее и готов пожертвовать 10% производительности ради этого» - Тим Суини.
Аргумент хорош, обещает за небольшую цену красивых абстракций, паттернов и фичей языка позволить программисту быстрее производить "плохой" код, плохой в смысле медленный, но который делает ту же полезную работу, что и альтернативный хороший, но нечитаемый и сложный для понимания. Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем абстракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата.
Сразу оговорюсь, что под "плохим кодом" я не имею в виду то, что программист видит у себя в редакторе. Там как раз может быть красота, ровные отступы, говорящие имена, абстрации и документация. Но я говорю о реальном коде, который фактически крутится на процессоре или видяхе у игрока, и который превращается в просадки фреймрейта, в полминуты загрузки уровня и в взлетающие вентиляторы.
Статья родилась после очередного приступа клинокодомании в отдельно взятой студии, когда кто-то в очередной раз увидел и притащил всем известную книгу Мартина о достоинствах этой самой клинокодии. Но "Clean Code", тот что с заглавной буквы и тысячными тиражами, вовсе не «чистый код» в бытовом смысле, потому что Мартин придумал этот бренд, ярлык, и несколько лет пестовал его на конференциях, связав свое имя и это понятие. Правильнее было бы называть это "стиль мистера Мартина" или "стиль Дядюшки Боба", и тогда половина споров о важности книги отваливается сама собой, потому что спорить приходится уже не про абстрактную "чистоту", а про конкретные наборы приёмов конкретного автора. Та дискуссия с технической стороны так и не получила внятных результатов, потому что на третьем круге обсуждения в ход шла риторика и подмена понятий вроде «clean» (хороший, годный), который начал превращаться в «Clean» (по методичке), и обратно.
Не все "Ёгурты" одинаково полезны
Тут нужна небольшая поправка к тексту статьи и почему не стоит бросаться использовать примеры из красной книги у себя в проекте. Когда Мартин писал Clean Code (2008), он уже много лет занимался не только разработкой, но и консультированием команд через Object Mentor, которая обучала экстремальному программированию, объектно-ориентированным подходам и agile-идеям. Поэтому книга выросла из опыта работы с большими бизнес-системами и командами, где главной проблемой обычно была сложность изменения и поддержки кода, а не стоимость каждого микросекундного участка выполнения.
Надо понимать, что Clean Code не книга про оптимизацию исполнения программ и её основная область будет про поддерживаемость больших систем, где основная стоимость часто появляется не от лишнего вызова функции или промаха кеша, а от сложности изменения кода спустя годы. Для игровых движков и realtime-систем эти идеи становятся лишним слоем абстракции и могут попасть не только в стоимость поддержки, но и в стоимость каждой итерации разработки и каждого кадра.
Начнем с того, что основной интерфейс, через который программист пишет код очень узконаправленный и неудобный, приходится писать буковки, много буковок, очень много буковок. Просто чтобы описать небольшое действие, вроде вывода HelloWorld в консоль. Интерфейс, через который мы пишем код, плотно завязан на психологию, на способность рассуждать и выражать вычислительные эффекты и не всем это подходит, а большая часть существующих интерфейсов одинаково неудобны человеку, например потому что писать на бумаге, рисовать или говорить более естественно, чем выражать мысль через ограниченный набор букв, плюсиков и амперсандов.
Но это если смотреть со стороны человека, потому что есть другая сторона, где тоже плохо, и любой интерфейс одинаково неэффективно реализуется на железе, просто потому что это интерфейс. А неэффективность железа, пролезает обратно в код.
Возьмем что-то совсем приземленное, обход массива объектов, к примеру и попробуем посчитать сумму какого-то поля. «Чистый» вариант почти всегда выглядит невинно, вектор shared_ptr, и виртуальный метод, удобная иерархия, или граф типов, но проблема начинается не там, где код становится чистым. Проблема начинается там, где абстракция становится целью, а не инструментом.
// "удобно", но каждый объект это отдельная аллокация for (Entity* e : scene.getAllEntities()) e->getTransform()->update(dt); // виртуальный вызов + виртуальный вызов // + прыжок по куче
Выглядит красиво, легко читается, легко тестируется, но... Но каждый объект лежит в своей собственной области памяти, кеш промахивается, виртуальный вызов не даёт компилятору заинлайнить и заодно векторизовать цикл, а если в иерархии десять разных типов, то и BPU (Branch Prediction Unit) тоже не особо помогает.
Второй вариант, тот что без иерархий и интерфейсов, держит просто массив структур (или, ещё лучше, массив отдельных полей, structure of arrays) и плоский цикл, который компилятор разворачивает и векторизует сам, без подсказок. Этот вариант "грязнее" в смысле Мартина, сложнее читать новичку и хуже укладывается в красивую иерархию классов из учебника, но его проще профилировать, потому что в нем нечему прятаться, проще распараллелить, потому что данные лежат рядом, и он в разы быстрее на железе. Это не жертва ради скорости, это просто другой способ думать о данных, не как об объектах с поведением, а как о массивах данных, которые надо быстро прогнать через процессор, коими это все и было, пока мы не попробовали это все дело приукрасить и "почистить".
// плотный проход по массиву: и читать приятно, и кешу хорошо for (size_t i = 0; i < count; ++i) positions[i] += velocities[i] * dt; // SoA, предсказуемый доступ
И вот когда мы приходим к измерению fps, замеров расхода памяти или профилированию на реальном железе, то серьёзных сторонников «Clean Code» становится вполовину меньше, а все заявления о том, что мы меняем циклы CPU на продуктивность программиста, так и остаются заявлениями.
Но предположим, мы действительно оказались в ситуации, где приходится менять производительность на скорость написания кода. Допустим даже, что у нас есть инструменты, про которые точно известно, что они так делают, но даже в этом идеальном для них случае выбирать комфорт программиста почти всегда неразумно. Главная ошибка, которая ломает весь довод «за скорость написания в ущерб скорости выполнения» это построение неправильной экосистемы с самого начала.
Я тебя написал, я тебя и запущу
Неявная модель, на которой все это держится выглядит так, что у нас есть один производитель (который пишет код) и один потребитель (которые его запускает). Производитель страдает над клавиатурой, потребитель наслаждается результатом. Красиво! Только в разработке игр это не так от слова совсем.
В реальности производитель, т.е. программист запускает код первым и чаще всех: во время разработки, отладки, профилирования и плейтестов и только после бесчисленных прогонов билд доходит до игрока. Игровой цикл разработчика выглядит примерно так:
ИТЕРАЦИЯ РАЗРАБОТЧИКА правка кода / ассета компиляция (плохая архитектура -> +2 минуты на инкрементальный билд) запуск редактора / cooking ассетов прожать до нужной сцены посмотреть результат 10 секунд -> заметить что не то -> повторить N раз
И вот тут плохое время исполнения бьёт по продуктивности самого автора и часть «выигрыша» от того, что код написали "чище", тут же съедается ожиданием. Пока соберётся проект, пока прогрузится уровень, пока ты дойдёшь до бага на десятой минуте геймплея, потому что быстрого сейва в этой точке нет, а загрузка занимает полминуты, пока... пока... пока...
Чтобы и дальше оправдывать подходы, ускоряющие генерацию плохого кода, нужно доказать, что ухудшение цикла итераций не перевешивает выигрыш в скорости написания. А ведь код пишется один раз, а запускается, отлаживается и подкручивается сотни и тысячи раз и каждая лишняя секунда компиляции и каждый просевший до 20 fps редактор умножаются на это число. Подумайте про компиляцию своего проекта, вы где-то добавили <iostream> , он добавил вам почти !секунду! на компиляции, вы это код собираете по 60 раз за день, минута времени просто ушла в никуда, а это просто один заголовочный файл, но их в проекте сотни, и каждый со своим сайдэффектом. Эта секунда критична (объясню ниже), но этого никто не считает, пока время не начинает переваливать за минуты, десятки минут или часы. Часы ожидания.
Тормоза распространяются
Примеры и задачи из Clean Code в первую очередь про прикладной бизнес-софт, системы учёта, бизнес-логику, приложения, где главная сложность будет в изменении требований и сохранении понятности кодовой базы. Это тоже важные проблемы, но realtime-разработка добавляет к ним ещё один слой, когда код должен не только быть понятным человеку, он должен укладываться в жёсткий бюджет времени процессора, памяти и итераций команды.
Мне приходится делать движок, а чтобы делать движок хорошо и чтобы дизайнер не ругался на загрузку уровня по пять минут, мне нужен профилировщик, дебаггер, система контроля версий и редактор. Профилировщик мне делает другой программист, и ему чтобы делать профилировщик, ему нужен... движок, на котором он будет тестировать, что профайлер вообще что-то ловит.
И тут вместо абстрактных «производителя» и «клиента» есть я, который пишу движок, а справа от меня сидит Джон-Ваня, который пишет инструмент, без которого я не могу нормально писать движок. И таких связей повсюду внутри студии очень много, геймплейщики зависят от тулзов, тулзы от билд-инженеров, те зависят от рендера, который пилят рендер-программисты, которым нужны тулзы геймплейщиков для теста, и вообще вся индустрия сидит на чьих-то либах, движках, библиотеках и SDK.
В этом контексте, если мой софт медленнее, чем мог бы быть, то он тормозит не только меня. Оно тормозит всех, кто на меня завязан, сокращает число их итераций, а от их софта завишу уже я. Я начал с того, что чуть-чуть ухудшил свой движок, а эффект начинает расползаться по сети зависимостей и, поскольку граф циклический, вернулся ко мне же. Я сам себе уронил продуктивность через три рукопожатия.
Тормоза накапливаются
И это всё ещё оптимистичная картина, потому что реальный граф экосистемы разработки игры будет огромной циклической зависимостью через независимых участников: студии, мидлвар, движки, плагины, ассет-сторы, тулчейны, платформенные SDK. Все зависят от всех.
Плохая производительность, внесённая в любой узел этой сети, распространяется по всей сети, потому что «зависеть от ПО» в нашем болоте буквально значит «исполнять его». Время работы зависимости так или иначе входит в стоимость запуска уровня, и через него в стоимость работы. Иногда напрямую в рантайме через тормозную физическую библиотеку и пару миллисекунд на кадр, иногда в издержках разработчика, когда тормозной редактор отъедает по часу в день у каждого в команде из ста человек.
Цифра реального активного проекта, художник в среднем за день делает 40 генераций ассетов, не рисует заново, но что-то меняет и обновляет/cмотрит в игре, я взял только импорт ассета без запуска редактора и просмотра на реальном уровне.
быстрый импорт ассета: 0.2 c -> медленный: 8 c × 40 генераций ассетов в день × 40 художников = +4 часа ожидания в день
Блокируется либо программа, либо человек, но цена есть в обоих случаях, просто во втором её сложнее увидеть в профайлере, потому что она прячется в чашках кофе и выкуренных сигаретах. И чем длиннее цепочка зависимостей, тем выше шанс, что эффект умножится, продублируется и вернётся обратно, и тем меньше шанс, что кто-то вообще поймёт, где находится корень проблемы. Вот вам реальные затраты на применение чистого кода, вы могли нанять еще одного дизайнера или художника, но эти деньги ушли на оплату процентов по "техдолгу" проекта.
«Почему редактор тормозит?», да потому что плагин дёргает менеджер, который под капотом на каждый тик аллоцирует строки, потому что так было «чище» написать три года назад в библиотеке, которую с тех пор никто не открывал, и это, кстати, отлично объясняет состояние современных игр и инструментов.
Несмотря на чудовищный рост мощности железа, большая часть проектов запускается, грузится и итерируется заметно хуже своих аналогов десяти-пятнадцатилетней давности, которые крутились на машинах в десятки раз слабее. Почему? Потому что деградация в такой сети не останавливается на одном ребре графа, а умножается на каждом стыке.
Тормоза тормозят всех
В своей книге Мартин делил время на «домены», наносекунды для системщиков, микросекунды для прикладных разработчиков и секунды для пользователей, имея ввиду потеря пары миллисекунд погоды для последних не делает. Возможно это работает для кровавого ентерпрайза и бизнес-систем, но в реальности домен времени один. Потерянные наносекунды складываются в микросекунды, те в миллисекунды, те в просевший кадр, тот в неиграбельную сцену, та в перенос релиза.
16.6 мс на кадр @ 60 fps - 4.0 мс рендер - 3.0 мс физика - 2.0 мс анимация - 5.6 мс геймплей-логика -------- = 2.0 мс запас // "красивый" ECS-обёрточный слой добавил по 0.0008 мс на сущность // × 30 000 сущностей = 2.4 мс -> запас в минусе -> кадр застолился
Возьмем рендер на 60 fps, это 16 миллисекунд на кадр всего, и в этот бюджет нужно уложить физику, анимацию, AI, рендер и звук разом. Если где-то в недрах системы частиц лежит «чистая» абстракция с виртуальным вызовом на каждую частицу, то при десяти тысячах частиц на сцене это уже полмиллисекунды, три процента от всего бюджета кадра, потраченные не на частицы, а на красоту кода. Один такой класс не уронит игру, но в реальном проекте таких "чистых" решений сотни, и просадка набегает не из одного места, а из тысячи маленьких, каждое из которых по отдельности оправдано читаемостью.
Жертвы чистого кода
Менять эффективность ПО на эффективность программиста может казаться выгодной сделкой, пока её оплачивает кто-то другой подальше от вашей студии. Методологии, которые продвигают красоту кода в редакторе как высшую ценность, вносят с собой и заметную деградацию качества игр и инструментов, и вот какая ирония появляется, еще и падение продуктивности самих разработчиков, ради которых всё это якобы затевалось.
Я начал с цитаты Суини про 10% производительности ради удобства программиста, но беда в том, что разработка игр сегодня сплошь и рядом оказывается сложнее, муторнее и менее продуктивной потому, что система научилась оправдывать посредственность красивыми словами. Чистый код пожирает сначала скорость ради удобства разработчика, а потом забирает и и скорость проекта и удобство разработки.
Поэтому когда вам в следующий раз принесут красную книгу про что-то чистое и благородное, киньте профайлером в приносящего дар, авось одумается. Код конечно не должен быть грязным, но чистота ради чистоты превращается в ещё один вид технического долга, а идеи, какими бы красивыми они ни были, всё равно должны пройти проверку реальным железом, временем сборки и количеством мата со стороны дизайнеров.
З.Ы. Тут тоже ругаются на чистый код и Тут
З.З.Ы. Еще я завел сайт на github pages, где собрал часть статей, которые относятся к разработке и играм (https://dalerank.github.io/). Статьи переведены на английский и частично итальянский, за что отдельное спасибо коллегам и нашему отделу локализации.
Комментарии (100)
hurtavy
10.07.2026 14:23а разве игровые студии заботит фпс? :))
Andrey2008
10.07.2026 14:23Так жирно, что тонко :)
А если серьёзно, то ещё как! Как раз с Сергеем уже цикл вебинаров есть на тему GameDev и оптимизации:
dalerank Автор
10.07.2026 14:23в эпоху переизбытка мощностей по большей части не заботит, но кого это заботит? /s Ж) Это один из вопросов в студии, нужен ли нам перформанс инженер, часто он поднимается когда чинить уже поздновато. Но в целом стараются все же следить за этим.
Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме, потому что к моменту выхода игры они станут массовыми конфигурациями. Люди, которые попали в эти 20% играют без проблем, консоли играют без проблем, люди которые к моменту выхода не попали... испытывают затруднения
smart_pic
10.07.2026 14:23Просто понятие фпс у нас разные, студии при разработке игр ориентируются на верхние 20% сегодняшнего железа в стиме,
Дать разработчикам компьютеры действующего среднего уровня, а не как они привыкли топового, вот тогда и начнут писать код который работает быстрее.
ShadF0x
10.07.2026 14:23Дать разработчикам компьютеры действующего среднего уровня
Так ведь два последних поколения консолей - это они и есть. Это раньше были какие-то MIPS, PowerPC и прочие извращения, а с восьмого поколения везде AMD64 (ну, кроме Switch).
Просто на ПК дают настройки покрутить и рендерить в каком угодно разрешении, отчего сразу видно "косяки" в производительности, а на консолях будешь жрать что разработчики выставили.
Например, в Dragon's Dogma 2 (как пример не самой оптимизированной игры) на консолях есть два режима: "плавающий" FPS (который не ниже 30, но и до 60 никогда не дотягивает) или жёсткие 30 FPS, и реальное разрешение игры меньше того, что оно выдаёт на выходе (1920x2160 для "4К" и 1280x1440 для "2К").
randomsimplenumber
10.07.2026 14:23Дать разработчикам компьютеры действующего среднего уровня
У разработчиков IDE не тормозит.
MountainGoat
10.07.2026 14:23Быстрее. За счёт графики уровня Doom2. Во время разработки игра тормозит даже на топовых комплектующих. Разработчики все 2-3 года созерцают своё творение, обычно, в 5-10 фпс. Давайте им ещё уполовиним.
rukhi7
10.07.2026 14:23нужен ли нам перформанс инженер
а что такое перформанс инженер? Промт-инженер слышал! перформанс инженер - это что-то новенькое, даже в IPP которое Intel Performance Primitives, 25+ лет назад, такого не было.
Просто надо чтобы кто-то умел померить эти ФПС, но уже никого не осталось кто их померить правильно может. Консоли пока играют и ладно. И Clean Code тут, как бы особо, тоже не причем, надо просто уметь измерить, остальное приложится.
dalerank Автор
10.07.2026 14:23А это одно из ответвлений билд-инженера (CI/CD) или tool/engine-программера, отвечает за то, чтобы игра держала бюджеты памяти/времени кадра на таргет платформах. В небольших студиях эту роль часто тащит техлид/техдир или кто-то из принципалов по совместительству, в более крупных это отдельная команда внутри engine-подразделения и отдельный человек.
wintermute2025
10.07.2026 14:23Определение Clean Code разное в разных контекстах. В контексте корпоративной разработки Clean Code - это организация кода таким образом, чтобы внесение изменений в одном месте не ломали фичи в другом + реализуемая логика важнее производительности. В контектсе системного ПО Clean Code - это производительность превыше всего. В контексте субъективной вкусовщины Clean Code - это про красоту кода, который ототбражен на экране (название классов, переменных, расположение открывающих и закрывающих кавычек etc.). А ещё, вполне возможно, есть и другие контексты для Clean Code. Выбирай тот контекст, который тебе подходит, ну или нравится. Среди них нет плохих или хороших. Мартин написал книгу про одно, вы написали статью про другое. И то, и то имеет право на существование.
Politura
10.07.2026 14:23Это ваше представление о понимании словосочетания чистый код. А статья о том, что словосочетание стало брендом единственного подхода, который из-за популярности книжки получил поколения программистов выросших на ней которые тащат этот подход во все области, даже туда, где он вредит, оправдываясь оным словосочетанием.
rg_software
10.07.2026 14:23Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
JBFW
10.07.2026 14:23большая существующих интерфейсов одинаково неудобны человеку, например потому что писать на бумаге, рисовать или говорить более естественно, чем выражать мысль через ограниченный набор букв, плюсиков и амперсандов
Напомнило: "у меня не хватило слов чтобы это описать, поэтому я подготовил танец!"
Как раз сформулировать мысль удобнее через набор буковок и амперсандов, чем рисовать, писать на бумаге и даже говорить. Правда, не для всех...
dalerank Автор
10.07.2026 14:23Как сказал один из хороших разработчиков, если вы не можете это сказать словами и нарисовать на одной стороне листа, то написать это хорошо, тоже не сможете.
"A specification that will not fit on one page of 8.5x11 inch paper cannot be understood."
"Спецификация, которая не помещается на одном листе формата 8.5x11 дюймов, не может быть понята."
Mark ArdisJBFW
10.07.2026 14:23Имеется ввиду "не помещается", а не "напишите это перьевой ручкой на пергаменте"
Другой вариант этого же правила - функция должна помещаться в один экран
RealHuman1
10.07.2026 14:23Функция должна выполнять свою работу, а не помещаться на какой-нибудь там экран. Экраны тоже бывают разные, на 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)".
А вот серваку вызов полусотни абсолютно лишних функций совсем скорости не добавит. В проде бывавает и так, что с СИ на асм соскакивают, чтобы миллисекунды выгадать.
boulder
10.07.2026 14:23Эге, коллега!..
Ну, не на 50, а на 5 функций можно бы и разбить.
А лучше (сильно лучше) перевести подобный импорт на систему из шаблонов, которые задаются — да хоть в текстовом файле! Потому что один человек дописывает к этой полутыще строк if{}, другой тоже... — и вот у вас через 5 лет не 500 строчек, а 2500 — и это именно наш случай. И только сейчас добрались до переделки :)
atyumentsev
10.07.2026 14:23Такие функции на 500 строк имеют дурацкую привычку разрастаться до 5000 строк.
И если для функции на 500 строк может быть несколько человек, которые хоть приблизительно понимают, как она работает, где тонкие места в ее логике / производительности, какие есть баги, и так далее, то в функции на 5к строк таких людей уже нет по определению
VitalyZaborov
10.07.2026 14:23Я видел такие функции как в примере выше. Если там 5000 строк достаточно бойлерплейтного кода, но без копипасты, то лучше не разбивать. Если вся функция больше похожа на конфиг, то оттого что вы её порежете кода меньше не станет.
alamat42
10.07.2026 14:23“row[inn] = (int)row[inn]; if strlen(row[inn]) != 11 throw new Exception…” было бы “checkInn(row[inn])”
Выглядит как код на С++, написанный в стиле Си, что само по себе не очень хорошо пахнет в большинстве контекстов.
Просто в результате вместо одной легко читаемой последовательно простынки было бы 50 носовых платков, каждый из которых невозможно переиспользовать,
Смысл деления на функции не только в том, чтоб их можно было переиспользовать, но и в том, чтобы:
Декомпозировать код на части, каждая из которых выполняет свою задачу, и дать этой части внятное имя.
Ограничить контекст, в котором код выполняется.
И то, и другое нужно как раз для того, чтоб в коде было быстрее и проще понять, что происходит. Даже если код читается так же легко, как приключенческий роман, то для того, чтоб понять, что происходит в функции, (и найти место, которое ему нужно поправить) человеку придется прочитать все 500 строк кода, и к тому моменту, когда он дойдет до конца, он уже забудет, что конкретно там было в начале.
Так устроено человеческое мышление: человек не может удерживать в кратковременной памяти больше, чем 7±2 вещей. В простыне будет и сложнее найти нужное место в коде, и проще совершить ошибку из-за слишком большого контекста, о котором стоит помнить.
А вот серваку вызов полусотни абсолютно лишних функций совсем скорости не добавит.
Это на каком языке нужно писать, чтобы беспокоиться о влиянии на производительность лишних вызовах функций? В любом приличном компилируемом языке программирования компилятор сам заинлайнит вызовы функций, если это будет сулить какой-никакой выигрыш по производительности. А если писать на каком-нибудь питоне, то ты уже отказался от высокой производительности в пользу скорости разработки.
Boneyan
10.07.2026 14:23Ограничить контекст, в котором код выполняется.
Но ведь для этого не обязательно разбивать большую функцию на функции? Можно разбить функцию на кодовые блоки, чтобы в конце блока переменные выходили из видимости.
fn my_big_func() { { // do thing A } { // do thing B } { // do thing C } }В простыне будет и сложнее найти нужное место в коде, и проще совершить ошибку из-за слишком большого контекста, о котором стоит помнить.
Тут зависит от того, какая задача стоит перед программистом.
Если программисту для того чтобы решить свою задачу нужно прочитать фунцию полностью, то “простыня” будет читаться проще, чем вызов большого количества маленьких функций. Ему придётся прыгать вверх-вниз по коду, читая каждую такую функцию.
Если же программисту не обязательно для своей задачи понимать функцию полностью, то ему наверное будет проще с подходом, где большая функция разбита на маленькие. Он увидит вызов
doThingA()и решит “окей, тут делается вещь А, глубже читать не буду” (замечу, только при условии что имя у функции понятное и полностью отражает её содержимое!).Вопрос в том, что чаще встречается - задачи для которых не нужен полный контекст функции или задачи для которых он нужен?
AdrianoVisoccini
10.07.2026 14:23Для бизнеса это выгоднее, хотя по моему опыту, бизнесу глубоко пофиг на количество написанных конкретным Джоном, Ваней или Вапуром строчек кода, его сложность или наличие в нем астракций, там совсем другие метрики "хорошести", пусть и в ущерб качеству итогового результата.
Ну да, основная фича КлинКода для энтерпрайз приложений в том, что можно заменить любого на любого и он поймет что там происходит. Таким образом можно выгнать гения, когда он написал и отладил систему и посадить макаку её поддерживать.
Alex_RF
10.07.2026 14:23Не посадить макаку его подерживать - а обеспечить высокую скорость внесение исправлений, при минимуме проблем которое внесет это изменение. При этом код не должен в течение 10 лет его эксплуатации стать порталом в ад. К стати если посадить макаку - то она из понятного и структурированого кода тоже портал в ад быстро сделает. Я как понял это статься относится к
В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции.
то есть там где на ради оптимизации готовы на траты времени и готовы жертвовать обслуживаемостью кода. Да там идеи дядюшки Боба несколько опасны.
PS Я не являюсь явным поборником идеалогии Clean Code - но она должна жить. Есть проекты, где ее использования (без излишнего фанатизма) приносит реальный результат. При этом я явно против тех, кто считает если ему удалось написать вычесление факториала в 1 строку, который только он понять может и на который от потратил пару человеко-месяцев рабочего времени - то остальные просто какие-то макаки.
lamerok
10.07.2026 14:23for (Entity* e : scene.getAllEntities()) e->getTransform()->update(dt);
Справедливости ради, это не чистый код от слова вообще. Как минимум нарушен принцип Деметры, ну и в целом, это сделал какой то диверсант.
dalerank Автор
10.07.2026 14:23это сделал человек, который принес красную книгу, после чего и зашла дискуссия про него. Про диверсанта мысль интересная :)
michael_v89
10.07.2026 14:23Непонятно, в чем претензия. Clean code разве обещает высокую производительность в играх? Нет. Код в таком стиле является более поддерживаемым? Является. В чем проблема-то?
Если что, я не согласен со многими советами из этой книги. Но логика статьи всё равно непонятна.
SergeyEgorov
10.07.2026 14:23Чего ж тут непонятного? Дядя Боб же испортил все программирование на годы, а сам развлекается там в омериках на пенсии. А у нас тут в геймдеве разброд и шатание из-за его книжек 20 летней давности. От того, что мы доверчивые бездумно. Привыкли под авторитеты безоговорочно ложиться.
dalerank Автор
10.07.2026 14:23идеи то правильные, но не надо бездумно тащить в дом все что найдено, иначе дом превращается в свалку
lazarus_net
10.07.2026 14:23Главное достоинство его книги, это не про чистый код, тестируемость, расширяемость и поддержку, это про то, что большинство разрабов пишут убогий и страшный код, который поддерживать невозможно. Объяснять им как писать правильно: для начала хотя бы выделять функции , долго муторно и все равно не поймут.
В этот момент можно взять «чистый код» пихнуть в «морду» и сказать пиши вот так. Если побежит жаловаться менеджеру- то тут ПР Товарища Мартина тоже поможет- мы же не против, сложившихся практик, мы за расширяемость … - нужное подчеркнуть.
Для человека который боле -менее нормально пишет ничего нового/интересного в в книге нет. Но таких, к сожалению не много …
k4ir05
10.07.2026 14:23Так корень проблемы не в книге или её авторе. А в тех, кто относится к ней как к Библии. Не будь этой книги, они нашли бы другую.
Просто не нужно прямо следовать всем советам из книги (если мне память не изменяет, в книге так и написано).
FunSense
10.07.2026 14:23Спасибо за статью. Возник вопрос по поводу сайта на github pages: почему именно итальянский был выбран третьим языком для статей? Из чистого любопытства интересуюсь, выбор показался весьма неожиданным
Jijiki
10.07.2026 14:23самое интересное, что у вас всего 2 маленьких примера, и буквально всё.
нет ни замеров, ни конкретных примеров почему тот или иной подход не совсем приятный.
у Кейси Муратори свой клин код, у Дяди Боба свой клин клод. у них у обоих клин код.
они оба говорят об одном и том же, Кейси говорит за минимализм без оверинжинирга, но на С писать не удобно, значит чуть по-выше это классы/деструкторы.
SadOcean
10.07.2026 14:23Статья хорошая, я бы сказал проблема даже шире.
Она не только с чистым кодом (дедушка Мартин вызывает сомнения своими советами со стартом), но в целом к границам применимости подходов и методологий.
У всего есть границы применимости и проблемы, которые оно решает.
И вот уже у людей странные требования к ООП, абстрактные зависимости, идеально быстрый ECS везде, нет синглтонам, AoS, SoA, паттерны, интерфейсы, браузер внутри, блеать, всего, виртуальные машины на виртуальных машинах и своя собственная, Тьюринг полняя, но плохая реализация LISP.
Причем все сразу.
Потому что эти рекомендации перешли из пространства решений в пространство ритуала и потеряли связь с ограничниями.
Потеряли важный фактор того, что оно не бесплатно, и если ты делаешь что-то просто так, ты платишь без отдачи.
Сами по себе рекомендации не бесполезны конечно, мысль про то, что хорошая архитектура может чего то стоить, как и то, что ультра оптимизированный код хер прочитаешь и логичная и подтверждается опытом.
Но все хорошо в меру.
black_warlock_iv
10.07.2026 14:23спорить приходится уже не про абстрактную “чистоту”, а про конкретные наборы приёмов конкретного автора
Да, про конкретные приёмы можно спорить, но это не так интересно. Интереснее вопрос, должен ли код быть чистым в принципе или нет. Я считаю, что да, хотя конкретика конечно не как у апологета. Как считаете вы я не совсем понял.
Lewigh
10.07.2026 14:23Проблема в том что большинство программистов, последнее время пафосно направо и налево называющих себя инженерами, никакого отношения ни к понятию инженерного дела ни к понятию прагматизма не имеют. Уже давным давно балом правит хайп.
По хорошему, человек который прочитал Clean Code и думающий его внедрять, должен задаться вопросами: а кто такой автор книги и какой у него опыт и можно ли посмотреть его проекты, а если ли доказательства эффективности предлагаемых им методик, наконец провести мозговой штурм с коллегами проверяя это все на прочность. И тогда неожиданно выясниться что Мартин - обычный хайпожор, завирусившийся на книгах и статья без каких либо серьезных достижений, серьезные работы которого особо негде посмотреть. Ну т.е. типичный советчик. Далее, каких нибудь ну хоть сколько то объективных доказательств просто нет. А многие его советы не выдерживают критики. Но так должны думать нормальные инженеры, а для большинства нужен вайб и хайп. Clean Code модный - значит будем его внедрять. Это касается не только данной темы.
Удивляет только что такой хренью начали страдать в геймдеве. В энтерпрайзе то это все расцвело потому что так программист мало за что отвечает. Будет тормозить не вывозить - это проблема заказчика, пусть серверов докупает. А мы художники, мы высокими архитектурами занимается по книжками.
whoisking
10.07.2026 14:23Уже давным давно балом правит хайп.
Полностью согласен, прагматиков один на сотню. Это вижу и с архитектурами и с методологиями и с инструментами и с ИИ. А теперь, особенно, с ИИ. Когда в меня команда кидает маркетинговые твиты, а СТО на мои вопросы о том, как мы это будем поддерживать, кто будет нести ответственность и кто вообще будет понимать, что там происходит внутри сервисов, написанных агентами, отвечает "оно сейчас везде, оно сейчас повсюду", то руки уже просто опускаются. Также было с чистой архитектурой, также было и с методологиями. Кажется, мне нужен психотерапевт
misha_erementchouk
10.07.2026 14:23Здесь как в том анекдоте: и ты прав, и ты прав, и ты прав.
Это практически как пример из классической философии. Положим программа в ходе своей работы нарисовала кучу квадратиков. Что делает код? Кто-то скажет, что код рисует кучу квадратиков. А кто-то скажет, что код решает (условно) бизнес-задачу. Кто прав? Что же код делает на самом деле? А есть еще третий кто-то, четвертый и т.д. И, оказывается, все правы и код на самом деле все это и делает. Проблема в том, что хотя классическая философия и говорит, что, ну, да, оно как-то все вот так, она ничего не говорит, что же делать когда разные "на самом деле" приходят в конфликт. Точнее, она нас научила тому, что в непрекращающихся войнах вокруг этих конфликтов и происходит движение, но жить от этого не проще.
Перекос в сторону идей "Чистого кода" произошел потому, что дядя Боб разговаривает на языке пиджаков, со всеми вытекающими. Спорить с этими идеями с позиций производительности непродуктивно, потому что это другая категориальная система. У пиджака всегда есть железный аргумент: знаете, какой код самый быстрый? который не выполняется, он требует нулевого времени. В частности код, который не выполняется, потому что его никто и не собирается выполнять.
Помимо общих аргументов, у высокоуровневых идей есть более конкретный резон. Например, выражается в виде максимы "скороспелая оптимизация - корень зла". Разумеется, пытаться ее пропихивать как некую абсолютную идею - неосмотрительно, но, я думаю, мы все сталкивались с ситуацией, когда заоптимизированный код превращался в дикую занозу, потому что условия выполнения слишком кардинально изменились. Очень легко показывать ускорение, когда данные реализуются в виде просто индексируемого массива. А что делать, если в новых условиях данные оказались серией пользовательского ввода? Переписывать простыни кода, которому функционально вообще до фонаря была природа реализации данных? Разумеется, пример утрированный, но, надеюсь, проблему иллюстрирует.
Проблема со скороспелой оптимизацией в том, что не всегда легко сказать, когда же наступил тот момент, что она перестала быть скороспелой. Утрируя, позиция дяди Боба в том, что такой момент никогда не наступает. Другое дело, что инженеры на то и инженеры, чтобы не слушать, какого-то дядю, который сидит неизвестно где, а видеть то, с чем им приходится работать собственными руками. Видеть то, что Кнут назвал критическими тремя процентами. С этих перспектив "чистый код" представляется довольно небесполезной системой почти формализованных ограничений. По крайней мере, с такими ограничениями проще справляться, чем когда доступны только такие-то и такие-то марки стали.
vadimr
10.07.2026 14:23Это практически как пример из классической философии. Положим программа в ходе своей работы нарисовала кучу квадратиков. Что делает код? Кто-то скажет, что код рисует кучу квадратиков. А кто-то скажет, что код решает (условно) бизнес-задачу. Кто прав? Что же код делает на самом деле? А есть еще третий кто-то, четвертый и т.д. И, оказывается, все правы и код на самом деле все это и делает.
Это вполне хорошо формализованная задача формальной семантики. Рисование кучи квадратиков – это операционная семантика, а решение бизнес-задачи – денотационная. Они могут быть поставлены в разных эвивалентных формулировках. Но думать в эту сторону не очень поощряется, так как слетает весь маркетинг и надувание щёк авторами методик разработки, а теперь ещё и нейросети могут быть в числе пострадавших. Так и до ТеХа вместо майкрософт офиса докатиться можно, а это какие убытки для отрасли!
Timofeuz
10.07.2026 14:23Не хочется менторствовать, но разработка игр не всегда равно разработке движков для игр. Для разной скриптовой логики смысл вполне имеется.
thelexi
10.07.2026 14:23Статья интересная. Но общая суть Чистого кода гораздо проще и очевиднее. Просто книга написана для США - а там принято растекаться текстом по мысли..
Суть - программирование - это искуссстаот ограничений а не абстракций, а задача ограничений в управлении сложностью. И это все. Все остальное это сугубо личный взгляд дядюшки Боба в конкретной ситуации.
То ксть, каким образом это достигается - зависит только от знания языка и внутренней разрешительной системой программиста
thelexi
10.07.2026 14:23писал коммент с телефона - аж читать стыдно..
Суть - программирование - это искусство ограничений а не абстракций, а задача ограничений в управлении сложностью. И это все. Все остальное это сугубо личный взгляд дядюшки Боба в конкретной ситуации.То есть, каким образом это достигается - зависит только от знания языка и внутренней разрешительной системой программиста
d3d14
10.07.2026 14:23Это та книга, где советовалось передавать аргументы в методы через свойства класса? )
vadimr
10.07.2026 14:23Тут нужна небольшая поправка к тексту статьи и почему не стоит бросаться использовать примеры из красной книги у себя в проекте. Когда Мартин писал Clean Code (2008), он уже много лет занимался не только разработкой, но и консультированием команд
Тут нужна небольшая поправка к небольшой поправке. Собственно разработкой Мартин прекратил заниматься в 1991 году, и сам никогда не применял в реальном производстве ПО те принципы, которые проповедует. Они являются переосмыслением его опыта написания спагетти на Фортране 77, Коболе и PL/I.
aldekotan
10.07.2026 14:23Сапожник без сапог?.. А почему его вообще, в таком случае, кто-то воспринимает всерьёз тогда
vadimr
10.07.2026 14:23Ну сам по себе тот факт, что одни люди пишут код, а другие - учебники, ещё ни о чём не говорит. Просто не надо воспринимать прочитанное как догму. Это всего лишь светлые утопические идеи, каких в истории было немало. С неочевидными на первый взгляд минусами.
В данном случае минусом является размывание прикладного кода по слоям абстракций. Типичный косяк неофитов ООП.
Lewigh
10.07.2026 14:23Просто не надо воспринимать прочитанное как догму.
Проблема в том что большинство думать не хотят но хотят воспринимать все проще, как догму и будут так воспринимать. Поэтому мы и наблюдаем как сообщество десятки лет безуспешно пытается научиться пользоваться ООП, веря что ну должно же оно все проблемы решить. Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом. Потом Clean code. Потом пришло безумие повального функционального программирования. Затем микросервисы. Потом DDD-шиза.
Потому что много думать - много грустный. Все хотят чудо решение.
hauserich
10.07.2026 14:23Кстати, применение ООП, по моему опыту, резко уменьшает производительность. Везде ли стоит его применять? Вот вопрос...
geher
10.07.2026 14:23Если речь про производительность программиста, то по моему опыту снижает на начальном этапе и увеличивает потом. В целом скорее увеличивает. Это всего лишь очень удобный способ структурировать модель предметной области.
Просто не следует тупо следовать заветам вроде "В методе класса не должно быть более 5 строк" или упарываться по поводу всяких SOLID до упора. А то посмотришь на структуру классов в некоторых проектах, а тем уже непонятно вообще, зачем все эти классы, и что каждый из них реализует, поскольку поделено не по смыслу, а по формальным правилам.
Если речь о производительности программы, то таки да, может сильно снижать. Но тут тоже сильно помогает отказ от тупого следования догмам и совмещение разных парадигм программирования.
hauserich
10.07.2026 14:23Сорри, я не уточнил. Да, речь шла о производительности программы. А так вообще - лично я не люблю ООП как идеологию и стараюсь максимально уменьшить ее использование. К сожалению, под Виндовс совсем без нее обойтись не получается, но хоть как-то стараюсь...
Konstantin0Scheglov
10.07.2026 14:23А почему не получается с Windows? Вроде Win32 раньше вполне процедурный был. Потом конечно накрутили сверху OWL, VCL, MFC - но это всегда была опция, а не необходимость. Я давно не писал под Windows, но неужели поломали обратную совместимость?
x86chk
10.07.2026 14:23В порядке всё с этим, можно даже сейчас на классическом Win32 API на C писать программы. Так и делал, пока не надоело и не перебрался на ATL (хотя уже в WTL надо думать).
rukhi7
10.07.2026 14:23Везде ли стоит его применять? Вот вопрос...
С одной стороны я бы ответил что однозначно нет! Но с другой стороны я совершенно не знаю что для вас значит ООП, у меня есть например такая интерпретация - воспринимайте любую сущность необходимую вам для программирования как Объект Вашего Внимания, и тогда без ориентированности на эти Объекты нам не обойтись.
Lewigh
10.07.2026 14:23Кстати, применение ООП, по моему опыту, резко уменьшает производительность. Везде ли стоит его применять? Вот вопрос...
Я пришел к тому ООП это очень местечковая история, и главная проблема - это пыпытка на нем делать все. Из того где это может быть полезно это оборачивание ресурса для управления его жизненным циклом и небольшие стейт-машины на уровне кода, где состояние не выходит за пределы объекта.
Мне кажеться что проблема ООП не только в производительности но и в самой чужеродности подхода попытки все представить объектами при исполнении программы.
rukhi7
10.07.2026 14:23Потом паттерны GOF, которые не более чем набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени, стали культом.
ну не скажите, там например рассматривается задача как спроектировать редактор текста как типовая задача, это что задача конкретных людей? Есть кто-то кто не пользуется редактором текста? А если знать как правильно построить редактор текста, то можно использовать это знание чтобы построить редактор чего угодно. Там рассматривались фундаментальные задачи. С таким же успехом можно говорить что Нильс Бор, например, решал какие-то конкретно свои проблемы, а Эйнштейн написал
набор советов конкретных людей о конкретно их проблемах, в конкретный момент времени
которые тоже (непонятно почему) стали культом.
hauserich
10.07.2026 14:23А если знать как правильно построить редактор текста
А что, есть правила построения редактора текста? От которых нельзя отступать? Редакторов уйма, все разные. Только я написал целых два текстовых редактора, совершенно разных как по функциям, так и по внутренней организации. Так что не очень понятно, о чем речь? Кстати, графические редакторы - это совсем другое. А редактор шрифтов я еще под ДОС писал - это совсем другое...
rukhi7
10.07.2026 14:23Кстати, графические редакторы - это совсем другое.
насколько я помню и понимаю, там как раз про графические редакторы, которые обладают полной функциональностью включая масштабирование и раскраску, и вариативность стилей, вы пробовали такие делать?
Тут как раз важна сложность задачи и универсальность ее решения. Действительно, если урезать эту глобальную задачу с разных сторон, то можно получить неограниченное количество более простых задач и, соответственно их решений, но решение самой общей и полной задачи задает некоторые стандарты и определяет некоторые обобщенные приемы проектирования. Это как я это понимаю и если вам действительно интересен мой ответ на ваш очень интересный (действительно!) вопрос, вопросы!
Jijiki
10.07.2026 14:23там проблема как с созданием своего УИ, походу да есть тонкости именно по удобству, но минимально допустимой ценой, текстовый редактор еще ничего.
текстовый редактор условно рисует квадратики, УИ тоже, но там есть метод кода лапши, который не хочется писать/читать, а если более оптимальный на обьектах, но с ООП, да чутка теряем в производительности, но удобство перекрывает всё в этот момент...
vadimr
10.07.2026 14:23А из минимально вменяемых редакторов текста при этом - остался один emacs, автор которого точно этих советов не читал.
Lewigh
10.07.2026 14:23ну не скажите, там например рассматривается задача как спроектировать редактор текста как типовая задача, это что задача конкретных людей? Есть кто-то кто не пользуется редактором текста? А если знать как правильно построить редактор текста, то можно использовать это знание чтобы построить редактор чего угодно. Там рассматривались фундаментальные задачи. С таким же успехом можно говорить что Нильс Бор, например, решал какие-то конкретно свои проблемы, а Эйнштейн написал
В книге знаний людей по конкретным темам в конкретный исторический период. У автором богатый опыт создания графических редакторов теста, поэтому про редактор и писали и про остальное, а не про фундаментальную философию разработки чего угодно. И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время. Этот опыт действительно очень обобщенный и может применяться в разных ситуация но это капля в море в мире проектирования различного софта.
Это я к чему, не к тому что оно плохое а к тому что люди воспринимают это как библио которая даст ответ на все вопросы. Не даст.
rukhi7
10.07.2026 14:23опять же если вам действительно интересно:
И паттерное 23 не потому что это 23 фундаментальных паттерна разработки вселенной а потому что это выборка из опыта конкретных людей в конкретное время.
я думаю 23 это число действительно взятое с потолка, просто потому что это была первая попытка сформулировать! Не факт что эта работа теперь не засекречена и мы просто не знаем окончательный результат! Но то что есть фундаментальные паттерны разработки софта (а не вселенной), это не подлежит сомнению, по моему, их можно сформулировать и 15 и 45 и 23 тоже очень хорошее число на мой взгляд, вопрос в том как мы их будем формулировать! То есть есть ли кому у нас их формулировать при таком отношении. Ведь те кто их сформулировали смогли создать множество абсолютно комерчески-успешных продуктов! Заметьте до сих пор успешных! Те кто формулирует эти фундаментальные паттерны разработки софта не надеются что какое-то мифическое сообщество энтузиастов (в общем то не профессионалов) напишет за них код который они будут выгодно продавать как собственный продукт.
hauserich
10.07.2026 14:23Не знаю, по какой причине, но сейчас фактически не принято делать оптимизацию кода. "Не тянет железо? Купи новое!". Оптимизация требует времени программиста. Продукт выйдет позже. Плохо для бизнеса. "Пусть новое железо покупают". Почему Вин10 на моем компе с 8Г ОЗУ работала нормально, а Вин11 висит до озверения?
У меня привычка к оптимизации еще со времен даже не ДОС, а советских ПМК, где в 100 байт памяти нужно было уложить сложнейшие алгоритмы. Хорошая была школа.
Так вот, мой текстовый редактор сначала шифровал файлы при сохранении "в лоб". И на больших текстах это стало крайне долго. Следующую версию я решил все же оптимизировать. Стало мгновенно. Да, потратил время и мозги. Но зато работает как надо!Про книгу о чистоте кода не скажу, пишу не в команде и никому ничего объяснять не нужно. А понятия о красоте кода, наверно, у каждого свои...
rPman
10.07.2026 14:23Вы требования к win12 посмотрите, совсем весело/грустно станет.
Оптимизация - это от 'нищеты', пока проблема нехватки ресурсов существовала, оптимизировали и другого не знали, а как настало изобилие, так перестали тратить на это время.
Плюс, специалисты 'старой школы', те кто споткнулся о нехватку ресурсов, становятся все большей редкостью (точнее их изначально не хватает на стремительно растущую индустрию) вот и получаем результат.
Советы - посадить разработчиков на слабое железо, вредные, потому что там банально инструментарию требуется больше ресурсов, а если ресурсов мало, то банально работать эти инструменты начинают сильно медленно, это становится уже заметно в денежном эквиваленте. Можно конечно давать разработчику два физических устройства (условную тест машину, специально слабую) и заставлять тестировать все там,.. не уверен что это будет иметь пользу.
kisskin
10.07.2026 14:23Вижу некоторую путаницу в понимании "чистого кода".
У меня есть проект, работающий с биржами, который непрерывно качает и обрабатывает кучу данных. О том, чтобы держать их во время работы в БД даже речи не идёт, это будет просто провально по времени.
Но можно классически организовать хранение в виде объектов/классов - это типичный подход, который родит очень удобный и безопасный код, но он будет работать на 20-30% медленнее ручной обработки с указателями и выделением памяти.
Пример в статье с массивами будет простым, пока массив один, а когда этих массивов десятки, и размер их непрерывно растет и в каждой записи массива еще по несколько массивов и указателей и т.п., то внезапно однажды "чистый" код становится "грязным", т.к. через какое-то время там настолько всё будет наворочено, что будет сложно понять, как это работает. Хотя, при этом, этот код всё так же будет более быстрым.
Для себя я выберу более быстрый вариант, хотя он потребует в разы больше времени, но при разработке на сторону я бы 100 раз подумал.
40kTons
10.07.2026 14:23Почему бы не решить эти проблемы по-современному. Пишите чистый код, а потом "окей нейронка, перепиши разверни эти паттерны в тупой код шоб было быстро"
dalerank Автор
10.07.2026 14:23А они так не умеют, так умеют некоторые экспериментальные нейронки от Intel, но они стоят запредельно дорого.
40kTons
10.07.2026 14:23Интересно с чем связано это неумение? Сложностью разработки на ассемблере и, как следствие, небольшой кодовой базой для обучения?
После коротких тестов мне показалось, что справляются хуже. Одна и та же модель нормально реализует класс с несколькими функциями, но стоит попросить что-то вроде "напиши функцию на NASM x86_64 под Linux с соблюдением System V AMD64 ABI", как она выдает какой-то неликвид, который ещё сильно дорабатывать надо.
В итоге будущее разработки - много медленного высокоуровневого кода от ии, а люди будут вытеснены до оптимизации байтиков для быстрого кода на низких языках?
rPman
10.07.2026 14:23какие это экспериментальные нейронки интеля?
если бы у них были топовые агенты кодирования, они бы уже во всех бенчмарках бы наследили, ибо деньги от сюда полезут просто огромные.
dalerank Автор
10.07.2026 14:23могу только общее рассказать, ибо остальное под NDA. В рамках сотрудничества с синими нам дали доступ к плагину для vtune, который оптимайзит выбранные участки. Наш гуру асма грустит, ибо он потратил на тот код две недели чтобы его ускорить в полтора раза, а нейронка его ускорила за час в два раза. Но ничего другого плагин не умеет, пока не умеет, да и оптимазить больше 2к (пока) инструкций тоже отказывается
rPman
10.07.2026 14:23Агенты кодирования нужно исследовать не на том чего они умеют, а на том где они ломаются.
Я в шоке от слабой qwen3.6-35b-a3b (3 миллиарда активных параметров, это почти ничего!), она в режиме агента иногда способна на чудеса, но чаще - творит дичайшую дичь...
и чем больше одно относительно второго - тем круче модель.
ryo_oh_ki
10.07.2026 14:23Вероятно автор статьи либо не читал, либо не понял "Чистый код". Собственно в статье нет ничего по сути чистого кодирования, кроме апелляции к частным случаям трудностей оптимизации. Попробую объяснить суть, немного утрируя. Предположим, что противоположность "чистого кода" - "вонючий код". Это когда задача решена, и может быть даже достаточная производительность была достигнута. Но, код получился настолько вонючим, что никто не захочет его трогать, даже сам автор некоторое время спустя. Код более не оптимизируется, более не поддерживается. Это как раз тот случай, когда хочется "всё удалить и переписать заново". И это проблема. Потому что удваивает стоимость *продолжения* разработки. Книга предупреждает об этом, пытается привести много способов (на данный момент немного устаревших) этого избежать. Но сам принцип всё ещё верен.
dalerank Автор
10.07.2026 14:23И читал и понял, и применял, и могу сравнить разные подходы. Мартин про управление сложностью через ооп-абстракции, но в высоконагруженных системах эти самые абстракции и создают ту сложность, из-за которой код становится "вонючим" как вы выразились и невыносимым для поддержки через год. Когда у вас граф зависимостей разрастается до такой степени, что никто не понимает, как данные текут через систему, это и есть результат слепого следования букве книги, а не реалиям разработки. Задача хорошего разработчика найти баланс, чтобы код остался понятным и расширяемым, не превращаясь в "лапшу" из виртуальных вызовов и аллокаций. И это не всегда ООП и не всегда чисто в редакторе. Про устаревшние способы тоже верно, и это один из аргументов не тащить наследие. Есть более современные авторы Фабиан и Найстром, которые пишут как выбраться из этого оопешного ада, и книга Оустерхаута, которая показывает недостатки стиля Мартина.
ryo_oh_ki
10.07.2026 14:23как выбраться из этого оопешного ада
Я вижу у вас какую-то излишнюю избирательность в терминах. Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения. Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами). И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода. "Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать. Не бывает "излишне чистого кода", или "лучшего" с вашей точки зрения, но "не очень чистого". "Чистый код" по определению самый лучший в вашей данной конкретной ситуации.
Lewigh
10.07.2026 14:23Объект в ООП - это абстракция чуть выше памяти и операций ЦП. Например, при "функциональном программировании" тоже есть "объекты" - это совокупность функций, их параметров и их возвращаемых значений выстроенных в потоки выполнения.
Очень вольное обращение со словом объект. Да, и в ФП и в процедурном программировании можно упортреблять слово объект, но это структуры сгруппированных данных не более. Подход в этих парадигмах - есть отдельно функции а есть отдельно данные. Для ООП характерен стиль совмещения данных и функций, и хоть это тоже называется объектами, по смыслу это совсем иное чем объекты (структуры) из ФП и ПП.
Тут ничего нельзя сделать по другому - человек всё равно мыслит образами (т.е. объектами).
Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:
- получить данные от клиента
- провалидировать
- послать запрос на обновление в БД
- вернуть данные клиентуНикаких объектов тут нет. Попытка смоделировать и натягивать объекты на реальный мир это куда более сложная и более высокая абстракция.
И хорошо, что появились языки программирования, предлагающие из коробки удачные способы объектного подхода.
Замечательно что они появились и что они были настолько удачные что несколько десятков лет все пытались писать на них нормально, да так успешно что в последнее время в новых языках отказываются от этой парадигмы как базовой.
"Чистый код" предполагает выбирать наиболее ясные и простые способы описать алгоритмы в .т.ч при помощи ООП, в первую очередь, чтобы другие люди могли его легко прочитать.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
hauserich
10.07.2026 14:23Возможно я ошибаюсь, но мне кажется, что именно логика ООП привела к организации программ в виде цикла событий и реакции объектов на эти события. В обычной ДОС логика была совершенно другой: программа выполнялась линейно, в нужных местах запрашивая действия пользователя. Но ООП под ДОС работало уже в логике реакции на события!
Сейчас есть только логика реакций на события (ООП). А мне кажется, что каждый вариант имеет свои плюсы и минусы. Но выбора сейчас нет...
VitalyZaborov
10.07.2026 14:23Не мыслит человек никакими объектами. В базовом виде все мышление всегда идет через описание применения алгоритмов над данными:- получить данные от клиента- провалидировать- послать запрос на обновление в БД- вернуть данные клиенту
Если заниматься одними CRUD'ами - то да. Если у вас танк порождает снаряд, снаряд обрабатывается физикой и когда-то потом наносит урон другому игроку - то это уже сложно переложить на плоский алогритм.
Ну и как, получилось? При помощи ООП и Чистый кода все стали писать понятный простой и чистый код?
Вопрос не имеет смысла: вообще все писать хотя бы нормально никогда не начнут. Но в целом появление ООП заметно улучшило картину, иначе эта парадигма не получила бы такого распространения.
Andrey2008
Спасибо за публикацию. Просто отмечу, что короткий и красивый код, это не обязательно всегда замедление. Конечно, надо понимать, что ты делаешь и зачем. Без этого никак. И тогда вполне возможен сценарий, когда от упрощения и лакончиности все только выигрывают. Вот прямо сейчас разбираю такой случай в здесь – https://t.me/programming_tales/662