Начнём с наведения аксиоматики, потому что без неё любая дискуссия сводится к измерению физиологических особенностей организма, помешавших всем нам стать примами Большого театра. Роберт Мартин, тот самый дядюшка Боб с благостной улыбкой гуру, провозглашает: чистый код должен быть элегантным и эффективным, прямолинейным, как хорошая проза. Грейди Буч добавляет, что чистый код читается как хорошо написанный текст, он не заставляет ваш мозг кипеть от усилий понять замысел автора. Бьёрн Страуструп, создатель C++, того самого языка, который уже лет 15 в должной мере не знает никто в мире, и где шаблоны могут занимать полстраницы, утверждает, что чистый код делает одну вещь, но делает её хорошо. А Уорд Каннингем завершает этот хор оптимистов заявлением, что код чист, когда каждая функция делает именно то, что вы ожидали.
Прекрасно. Теперь, когда мы определились с тем, что чистый код — это единорог программирования, существующий в параллельной вселенной, где менеджеры не торопят с дедлайнами, а заказчики точно знают, чего хотят, давайте поговорим о реальности.
Я позаимствовал КДПВ с сайта «Как работает гомеопатия», потому что лучше на этот вопрос ответить невозможно:
Давайте пройдёмся по пунктам.
Чистый код экономит время в долгосрочной перспективе
Этот перл особенно любят повторять на конференциях, потягивая бесплатный кофе и делая вид, что никогда не забивали в кодовую базу костыли пятничными вечерами. В теории звучит убедительно: потратьте час на рефакторинг сейчас, сэкономите неделю через полгода. На практике же выясняется, что через полгода весь этот прекрасно отрефакторенный модуль выброшен на помойку, потому что бизнес развернулся на сто восемьдесят градусов, а вы всё это время полировали архитектуру, которая никому не нужна. Чистый код экономит время примерно так же, как дорогой спортзал экономит ваше здоровье — в теории да, но абонемент всё равно пылится в дальнем ящике стола.
Названия должны быть самодокументирующими
Ах, эти волшебные имена переменных. UserAccountManagerFactoryBuilderSingleton — теперь всем сразу понятно, что делает этот класс, правда? Не нужно никакой документации, когда у вас такие говорящие названия. Проблема в том, что код превращается в словесный понос, где каждая строчка расползается за границы экрана, а вы скроллите горизонтально, пытаясь понять, где же кончается это проклятое имя метода. И знаете что самое смешное? Через месяц выясняется, что UserAccountManager на самом деле только отправляет письма, а управлением занимается UserService, но переименовать уже страшно, потому что это сломает половину проекта.
Функции должны быть короткими
Дядюшка Боб говорит: функция не должна быть длиннее пяти строк. Прекрасный совет, если вы пишете калькулятор для начальной школы. В реальном мире следование этому правилу превращает вашу кодовую базу в матрёшку: функция вызывает функцию, которая вызывает функцию, которая вызывает функцию. Чтобы понять, что же на самом деле происходит при нажатии кнопки «отправить», — вам нужно нырнуть на семь уровней вглубь, открыть двадцать файлов и составить блок-схему на ватмане. Поздравляю, ваш код теперь чист как слеза, и столь же бесполезен для понимания логики.
Комментарии — признак плохого кода
«Если вам нужно написать комментарий, значит ваш код недостаточно выразителен.»
Это — мантра чистого кода, которую повторяют как заклинание. Результат предсказуем: вы смотрите на битовые операции, на хитрый алгоритм оптимизации или на обход бага в стороннем API, и нигде ни слова объяснения, почему это работает именно так. Предыдущий разработчик был уверен, что его код самодокументируется, а вы три часа гуглите, пытаясь понять, зачем он сдвигает биты влево и складывает их с какой-то магической константой. Спойлер: это был обход бага в драйвере, но теперь драйвер обновился, код можно упростить, но никто этого не знает, потому что комментариев нет.
DRY (Don’t Repeat Yourself) священен
Увидели две похожие функции? Немедленно абстрагируйте. Три строчки повторяются? — В отдельный метод. В результате вы получаете систему настолько переплетённую общими абстракциями, что изменение одной строки где-то в глубинах вашей архитектуры ломает функциональность в трёх несвязанных модулях. А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи, и вам приходится добавлять параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю.
Тут я должен оговориться, ведь проницательные читатели обязательно припомнят мне, как я триста раз говорил: «думайте на шаг вперёд, YAGNI — враг, лучше один раз отмерить сейчас, чем семь раз перекраивать потом». Всё так, тут нет противоречий. Если кусок кода выглядит как отчуждаемый в абстракцию, и крякает так же — не нужно ждать второго повторения, выносите сразу. Если же нет — лучше копипаста, чем сторонний модуль utils с кучей одноразовых, как презервативы, функций. Просто надо руководствоваться здравым смыслом, а не принципами «чистого кода».
Тесты делают код чище
TDD фанатики обещают, что если вы пишете тесты до того, как приступаете к реализации, — ваш код автоматически становится чище. Практика показывает, что вы просто получаете две кодовых базы вместо одной, и обе требуют поддержки. Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре, другая половина настолько хрупкая, что ломается от любого рефакторинга. А покрытие в девяносто процентов даёт вам ложное чувство безопасности, пока в продакшене не выясняется, что оставшиеся десять процентов — это как раз критичная логика оплаты.
Покрытие вообще — метрика так себе. У меня есть библиотека со 100% покрытием, и я там буквально на днях нашел бажину размером с тропического таракана. Один из наших старых микросервисов, написанных мной 10 лет назад за неделю и приносящий десятки миллионов ежегодно — не покрыт юнитами вовсе, потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ в продакшене с очень подробным логом и немедленная подстройка под изменившийся без объявления войны интерфейс третьесторонних API.
SOLID принципы решают все проблемы
Ой, ну да, серебряная пуля. Единственная ответственность, открытость для расширения, подстановка Лисков, разделение интерфейсов, инверсия зависимостей — звучит это всё как заклинания из Гарри Поттера, и примерно настолько же применимо в реальной жизни. Попытка следовать всем пяти принципам одновременно превращает простой CRUD в архитектурный шедевр из двадцати слоёв абстракции, где для добавления одного поля в форму нужно изменить семь интерфейсов, создать три новых класса и обновить конфигурацию dependency injection контейнера. А потом приходит новый разработчик, смотрит на всё это великолепие и спрашивает: «А нельзя было просто поле в базу добавить?».
Вот и вся правда о чистом коде. Он не работает не потому что принципы неверны — нет, в вакууме они прекрасны. Он не работает потому что реальный мир грязен, хаотичен и непредсказуем (и асинхронен ещё, да). Потому что дедлайны не переносятся, требования меняются, бюджеты заканчиваются, а заказчик хочет всё и сразу. Потому что идеальный код — это код, который решает реальную проблему вчера, а не тот, который будет элегантен в учебнике послезавтра.
Лучший код, который я видел в своей практике, нарушал добрую половину принципов чистого кода. Он был прямолинейным, иногда грубым, с комментариями там, где они нужны, и без излишних абстракций там, где они не нужны. Он работал, его можно было понять и изменить. А это, как оказывается, и есть настоящая чистота — не в следовании догмам, а в решении задач.
Вот только формализуется такой подход очень плохо (именно этому факту мы обязаны появлением такого странного термина, как «идиоматический код»). Продать книжку миллионными тиражами, или курсы, или консалтинг — практически невозможно. Поэтому гораздо выгоднее выдумать термин, построить вокруг него теорию, показать на игрушечных примерах, что всё работает… — И заняться чем-то ещё, например, начать разводить тритонов.
Кто узнал отсылку из предыдущего предложения — тот трухакер.
Комментарии (81)
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Так это и есть "золотая середина", не находите?
да я наверно маленько про другое. Есть программирование чтобы что-то посчитать, вывести на консоль, а есть программирование чтобы создать какую-то более менее глобальную систему с графическим интерфейсом для одновременной работы нескольких (даже нескольких, даже двух - это уже признак задачи другого уровня) пользователей. Принципы построения программ будут разные в зависимости от масштаба задач для программирования. Что хорошо в одном случае будет вызывать вопросы об адекватности в другом. Здесь нет середины - надо уметь выбирать методы которые подходят для решения конкретной задачи. Я вот что имел ввиду.
Вот например я написал про Абсолютную Инкапсуляцию. Если можно обеспечить такую Абсолютную Инкапсуляцию это же не значит что ее надо пихать везде где попало, надо же понимать где ее можно и нужно применять, а где нет. Какая тут может быть середина? Мы либо понимаем и адекватно используем, либо нет и расшибаем лоб о ее неадекватное применение.
Zalechi
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Меня тоже это триггернуло. Но при этом я отдаю себе отчёт, что никакой вывод только на основании этой информации я сделал не могу.
vvbob
07.01.2026 06:54В сущности все человеческое мышление - это лютая солянка из кучи когнитивных искажений :)
Если бы меня кто-то из джунов спросил, как научиться "чистому коду", я бы не стал советовать читать талмуды всяких там пророков IT, а вместо этого посоветовал бы читать как можно больше кода. Только с опытом чтения и написания кода начинает приходить какое-то понимание что такое хороший код, а что такое код плохой. Тогда только, может быть, стоит аккуратно и включив на максимум критическое мышление, почитать что-либо из опусов всевозможных философов от IT. Обратный порядок, как правило, джунов ломает, превращает их в фанатиков-говнокодеров, бездумно пихающих в код спорные концепции из популярных книг.
NikolayPyanikov
07.01.2026 06:54Очередная статья наброса говна на вентилятор и яркий пример избирательного восприятия.
Zalechi
07.01.2026 06:54Аргументы автора я услышал. Можно Вашу позицию увидеть?
NikolayPyanikov
07.01.2026 06:54Не планировал комментировать эту статью, поскольку, похоже, именно на такие эмоциональные отклики она и рассчитана. Однако не могу не высказаться: на мой взгляд, материал носит ярко выраженный кликбейтный характер. Автор стремится привлечь внимание и сформировать репутацию, избегая глубокой проработки темы.
Основная проблема — манипулятивный стиль подачи. Автор поверхностно затрагивает сложные, многоаспектные вопросы (чистый код, принципы проектирования, тестирование), которые в профессиональной среде обсуждаются годами, а затем:
выдвигает упрощённые или заведомо спорные тезисы
демонстрирует их «абсурдность» через гиперболизированные примеры
делает выводы, создавая иллюзию лёгкого решения сложных проблем
Разберу ключевые моменты.
Чистый код экономит время в долгосрочной перспективе. Этот перл особенно любят повторять на конференциях, потягивая бесплатный кофе и делая вид, что никогда не забивали в кодовую базу костыли пятничными вечерами. В теории звучит убедительно: потратьте час на рефакторинг сейчас, сэкономите неделю через полгода. На практике же выясняется, что через полгода весь этот прекрасно отрефакторенный модуль выброшен на помойку, потому что бизнес развернулся на сто восемьдесят градусов, а вы всё это время полировали архитектуру, которая никому не нужна. Чистый код экономит время примерно так же, как дорогой спортзал экономит ваше здоровье — в теории да, но абонемент всё равно пылится в дальнем ящике стола.
Автор противопоставляет теорию и практику, но не приводит ни статистики, ни конкретных кейсов. Утверждение, что бизнес «разворачивается на 180 градусов» и весь рефакторинг оказывается бесполезным, — это крайность. Такой подход равносилен отказу от проектирования: мол, зачем что-то делать, если всё может измениться? Или автор предпочитает лететь на самолёте, который делали из расчета, что на нем никто не полетит? Просто абсурдная логика.
Названия должны быть самодокументирующими. Ах, эти волшебные имена переменных. UserAccountManagerFactoryBuilderSingleton — теперь всем сразу понятно, что делает этот класс, правда? Не нужно никакой документации, когда у вас такие говорящие названия. Проблема в том, что код превращается в словесный понос, где каждая строчка расползается за границы экрана, а вы скроллите горизонтально, пытаясь понять, где же кончается это проклятое имя метода. И знаете что самое смешное? Через месяц выясняется, что UserAccountManager на самом деле только отправляет письма, а управлением занимается UserService, но переименовать уже страшно, потому что это сломает половину проекта.
Пример с UserAccountManagerFactoryBuilderSingleton — явная карикатура. Конечно, избыточно длинные имена — проблема, но альтернатива в виде A, B ещё хуже. Здравый подход — искать баланс: имена должны быть понятными, но не перегруженными. Критика автора выглядит как атака на крайность, которой в реальности почти никто не придерживается. Где аргумены что бы не давать нормальные навзвания?
Функции должны быть короткими. Дядюшка Боб говорит: функция не должна быть длиннее пяти строк. Прекрасный совет, если вы пишете калькулятор для начальной школы. В реальном мире следование этому правилу превращает вашу кодовую базу в матрёшку: функция вызывает функцию, которая вызывает функцию, которая вызывает функцию. Чтобы понять, что же на самом деле происходит при нажатии кнопки «отправить», — вам нужно нырнуть на семь уровней вглубь, открыть двадцать файлов и составить блок-схему на ватмане. Поздравляю, ваш код теперь чист как слеза, и столь же бесполезен для понимания логики.
Автор ссылается на «дядюшку Боба», но искажает контекст. Принцип коротких функций связан с SRP (Single Responsibility Principle): каждая функция решает одну задачу. Это не догмат, а стратегия упрощения кода. Альтернатива — монолитные блоки с комментариями, которые:
сложнее тестировать
труднее переиспользовать
нарушают принцип DRY
Критика в стиле «придётся открыть 20 файлов» — это проблема структуры проекта, а не самих функций. Уменьшение размера сущностей — это стратегия «разделяй и властвуй» для того, чтобы сделать код чище, проще, понятнее. Это рекомендация, а не правило. Альтернатива - большие и сложные функции с кучей комментариев (см. следующий пункт автора «Комментарии — признак плохого кода»), которые могли бы быть в именах функций)), и, очевидно, невозможность переиспользование кода, как маленьких кирпичиков, см. пункт автора про «DRY (Don’t Repeat Yourself) священен»)) Пропущу обсуждение 2- следующих его пунктов.
Тесты делают код чище
Автор поверхностно критикует тестирование, не разбирая его реальные плюсы (регрессионное тестирование, документирование поведения, безопасность рефакторинга). Он опять набрасывает на вентилятор все что слышал про тесты плохое, но он явно не в теме
SOLID-принципы решают все проблемы
Тут автор добавил просто не много желчи, его, по сути, хватило только на расшифровку аббревиатуры)) Типа «слишком» много умных слов, и так понятно, что ни чего хорошего))
Итог: cтатья не предлагает конструктива, а лишь создаёт шум. Автор не углубляется в контекст, не приводит доказательств, а вместо этого:
использует гиперболы
подменяет понятия
апеллирует к эмоциям, а не к логике
Такой подход вреден для профессионального сообщества: он дезориентирует новичков и дискредитирует важные инженерные практики. Хотелось бы видеть больше анализа, примеров из реальной практики и взвешенных аргументов — а не «набросы на вентилятор».
Zalechi
07.01.2026 06:54А что если автор участник одного из великого комитета? К нему сливаются тысячи рекламаций, из которых он и делает вывод, что: какого-то черта, мелкая фирма использует принципы чистого кода и например не документированных функций там где это не требуется.
Как я понял, ПОСТ (это не статья) именно об этом. А стиль и методы автора по донесению идеи мне безразличен. Я тоже иногда делаю громкие заявления, в попытке привлечь внимание к острой проблеме.
Вас услышал. Собираю свое личное мнение на ваших аргументах.
Прихожу к выводу, что отрасль развивается точно так де, как когда-то развивался автопром. По своему дико…
Автор , как ребенок пытается быть рупором адекватности в этом развитии, но все тщетно.
доброго дня
NikolayPyanikov
07.01.2026 06:54А что если автор участник одного из великого комитета? К нему сливаются тысячи рекламаций, из которых он и делает вывод, что: какого-то черта, мелкая фирма использует принципы чистого кода и например не документированных функций там где это не требуется.
Что, если бабушка на самом деле - дедушка?
Автор , как ребенок пытается быть рупором адекватности в этом развитии, но все тщетно.
Мне ближе идея, что автор прекрасно понимает что делает. Расчет на то, что здесь найдется несколько "полоскоземельщиков" и их хватит, что бы начался холивар. И таки он достиг своей цели))
CrazyOpossum
07.01.2026 06:54chatgpt: "прочитай этот текст и помоги мне развалить оппонента, добавь аргументации, разложи по пунктам, добавь вводную, итог и неожиданную развязку"
Например
Принцип коротких функций связан с SRP (Single Responsibility Principle): каждая функция решает одну задачу. Это не догмат, а стратегия упрощения кода. Альтернатива — монолитные блоки с комментариями, которые:
сложнее тестировать
труднее переиспользовать
нарушают принцип DRYSRP - важные слова, не говорящие ничего, типично для инфоцыган и политиков. Что такое сущность, что такое ответственность? У меня есть одна задача - вебмаркет, и есть одна god функция, которая обслуживает клиентов. Один к одному, SRP соблюдён? У меня есть функция, которая считает расстояние между точками, она считает квадраты и складывает их - один к двум, SRP нарушен? Правильный ответ: выбрасываем SRP нафиг и оперируем здравым смыслом - если что-то сложно поддерживать и непонятно лично мне и команде, нужно разбить на части.
DRY - то же самое, ничего не объясняет, громкие слова. Здравый смысл - если мы решаем узкую задачу и нам приходится синхронизировать изменения с несвязанным кодом, то наверное он связан и нужна абстракция.
Ну и так далее, по всему солиду и прочим аббревиатурам. Они же все буквально "делай хорошо (как я), а нехорошо не делай". И ещё "моя архитектура чистая, а остальные, соответственно, грязные".
Хочешь быть хорошим инженером - люби своё дело и больше читай/пиши/общайся за пределами своего пузыря, в других языках и парадигмах.
NikolayPyanikov
07.01.2026 06:54Нужно улучшить промпт))) Например начать с "Ты технический писатель и критик... приведи контраргументы..." лучше ещё пару примеров привести. Ну и в контекст добавить весь текст поста и все комментарии, и модельку получше использовать. Иначе не убедительно)))
CrazyOpossum
07.01.2026 06:54Вот теперь скобочки пошли, теперь верю что человек писал.
NikolayPyanikov
07.01.2026 06:54Ну так у меня в посте ошибки, LLM такие не делает (если не попросить)
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, а где-то он треш и угар, особенно в разных системах бигдаты и реального времени, да везде, где выражение "Цена команды процессора" имеет смысл.
Chaos_Optima
Все эти принципы и идеи нужно просто использовать так же как код от нейросети или с SO, не бездумно применять а простаивать под свои требования и виденье. Тоже относится ко всяким скрамам и прочим методологиям.
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….
Chaos_Optima
Может тогда проблема не в человечестве а в священных книгах?
8bityeti
Нет, суть в том что дай один текст десяти людям и каждый поймет по своему.
Вот например все накидывают минусов и тут два варианта (минимум): людей триггернуло про религию или за общепринятую ошибку интерпретации ООП от Алана Кая.
Zalechi
В них нет проблемы, они решали задачи своего времени и стввили постулаты на будущее. Будущее менялось, вот и некоторые постулаты устарели ( но не все устарели).
Пример: бог, в древней мифологии — этот просто царь, глава сообщества. Обычно ими становились самые ушлые и сильные. Конечно для своих современников они были «богами». Так же «обожествление» было политическим шагом. Надо держать сообщество в железных рукавицах.
То есть мы часто не адекватно идентифицируем древнюю терминологию.
А древних понять можно. Они объединяли абстрактные и реальные сущности в одно — и это было нормально. У них не было наших знаний, у них был ограниченный вокабуляр.
Выводы делайте сами. Для меня например бог это и ручей и камень и огонь, а еще Солнце. А когда мне очень плохо, то я в своих молитвах обращаюсь ко Христу.
Прикол в том, что я могу себе это позволить, а они?!
Lippiece
Автор имел в виду, что в самой книге по чистому коду названия, подобные описанным в статье. Уже была хорошая статья на эту тему на английском, с похожими постулатами, как тут. Было бы более понятно с примерами из книги, как в той статье.