Начнём с наведения аксиоматики, потому что без неё любая дискуссия сводится к измерению физиологических особенностей организма, помешавших всем нам стать примами Большого театра. Роберт Мартин, тот самый дядюшка Боб с благостной улыбкой гуру, провозглашает: чистый код должен быть элегантным и эффективным, прямолинейным, как хорошая проза. Грейди Буч добавляет, что чистый код читается как хорошо написанный текст, он не заставляет ваш мозг кипеть от усилий понять замысел автора. Бьёрн Страуструп, создатель C++, того самого языка, который уже лет 15 в должной мере не знает никто в мире, и где шаблоны могут занимать полстраницы, утверждает, что чистый код делает одну вещь, но делает её хорошо. А Уорд Каннингем завершает этот хор оптимистов заявлением, что код чист, когда каждая функция делает именно то, что вы ожидали.
Прекрасно. Теперь, когда мы определились с тем, что чистый код — это единорог программирования, существующий в параллельной вселенной, где менеджеры не торопят с дедлайнами, а заказчики точно знают, чего хотят, давайте поговорим о реальности.
Я позаимствовал КДПВ с сайта «Как работает гомеопатия», потому что лучше на этот вопрос ответить невозможно:
Давайте пройдёмся по пунктам.
Чистый код экономит время в долгосрочной перспективе
Этот перл особенно любят повторять на конференциях, потягивая бесплатный кофе и делая вид, что никогда не забивали в кодовую базу костыли пятничными вечерами. В теории звучит убедительно: потратьте час на рефакторинг сейчас, сэкономите неделю через полгода. На практике же выясняется, что через полгода весь этот прекрасно отрефакторенный модуль выброшен на помойку, потому что бизнес развернулся на сто восемьдесят градусов, а вы всё это время полировали архитектуру, которая никому не нужна. Чистый код экономит время примерно так же, как дорогой спортзал экономит ваше здоровье — в теории да, но абонемент всё равно пылится в дальнем ящике стола.
Названия должны быть самодокументирующими
Ах, эти волшебные имена переменных. UserAccountManagerFactoryBuilderSingleton — теперь всем сразу понятно, что делает этот класс, правда? Не нужно никакой документации, когда у вас такие говорящие названия. Проблема в том, что код превращается в словесный понос, где каждая строчка расползается за границы экрана, а вы скроллите горизонтально, пытаясь понять, где же кончается это проклятое имя метода. И знаете что самое смешное? Через месяц выясняется, что UserAccountManager на самом деле только отправляет письма, а управлением занимается UserService, но переименовать уже страшно, потому что это сломает половину проекта.
Функции должны быть короткими
Дядюшка Боб говорит: функция не должна быть длиннее пяти строк. Прекрасный совет, если вы пишете калькулятор для начальной школы. В реальном мире следование этому правилу превращает вашу кодовую базу в матрёшку: функция вызывает функцию, которая вызывает функцию, которая вызывает функцию. Чтобы понять, что же на самом деле происходит при нажатии кнопки «отправить», — вам нужно нырнуть на семь уровней вглубь, открыть двадцать файлов и составить блок-схему на ватмане. Поздравляю, ваш код теперь чист как слеза, и столь же бесполезен для понимания логики.
Комментарии — признак плохого кода
«Если вам нужно написать комментарий, значит ваш код недостаточно выразителен.»
Это — мантра чистого кода, которую повторяют как заклинание. Результат предсказуем: вы смотрите на битовые операции, на хитрый алгоритм оптимизации или на обход бага в стороннем API, и нигде ни слова объяснения, почему это работает именно так. Предыдущий разработчик был уверен, что его код самодокументируется, а вы три часа гуглите, пытаясь понять, зачем он сдвигает биты влево и складывает их с какой-то магической константой. Спойлер: это был обход бага в драйвере, но теперь драйвер обновился, код можно упростить, но никто этого не знает, потому что комментариев нет.
DRY (Don’t Repeat Yourself) священен
Увидели две похожие функции? Немедленно абстрагируйте. Три строчки повторяются? — В отдельный метод. В результате вы получаете систему настолько переплетённую общими абстракциями, что изменение одной строки где-то в глубинах вашей архитектуры ломает функциональность в трёх несвязанных модулях. А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи, и вам приходится добавлять параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю.
Тут я должен оговориться, ведь проницательные читатели обязательно припомнят мне, как я триста раз говорил: «думайте на шаг вперёд, YAGNI — враг, лучше один раз отмерить сейчас, чем семь раз перекраивать потом». Всё так, тут нет противоречий. Если кусок кода выглядит как отчуждаемый в абстракцию, и крякает так же — не нужно ждать второго повторения, выносите сразу. Если же нет — лучше копипаста, чем сторонний модуль utils с кучей одноразовых, как презервативы, функций. Просто надо руководствоваться здравым смыслом, а не принципами «чистого кода».
Тесты делают код чище
TDD фанатики обещают, что если вы пишете тесты до того, как приступаете к реализации, — ваш код автоматически становится чище. Практика показывает, что вы просто получаете две кодовых базы вместо одной, и обе требуют поддержки. Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре, другая половина настолько хрупкая, что ломается от любого рефакторинга. А покрытие в девяносто процентов даёт вам ложное чувство безопасности, пока в продакшене не выясняется, что оставшиеся десять процентов — это как раз критичная логика оплаты.
Покрытие вообще — метрика так себе. У меня есть библиотека со 100% покрытием, и я там буквально на днях нашел бажину размером с тропического таракана. Один из наших старых микросервисов, написанных мной 10 лет назад за неделю и приносящий десятки миллионов ежегодно — не покрыт юнитами вовсе, потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ в продакшене с очень подробным логом и немедленная подстройка под изменившийся без объявления войны интерфейс третьесторонних API.
SOLID принципы решают все проблемы
Ой, ну да, серебряная пуля. Единственная ответственность, открытость для расширения, подстановка Лисков, разделение интерфейсов, инверсия зависимостей — звучит это всё как заклинания из Гарри Поттера, и примерно настолько же применимо в реальной жизни. Попытка следовать всем пяти принципам одновременно превращает простой CRUD в архитектурный шедевр из двадцати слоёв абстракции, где для добавления одного поля в форму нужно изменить семь интерфейсов, создать три новых класса и обновить конфигурацию dependency injection контейнера. А потом приходит новый разработчик, смотрит на всё это великолепие и спрашивает: «А нельзя было просто поле в базу добавить?».
Вот и вся правда о чистом коде. Он не работает не потому что принципы неверны — нет, в вакууме они прекрасны. Он не работает потому что реальный мир грязен, хаотичен и непредсказуем (и асинхронен ещё, да). Потому что дедлайны не переносятся, требования меняются, бюджеты заканчиваются, а заказчик хочет всё и сразу. Потому что идеальный код — это код, который решает реальную проблему вчера, а не тот, который будет элегантен в учебнике послезавтра.
Лучший код, который я видел в своей практике, нарушал добрую половину принципов чистого кода. Он был прямолинейным, иногда грубым, с комментариями там, где они нужны, и без излишних абстракций там, где они не нужны. Он работал, его можно было понять и изменить. А это, как оказывается, и есть настоящая чистота — не в следовании догмам, а в решении задач.
Вот только формализуется такой подход очень плохо (именно этому факту мы обязаны появлением такого странного термина, как «идиоматический код»). Продать книжку миллионными тиражами, или курсы, или консалтинг — практически невозможно. Поэтому гораздо выгоднее выдумать термин, построить вокруг него теорию, показать на игрушечных примерах, что всё работает… — И заняться чем-то ещё, например, начать разводить тритонов.
Кто узнал отсылку из предыдущего предложения — тот трухакер.
Комментарии (57)
Arm79
07.01.2026 06:54То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
VladimirFarshatov
07.01.2026 06:54Всё верно и у автора и у вас. Вы просто про разное: автор про то, что не надо абсолютизировать "чистый код" (с гиперболами конечно же) а Вы про то, что он бывает полезен (с примитивизмами, как без них). Истина как обычно - посередине. Просто прежде чем молиться на фетиши, надо включать голову. Тогда и SOLID и DDD и отказ от них будут в тему.
rukhi7
07.01.2026 06:54Истина как обычно - посередине.
мне вот кажется что это не верное утверждение. Истина не посередине, она зависит от сложности предметной области. Так же как в физике теория относительности не отменяет классической механики! - Верна И теория относительности И классическая механика, только до определенных границ потому что применение теории относительности в задачах с определенными ограничениями на физические параметры явно избыточно. Так же и в программировании при определенных параметрах алгоритмов к реализации и самой кодовой базы SOLID, например, приплетать бессмысленно и явно избыточно.
VladimirFarshatov
07.01.2026 06:54Так это и есть "золотая середина", не находите? Чистый код не более чем рекомендация, но полно команд, где книги или не читали, или читали но не поняли и ставят их аки алтарь для молельни.
"Дуракам законе на писан" .. есть продолжение: ".. если писан, то не читан. Если читан, то не понят. Если понят, то не всеми. Если всеми, то не так". Увы, но команд где "чистый код" возведен в аксиому и требуется на ревью безальтернативно - гораздо больше чем кажется. А разбирать его: UserLocalParameter и UserLocalParameters -- первое переменная, второе - массив. Разница в одной букве, что при километровых именах пропускается мимо глазок на раз, только в путь. Реальный кейс, две функции, у одной переменная у второй массив. При 5-и параметрах просмотреть "раз плюнуть".
rukhi7
07.01.2026 06:54Так это и есть "золотая середина", не находите?
да я наверно маленько про другое. Есть программирование чтобы что-то посчитать, вывести на консоль, а есть программирование чтобы создать какую-то более менее глобальную систему с графическим интерфейсом для одновременной работы нескольких (даже нескольких, даже двух - это уже признак задачи другого уровня) пользователей. Принципы построения программ будут разные в зависимости от масштаба задач для программирования. Что хорошо в одном случае будет вызывать вопросы об адекватности в другом. Здесь нет середины - надо уметь выбирать методы которые подходят для решения конкретной задачи. Я вот что имел ввиду.
Вот например я написал про Абсолютную Инкапсуляцию. Если можно обеспечить такую Абсолютную Инкапсуляцию это же не значит что ее надо пихать везде где попало, надо же понимать где ее можно и нужно применять, а где нет. Какая тут может быть середина? Мы либо понимаем и адекватно используем, либо нет и расшибаем лоб о ее неадекватное применение.
Lewigh
07.01.2026 06:54А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования.
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось.
Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.А если у вас более сложная архитектура?
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
Arm79
07.01.2026 06:54Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
panzerfaust
07.01.2026 06:54Чистый код не работает у тех, кто сам сделал из него религию. Сотворили себе божество и, как водится, принялись расшибать лоб. Расшибли. Далее божество низвергается и создается новое анти-божество.
Для людей со здоровой психикой "Чистый код" и подобные книги это просто набор советов, а не Священное Писание. Дельный совет - бери, плохой совет - не бери. И тех и других там хватает. А хотите какого-то высшего абсолюта - ну реально идите в церковь, в не в ИТ.
rukhi7
07.01.2026 06:54это прям красиво получилось-написано! Фауст должен быть доволен, как и его автор!
Примите наше восхищение.
levlebedev92
07.01.2026 06:54Правильно, это набор советов, которых можно придерживаться в какой-то степени, но если придерживаться на все 100%, то это уже становится фанатизмом, а он в любых своих проявлениях - опасный звоночек
rukhi7
07.01.2026 06:54сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды.
а еще сначала мы учим простую механику в которой путь пропорционален скорости, а потом выясняется что с изменением скорости изменяется само течение времени и появляется некоторая неопределенность. Это тоже надо сразу с пятого класса детям объяснить чтобы они не путались потом? Или с четвертого, с третьего, ... ?
evomed
07.01.2026 06:54Наличие кучи абстракций, классов и методов не означает, что у тебя чистый код. С ними, внезапно - тоже надо уметь работать и логически организовывать. Работать в приложении с четкой компонентной архитектурой - это кайф. В отличие от копания в простынях говнокода где все уже перемешалось и практически нереально уже отследить связи (сейчас, как раз рефакторю свой легаси сервис и многое переписываю с нуля). Тесты должны помогать в работе, а не быть источником проблем. Их тоже надо уметь писать. Лично я пишу все виды тестов (функциональные, юнит, браузерные), но не потому что это нужно и правильно (такими категориями лучше вообще не думать), а потому что не люблю тестить руками. Мне нравится в клик мышки создать нужное окружение, открыть браузер в нужной точке и внести функциональность, а не сидеть и регистрировать аккаунты и тд просто, чтобы посмотреть, как там кнопочка отображается. Или поднимать сложное окружение, чтобы проверить отправляет ли класс нужное уведомление нужному пользователю.
vvbob
07.01.2026 06:54Наличие кучи абстракций, классов и методов не означает, что у тебя чистый код. С ними, внезапно - тоже надо уметь работать и логически организовывать. Работать в приложении с четкой компонентной архитектурой - это кайф. В отличие от копания в простынях говнокода где все уже перемешалось и практически нереально уже отследить связи (сейчас, как раз рефакторю свой легаси сервис и многое переписываю с нуля).
Да в общем обе крайности плохи. Доводилось копаться в лапше с методами в несколько тысяч строк, и в суперабстрактной абстракщине, в котором даже что-бы просто понять какой кусок кода выполняется, надо было целое исследование проводить, иногда не на один день. Что то дерьмо, что другое.. В общем без здравого смысла никуда, хоть еги и не формализуешь никак.
victor_1212
07.01.2026 06:54про здравый смысл правильно, плюс зависит от environment, если ответственность, типа серьезный real time, главный признак качественного кода это хорошая читабильность + быстрая отладка, т.е. почти все заранее продумано, приходилось работать с опытными людьми у которых код надежно работает почти сразу, по опыту это один из главных критериев высокой квалификации
vvbob
07.01.2026 06:54Просто надо руководствоваться здравым смыслом, а не принципами «чистого кода».
Идеальный, универсальный совет! Жаль только что здравый смысл у разных людей выглядит по разному и результаты его применения часто несовместимы.
ИМХО все эти попытки вывести формулу "чистого кода" похожи на попытку объяснить человеку, ни разу не видевшего воды больше чем в стакане, как надо плавать в море. Пока сам не
утонешьнахлебаешься воды, хрен поймешь даже эти объяснения, не то что-бы научиться плавать.
Tishka17
07.01.2026 06:54Хуже, при внимательном рассмотрении здравый смысл оказывается просто когнитивными искажениями.
CrazyOpossum
07.01.2026 06:54Здравый смысл - (под-)сознательный вывод из опыта (своего или чужого). Меня сильно триггернуло, что Мартин, зовущий себя архитектором, в 70 лет радостно открыл для себя SICP и сейчас пописывает на лиспе. Инженеру с таким кругозором нельзя писать книги по архитектуре.
Tishka17
07.01.2026 06:54Меня тоже это триггернуло. Но при этом я отдаю себе отчёт, что никакой вывод только на основании этой информации я сделал не могу.
NikolayPyanikov
07.01.2026 06:54Очередная статья наброса говна на вентилятор и яркий пример избирательного восприятия.
SecondUniverse
07.01.2026 06:54Да. Автор прав. Сам на проекте где все молятся на чистый код. При этом архитектурой приложения Лид считает SOLID. Типо само всё заработает. Глюк на клюке, одно правится, другое отваливается. Хорошо хоть есть смежные задачи в виде отдельных модулей. Фактически туда сбежал и применяю там здравый смысл. И вот удивительно, что при таком подходе сразу всё работает!
Применяйте здравый смысл и делайте архитектуру, прежде чем писать что-то большое. Спасибо автору поста. Он обнадежил, что не все свихнулась.
fransua
07.01.2026 06:54Мне кажется у Вас довольно превратное представление о чистом коде - примеры которые вы привели имеют мало общего с оригинальными идеями Мартина.
Вы читали его книгу?
dimas846
07.01.2026 06:54Развитие здоровой идеи до ее логического, предела, когда она превращается в свою противоположность, это логический прием (reductio ad absurdum), который используется для критики, чтобы показать несостоятельность изначального положения, преувеличивая его до нелепости.
В каждой из приведенных книг и подходах, если не ошибаюсь, есть замечания, что не надо ударяться в крайности. Программист, который никогда не читал "чистый код" и подобное, или читавший, но не нашедший там для себя чего-то полезного, скорее всего будет не очень крут.
Статья понравилась!
Akon32
07.01.2026 06:54Проблема в том, что книга пропагандирует крайности. И если "Чистая архитектура" воспринимается многими как излишнее усложнение и редко претворяется в жизнь, то совет "не писать комментарии" из "Чистого кода" большинством используется как оправдание лени и хаоса в проекте. А с Автором Популярной Книги бывает сложно спорить, потому как с одной стороны - наш местячковый тимлид, а с другой - их прекрасный Роберт Мартин.
Scrawach
07.01.2026 06:54Проблема в том, что книга пропагандирует крайности.
Нет. Проблема в том, что глава "комментарии" в книге "чистый код" занимает ~22 страницы размышлений о том, какие комментарии вредны, а какие необходимы. Но для некоторых это оказывается слишком сложным, отчего всё сводится к максимально догматичному: "комментарии писать нельзя". Потому что так проще. Ирония здесь в том, что автор статьи, затрагивая тему комментариев, разбивает аргументы из чистого кода с помощью... чистого кода.
vkni
07.01.2026 06:54А покрытие в девяносто процентов даёт вам ложное чувство безопасности, пока в продакшене не выясняется, что оставшиеся десять процентов — это как раз критичная логика оплаты.
Не 10%, а нетестируемые пути исполнения. Их гораздо больше, чем 10% — если у вас последовательно стоят 3 if-else, то путей выполнения 8 штук, а минимальное 100% покрытие тестирует 2.
А если вы вызываете какие-то библиотечные функции, то в полном графе выполнения при 100% покрытии ваших строк кода тестируется вообще ничтожная доля путей выполнения.
Johnny_Depp
"Названия должны быть самодокументирующими" А что не так? Надо называть fun1 fun2 ? Это хороший подход, который не исключает документацию, а если название не отображает сути, так ну чья это проблема? Подхода? Или того кто этим пользуется?
"Он не работает потому что реальный мир грязен, хаотичен и непредсказуем (и асинхронен ещё, да)." - да, настолько хаотичен и непредсказуем, что существует логистика, просчёт траекторий и т.п.
"DRY (Don’t Repeat Yourself) священен" - ну не надо из крайностей в крайность, этот подход о том, что если часто, что-то повторяется, скорей всего это можно вынести в отдельную функцию.
VladimirFarshatov
Во всем нужна мера. Автор - прав, как ни парадоксально. Где-то, в бизнес логике полезен и SOLID, а где-то он треш и угар, особенно в разных системах бигдаты и реального времени, да везде, где выражение "Цена команды процессора" имеет смысл.
vvbob
По факту - следуя любым идеям, надо вовсю использовать здравый смысл, потому что даже хороший, годный принцип может привести к адовому коду, если следовать ему бездумно и механистически. Т.е. попросту умение создавать хороший код не формализуется до набора простых и эффективных правил.
8bityeti
DRY это не про повторяющиеся методы/функции.
Это про делится знаниями между модулями.
Johnny_Depp
https://yandex.ru/search/?clid=11450072&text=DRY+(Don’t+Repeat+Yourself)+подход&l10n=ru&lr=222
Почитайте.
"DRY (Don’t Repeat Yourself) - принцип разработки программного обеспечения, направленный на минимизацию дублирования информации в коде. С английского переводится как «не повторяйся». "
"Если в коде или логике программы есть повторяющиеся фрагменты, их следует реорганизовать так, чтобы они присутствовали только в одном месте. "
8bityeti
уважаемый, человечество священные книги не так поняли, понимают, что ещё говорить про ООП от Алана Кая и этого DRY….