Comments 81
"Названия должны быть самодокументирующими" А что не так? Надо называть fun1 fun2 ? Это хороший подход, который не исключает документацию, а если название не отображает сути, так ну чья это проблема? Подхода? Или того кто этим пользуется?
"Он не работает потому что реальный мир грязен, хаотичен и непредсказуем (и асинхронен ещё, да)." - да, настолько хаотичен и непредсказуем, что существует логистика, просчёт траекторий и т.п.
"DRY (Don’t Repeat Yourself) священен" - ну не надо из крайностей в крайность, этот подход о том, что если часто, что-то повторяется, скорей всего это можно вынести в отдельную функцию.
Во всем нужна мера. Автор - прав, как ни парадоксально. Где-то, в бизнес логике полезен и SOLID, а где-то он треш и угар, особенно в разных системах бигдаты и реального времени, да везде, где выражение "Цена команды процессора" имеет смысл.
По факту - следуя любым идеям, надо вовсю использовать здравый смысл, потому что даже хороший, годный принцип может привести к адовому коду, если следовать ему бездумно и механистически. Т.е. попросту умение создавать хороший код не формализуется до набора простых и эффективных правил.
если часто, что-то повторяется, скорей всего это можно вынести в отдельную функцию.
DRY это не про повторяющиеся методы/функции.
Это про делится знаниями между модулями.
https://yandex.ru/search/?clid=11450072&text=DRY+(Don’t+Repeat+Yourself)+подход&l10n=ru&lr=222
Почитайте.
"DRY (Don’t Repeat Yourself) - принцип разработки программного обеспечения, направленный на минимизацию дублирования информации в коде. С английского переводится как «не повторяйся». "
"Если в коде или логике программы есть повторяющиеся фрагменты, их следует реорганизовать так, чтобы они присутствовали только в одном месте. "
уважаемый, человечество священные книги не так поняли, понимают, что ещё говорить про ООП от Алана Кая и этого DRY….
Может тогда проблема не в человечестве а в священных книгах?
Нет, суть в том что дай один текст десяти людям и каждый поймет по своему.
Вот например все накидывают минусов и тут два варианта (минимум): людей триггернуло про религию или за общепринятую ошибку интерпретации ООП от Алана Кая.
В них нет проблемы, они решали задачи своего времени и стввили постулаты на будущее. Будущее менялось, вот и некоторые постулаты устарели ( но не все устарели).
Пример: бог, в древней мифологии — этот просто царь, глава сообщества. Обычно ими становились самые ушлые и сильные. Конечно для своих современников они были «богами». Так же «обожествление» было политическим шагом. Надо держать сообщество в железных рукавицах.
То есть мы часто не адекватно идентифицируем древнюю терминологию.
А древних понять можно. Они объединяли абстрактные и реальные сущности в одно — и это было нормально. У них не было наших знаний, у них был ограниченный вокабуляр.
Выводы делайте сами. Для меня например бог это и ручей и камень и огонь, а еще Солнце. А когда мне очень плохо, то я в своих молитвах обращаюсь ко Христу.
Прикол в том, что я могу себе это позволить, а они?!
Автор имел в виду, что в самой книге по чистому коду названия, подобные описанным в статье. Уже была хорошая статья на эту тему на английском, с похожими постулатами, как тут. Было бы более понятно с примерами из книги, как в той статье.
То, что бизнес может развернуть хотелки, вообще не влияет на рефакторинг. Из разряда - не буду мыть автомобиль шефа, не буду проходить ТО, все равно же завтра он его может продать и купить самокат.
Если у вас классы выполняют функции, отличные от их названия, как раз говорит о том, что рефакторингом в коде никто не занимался
Если "А потом выясняется, что те две «похожие» функции на самом деле делали немного разные вещи" - то это повод вернуть назад 2 функции с соответствующим комментарием, а не городить "параметры, флаги, условия, превращая элегантную абстракцию в монстра с десятком необязательных параметров и логикой, понятной только его создателю".
Чем вам не нравится TDD? "Половина тестов проверяет очевидные вещи вроде того, что два плюс два равно четыре" - ну не пишите такие тесты. Пишите, где они проверяют более осмысленную логику.
"потому что он полностью завязан на внешние источники, и единственный вариант его тестирования — элегантный отказ" - тестирование модуля, завязанного на внешние интеграции, осуществляется с применением mock-сервисов. Типа wiremock, mockoon.
Про solid - тоже неверно. Если у вас простейший crud, и логика в бд, то усложнять код не нужно. А если у вас более сложная архитектура? Это же как со строительством дома - сделать простейшую хибару проект не нужен. А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования. И серьезную перепланировку без заключения о прочностных характеристиках не получить. Хотя казалось бы, всего лишь снести одну несущую стену. То есть, я хотел сказать, пробросить какие то поля из базы на форму, минуя бизнес-логику
Всё верно и у автора и у вас. Вы просто про разное: автор про то, что не надо абсолютизировать "чистый код" (с гиперболами конечно же) а Вы про то, что он бывает полезен (с примитивизмами, как без них). Истина как обычно - посередине. Просто прежде чем молиться на фетиши, надо включать голову. Тогда и SOLID и DDD и отказ от них будут в тему.
Истина как обычно - посередине.
мне вот кажется что это не верное утверждение. Истина не посередине, она зависит от сложности предметной области. Так же как в физике теория относительности не отменяет классической механики! - Верна И теория относительности И классическая механика, только до определенных границ потому что применение теории относительности в задачах с определенными ограничениями на физические параметры явно избыточно. Так же и в программировании при определенных параметрах алгоритмов к реализации и самой кодовой базы SOLID, например, приплетать бессмысленно и явно избыточно.
Так это и есть "золотая середина", не находите? Чистый код не более чем рекомендация, но полно команд, где книги или не читали, или читали но не поняли и ставят их аки алтарь для молельни.
"Дуракам законе на писан" .. есть продолжение: ".. если писан, то не читан. Если читан, то не понят. Если понят, то не всеми. Если всеми, то не так". Увы, но команд где "чистый код" возведен в аксиому и требуется на ревью безальтернативно - гораздо больше чем кажется. А разбирать его: UserLocalParameter и UserLocalParameters -- первое переменная, второе - массив. Разница в одной букве, что при километровых именах пропускается мимо глазок на раз, только в путь. Реальный кейс, две функции, у одной переменная у второй массив. При 5-и параметрах просмотреть "раз плюнуть".
Так это и есть "золотая середина", не находите?
да я наверно маленько про другое. Есть программирование чтобы что-то посчитать, вывести на консоль, а есть программирование чтобы создать какую-то более менее глобальную систему с графическим интерфейсом для одновременной работы нескольких (даже нескольких, даже двух - это уже признак задачи другого уровня) пользователей. Принципы построения программ будут разные в зависимости от масштаба задач для программирования. Что хорошо в одном случае будет вызывать вопросы об адекватности в другом. Здесь нет середины - надо уметь выбирать методы которые подходят для решения конкретной задачи. Я вот что имел ввиду.
Вот например я написал про Абсолютную Инкапсуляцию. Если можно обеспечить такую Абсолютную Инкапсуляцию это же не значит что ее надо пихать везде где попало, надо же понимать где ее можно и нужно применять, а где нет. Какая тут может быть середина? Мы либо понимаем и адекватно используем, либо нет и расшибаем лоб о ее неадекватное применение.
Правильно глаголите!
Боже о чем вы спорите? Да, истина где-то по середине — это абстрактный и логичный вывод.
А как только начинаем смотреть МКД, нифига ж себе, оказываются есть архитектурные нормы и требования.
Нюанс в том что SOLID это не нормы и не требования. Это частное мнение Роберта Мартина, изложенное в его книгах и которое, по воле случая, завирусилось.
Никакого отношения к доказанной эффективности, доказуемости и уже тем более какие то стандартам разработки по факту это не имеет.
А если у вас более сложная архитектура?
Например стандартная библиотека какого-нибудь популярного языка программирования. Где в среднем нарушение SOLID во всех позах поставлено на поток. Интересно почему? Вроде бы не глупые люди должны таким заниматься.
Причем здесь конкретно solid? Это лишь один из принципов организации кода. На мой взгляд, вполне рабочий и корректный.
Проблема в другом - когда работает над кодом более одного человека, важно иметь общее понимание. Если каждый будет лепить код как ему вздумается, будет каша. Если используются паттерны и solid, есть хотя бы понимание, кто, что и как делает. Оптимально или нет, это уже вопрос, не имеющий правильного ответа
Чистый код не работает у тех, кто сам сделал из него религию. Сотворили себе божество и, как водится, принялись расшибать лоб. Расшибли. Далее божество низвергается и создается новое анти-божество.
Для людей со здоровой психикой "Чистый код" и подобные книги это просто набор советов, а не Священное Писание. Дельный совет - бери, плохой совет - не бери. И тех и других там хватает. А хотите какого-то высшего абсолюта - ну реально идите в церковь, в не в ИТ.
Двумя руками "ЗА". Плюсую.
это прям красиво получилось-написано! Фауст должен быть доволен, как и его автор!
Примите наше восхищение.
Правильно, это набор советов, которых можно придерживаться в какой-то степени, но если придерживаться на все 100%, то это уже становится фанатизмом, а он в любых своих проявлениях - опасный звоночек
Псст, не хотите поговорить о ФП? У нас там есть доказанные теоремы.
Об этом собственно и статья!
сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды.
а еще сначала мы учим простую механику в которой путь пропорционален скорости, а потом выясняется что с изменением скорости изменяется само течение времени и появляется некоторая неопределенность. Это тоже надо сразу с пятого класса детям объяснить чтобы они не путались потом? Или с четвертого, с третьего, ... ?
Наличие кучи абстракций, классов и методов не означает, что у тебя чистый код. С ними, внезапно - тоже надо уметь работать и логически организовывать. Работать в приложении с четкой компонентной архитектурой - это кайф. В отличие от копания в простынях говнокода где все уже перемешалось и практически нереально уже отследить связи (сейчас, как раз рефакторю свой легаси сервис и многое переписываю с нуля). Тесты должны помогать в работе, а не быть источником проблем. Их тоже надо уметь писать. Лично я пишу все виды тестов (функциональные, юнит, браузерные), но не потому что это нужно и правильно (такими категориями лучше вообще не думать), а потому что не люблю тестить руками. Мне нравится в клик мышки создать нужное окружение, открыть браузер в нужной точке и внести функциональность, а не сидеть и регистрировать аккаунты и тд просто, чтобы посмотреть, как там кнопочка отображается. Или поднимать сложное окружение, чтобы проверить отправляет ли класс нужное уведомление нужному пользователю.
Наличие кучи абстракций, классов и методов не означает, что у тебя чистый код. С ними, внезапно - тоже надо уметь работать и логически организовывать. Работать в приложении с четкой компонентной архитектурой - это кайф. В отличие от копания в простынях говнокода где все уже перемешалось и практически нереально уже отследить связи (сейчас, как раз рефакторю свой легаси сервис и многое переписываю с нуля).
Да в общем обе крайности плохи. Доводилось копаться в лапше с методами в несколько тысяч строк, и в суперабстрактной абстракщине, в котором даже что-бы просто понять какой кусок кода выполняется, надо было целое исследование проводить, иногда не на один день. Что то дерьмо, что другое.. В общем без здравого смысла никуда, хоть еги и не формализуешь никак.
про здравый смысл правильно, плюс зависит от environment, если ответственность, типа серьезный real time, главный признак качественного кода это хорошая читабильность + быстрая отладка, т.е. почти все заранее продумано, приходилось работать с опытными людьми у которых код надежно работает почти сразу, по опыту это один из главных критериев высокой квалификации
Вы не одиноки в этом мнении:
https://habr.com/ru/articles/743114/
а также https://qntm.org/clean
Просто надо руководствоваться здравым смыслом, а не принципами «чистого кода».
Идеальный, универсальный совет! Жаль только что здравый смысл у разных людей выглядит по разному и результаты его применения часто несовместимы.
ИМХО все эти попытки вывести формулу "чистого кода" похожи на попытку объяснить человеку, ни разу не видевшего воды больше чем в стакане, как надо плавать в море. Пока сам не утонешь нахлебаешься воды, хрен поймешь даже эти объяснения, не то что-бы научиться плавать.
Хуже, при внимательном рассмотрении здравый смысл оказывается просто когнитивными искажениями.
Здравый смысл - (под-)сознательный вывод из опыта (своего или чужого). Меня сильно триггернуло, что Мартин, зовущий себя архитектором, в 70 лет радостно открыл для себя SICP и сейчас пописывает на лиспе. Инженеру с таким кругозором нельзя писать книги по архитектуре.
В сущности все человеческое мышление - это лютая солянка из кучи когнитивных искажений :)
Если бы меня кто-то из джунов спросил, как научиться "чистому коду", я бы не стал советовать читать талмуды всяких там пророков IT, а вместо этого посоветовал бы читать как можно больше кода. Только с опытом чтения и написания кода начинает приходить какое-то понимание что такое хороший код, а что такое код плохой. Тогда только, может быть, стоит аккуратно и включив на максимум критическое мышление, почитать что-либо из опусов всевозможных философов от IT. Обратный порядок, как правило, джунов ломает, превращает их в фанатиков-говнокодеров, бездумно пихающих в код спорные концепции из популярных книг.
Очередная статья наброса говна на вентилятор и яркий пример избирательного восприятия.
Аргументы автора я услышал. Можно Вашу позицию увидеть?
Не планировал комментировать эту статью, поскольку, похоже, именно на такие эмоциональные отклики она и рассчитана. Однако не могу не высказаться: на мой взгляд, материал носит ярко выраженный кликбейтный характер. Автор стремится привлечь внимание и сформировать репутацию, избегая глубокой проработки темы.
Основная проблема — манипулятивный стиль подачи. Автор поверхностно затрагивает сложные, многоаспектные вопросы (чистый код, принципы проектирования, тестирование), которые в профессиональной среде обсуждаются годами, а затем:
выдвигает упрощённые или заведомо спорные тезисы
демонстрирует их «абсурдность» через гиперболизированные примеры
делает выводы, создавая иллюзию лёгкого решения сложных проблем
Разберу ключевые моменты.
Чистый код экономит время в долгосрочной перспективе. Этот перл особенно любят повторять на конференциях, потягивая бесплатный кофе и делая вид, что никогда не забивали в кодовую базу костыли пятничными вечерами. В теории звучит убедительно: потратьте час на рефакторинг сейчас, сэкономите неделю через полгода. На практике же выясняется, что через полгода весь этот прекрасно отрефакторенный модуль выброшен на помойку, потому что бизнес развернулся на сто восемьдесят градусов, а вы всё это время полировали архитектуру, которая никому не нужна. Чистый код экономит время примерно так же, как дорогой спортзал экономит ваше здоровье — в теории да, но абонемент всё равно пылится в дальнем ящике стола.
Автор противопоставляет теорию и практику, но не приводит ни статистики, ни конкретных кейсов. Утверждение, что бизнес «разворачивается на 180 градусов» и весь рефакторинг оказывается бесполезным, — это крайность. Такой подход равносилен отказу от проектирования: мол, зачем что-то делать, если всё может измениться? Или автор предпочитает лететь на самолёте, который делали из расчета, что на нем никто не полетит? Просто абсурдная логика.
Названия должны быть самодокументирующими. Ах, эти волшебные имена переменных. UserAccountManagerFactoryBuilderSingleton — теперь всем сразу понятно, что делает этот класс, правда? Не нужно никакой документации, когда у вас такие говорящие названия. Проблема в том, что код превращается в словесный понос, где каждая строчка расползается за границы экрана, а вы скроллите горизонтально, пытаясь понять, где же кончается это проклятое имя метода. И знаете что самое смешное? Через месяц выясняется, что UserAccountManager на самом деле только отправляет письма, а управлением занимается UserService, но переименовать уже страшно, потому что это сломает половину проекта.
Пример с UserAccountManagerFactoryBuilderSingleton — явная карикатура. Конечно, избыточно длинные имена — проблема, но альтернатива в виде A, B ещё хуже. Здравый подход — искать баланс: имена должны быть понятными, но не перегруженными. Критика автора выглядит как атака на крайность, которой в реальности почти никто не придерживается. Где аргумены что бы не давать нормальные навзвания?
Функции должны быть короткими. Дядюшка Боб говорит: функция не должна быть длиннее пяти строк. Прекрасный совет, если вы пишете калькулятор для начальной школы. В реальном мире следование этому правилу превращает вашу кодовую базу в матрёшку: функция вызывает функцию, которая вызывает функцию, которая вызывает функцию. Чтобы понять, что же на самом деле происходит при нажатии кнопки «отправить», — вам нужно нырнуть на семь уровней вглубь, открыть двадцать файлов и составить блок-схему на ватмане. Поздравляю, ваш код теперь чист как слеза, и столь же бесполезен для понимания логики.
Автор ссылается на «дядюшку Боба», но искажает контекст. Принцип коротких функций связан с SRP (Single Responsibility Principle): каждая функция решает одну задачу. Это не догмат, а стратегия упрощения кода. Альтернатива — монолитные блоки с комментариями, которые:
сложнее тестировать
труднее переиспользовать
нарушают принцип DRY
Критика в стиле «придётся открыть 20 файлов» — это проблема структуры проекта, а не самих функций. Уменьшение размера сущностей — это стратегия «разделяй и властвуй» для того, чтобы сделать код чище, проще, понятнее. Это рекомендация, а не правило. Альтернатива - большие и сложные функции с кучей комментариев (см. следующий пункт автора «Комментарии — признак плохого кода»), которые могли бы быть в именах функций)), и, очевидно, невозможность переиспользование кода, как маленьких кирпичиков, см. пункт автора про «DRY (Don’t Repeat Yourself) священен»)) Пропущу обсуждение 2- следующих его пунктов.
Тесты делают код чище
Автор поверхностно критикует тестирование, не разбирая его реальные плюсы (регрессионное тестирование, документирование поведения, безопасность рефакторинга). Он опять набрасывает на вентилятор все что слышал про тесты плохое, но он явно не в теме
SOLID-принципы решают все проблемы
Тут автор добавил просто не много желчи, его, по сути, хватило только на расшифровку аббревиатуры)) Типа «слишком» много умных слов, и так понятно, что ни чего хорошего))
Итог: cтатья не предлагает конструктива, а лишь создаёт шум. Автор не углубляется в контекст, не приводит доказательств, а вместо этого:
использует гиперболы
подменяет понятия
апеллирует к эмоциям, а не к логике
Такой подход вреден для профессионального сообщества: он дезориентирует новичков и дискредитирует важные инженерные практики. Хотелось бы видеть больше анализа, примеров из реальной практики и взвешенных аргументов — а не «набросы на вентилятор».
А что если автор участник одного из великого комитета? К нему сливаются тысячи рекламаций, из которых он и делает вывод, что: какого-то черта, мелкая фирма использует принципы чистого кода и например не документированных функций там где это не требуется.
Как я понял, ПОСТ (это не статья) именно об этом. А стиль и методы автора по донесению идеи мне безразличен. Я тоже иногда делаю громкие заявления, в попытке привлечь внимание к острой проблеме.
Вас услышал. Собираю свое личное мнение на ваших аргументах.
Прихожу к выводу, что отрасль развивается точно так де, как когда-то развивался автопром. По своему дико…
Автор , как ребенок пытается быть рупором адекватности в этом развитии, но все тщетно.
доброго дня
А что если автор участник одного из великого комитета? К нему сливаются тысячи рекламаций, из которых он и делает вывод, что: какого-то черта, мелкая фирма использует принципы чистого кода и например не документированных функций там где это не требуется.
Что, если бабушка на самом деле - дедушка?
Автор , как ребенок пытается быть рупором адекватности в этом развитии, но все тщетно.
Мне ближе идея, что автор прекрасно понимает что делает. Расчет на то, что здесь найдется несколько "полоскоземельщиков" и их хватит, что бы начался холивар. И таки он достиг своей цели))
chatgpt: "прочитай этот текст и помоги мне развалить оппонента, добавь аргументации, разложи по пунктам, добавь вводную, итог и неожиданную развязку"
Например
Принцип коротких функций связан с SRP (Single Responsibility Principle): каждая функция решает одну задачу. Это не догмат, а стратегия упрощения кода. Альтернатива — монолитные блоки с комментариями, которые:
сложнее тестировать
труднее переиспользовать
нарушают принцип DRY
SRP - важные слова, не говорящие ничего, типично для инфоцыган и политиков. Что такое сущность, что такое ответственность? У меня есть одна задача - вебмаркет, и есть одна god функция, которая обслуживает клиентов. Один к одному, SRP соблюдён? У меня есть функция, которая считает расстояние между точками, она считает квадраты и складывает их - один к двум, SRP нарушен? Правильный ответ: выбрасываем SRP нафиг и оперируем здравым смыслом - если что-то сложно поддерживать и непонятно лично мне и команде, нужно разбить на части.
DRY - то же самое, ничего не объясняет, громкие слова. Здравый смысл - если мы решаем узкую задачу и нам приходится синхронизировать изменения с несвязанным кодом, то наверное он связан и нужна абстракция.
Ну и так далее, по всему солиду и прочим аббревиатурам. Они же все буквально "делай хорошо (как я), а нехорошо не делай". И ещё "моя архитектура чистая, а остальные, соответственно, грязные".
Хочешь быть хорошим инженером - люби своё дело и больше читай/пиши/общайся за пределами своего пузыря, в других языках и парадигмах.
Да. Автор прав. Сам на проекте где все молятся на чистый код. При этом архитектурой приложения Лид считает SOLID. Типо само всё заработает. Глюк на клюке, одно правится, другое отваливается. Хорошо хоть есть смежные задачи в виде отдельных модулей. Фактически туда сбежал и применяю там здравый смысл. И вот удивительно, что при таком подходе сразу всё работает!
Применяйте здравый смысл и делайте архитектуру, прежде чем писать что-то большое. Спасибо автору поста. Он обнадежил, что не все свихнулась.
Мне кажется у Вас довольно превратное представление о чистом коде - примеры которые вы привели имеют мало общего с оригинальными идеями Мартина.
Вы читали его книгу?
Развитие здоровой идеи до ее логического, предела, когда она превращается в свою противоположность, это логический прием (reductio ad absurdum), который используется для критики, чтобы показать несостоятельность изначального положения, преувеличивая его до нелепости.
В каждой из приведенных книг и подходах, если не ошибаюсь, есть замечания, что не надо ударяться в крайности. Программист, который никогда не читал "чистый код" и подобное, или читавший, но не нашедший там для себя чего-то полезного, скорее всего будет не очень крут.
Статья понравилась!
Проблема в том, что книга пропагандирует крайности. И если "Чистая архитектура" воспринимается многими как излишнее усложнение и редко претворяется в жизнь, то совет "не писать комментарии" из "Чистого кода" большинством используется как оправдание лени и хаоса в проекте. А с Автором Популярной Книги бывает сложно спорить, потому как с одной стороны - наш местячковый тимлид, а с другой - их прекрасный Роберт Мартин.
Проблема в том, что книга пропагандирует крайности.
Нет. Проблема в том, что глава "комментарии" в книге "чистый код" занимает ~22 страницы размышлений о том, какие комментарии вредны, а какие необходимы. Но для некоторых это оказывается слишком сложным, отчего всё сводится к максимально догматичному: "комментарии писать нельзя". Потому что так проще. Ирония здесь в том, что автор статьи, затрагивая тему комментариев, разбивает аргументы из чистого кода с помощью... чистого кода.
А покрытие в девяносто процентов даёт вам ложное чувство безопасности, пока в продакшене не выясняется, что оставшиеся десять процентов — это как раз критичная логика оплаты.
Не 10%, а нетестируемые пути исполнения. Их гораздо больше, чем 10% — если у вас последовательно стоят 3 if-else, то путей выполнения 8 штук, а минимальное 100% покрытие тестирует 2.
А если вы вызываете какие-то библиотечные функции, то в полном графе выполнения при 100% покрытии ваших строк кода тестируется вообще ничтожная доля путей выполнения.
Он просто работает
Главная задача программиста - борьба со сложностью. И "Чистый код" - это единственное руководство, которые дает рецепты как бороться со сложностью. Или я что то не знаю?
Использовать "здравый смысл" для борьбы со сложностью проблематично, так как у каждого свой "здравый смысл".
Идеи "Чистого года" просты и известны уже очень давно (писатели в 17 веки или уже пользовались).
Главная идея - от общего к частному. Высокоуровневая функция вызывает среднеуровневую, среднеуровневая - низкоуровневую. Сложность множества строчек перемещается в длинное название функции. "Чистый код" негласно постулирует, что длинное название функции понять проще, чем вчитываться в содержание функции. Как минимум может выясниться, что вникать в эту функцию не нужно.
"Чистый код" можно назвать принципами оформления. То есть, хорошо написанный и декомпозированный код легко разделяется на множество функций. Если же сделать это вызывают затруднения, то проблеме не в "Чистом коде".
Главная задача программиста - борьба со сложностью.
Надеюсь в резюме у себя Вы такое не указываете
Длинное название функции - это точно такая же не читаемая лапша, как и сокращения типа $b $q
Может, изначально идея чистого кода и была в борьбе со сложностью путем унификации кодовой базы и подходов к дизайну систем, но текущий подход к унификации путём применения методов из ЧА оставляет желать лучшего:
ЧА абсолютно никак не учитывает разную сложность модулей(фич).
ЧА не учитывает эволюционность модулей.
ЧА не учитывает разный характер нагрузки модулей.
В итоге пишется куча бойлерплейта там, где оно не нужно. А потом приходится бороться и удалять бойлерплейт оттуда, где есть большие требования по нагрузке. И всё это порождает зачастую ещё больше сложности.
И "Чистый код" - это единственное руководство, которые дает рецепты как бороться со сложностью. Или я что то не знаю?
"Совершенный код" за авторством Стива Макконнелла - гораздо более адекватное руководство по этой теме.
Главная задача программиста - борьба со сложностью.
Проблема в том что сложность(сложность разработки + сложность поддержки + сложность доработки) константна, и эта сложность просто перетекает из одного места в другое. От сложности нельзя избавиться и она может только перерасти в технический долг, и как правило по причинам бизнеса, например надо поддерживать старое api из за партнеров или другого важного внешнего сервиса.
И все искусство разработки как раз и сводиться к тому чтобы в каждом конкретном случае выбирать оптимальное решение технической задачи для решения какой-то бизнес задачи.
А вот мне стало интересно, автор, ты когда-нибудь работал на одном и том же проекте длительное время? Не так чтобы полгода задачи с борда закрывать, а вот прям дизайнить архитектуру, писать код, релизить, саппорить, исправлять свои же косяки, etc. А то, поработав на разных проектах с разными людьми, в том числе с фрилансерами, а также на разного рода галерах, где на одном проекте люди постоянно меняются, у меня начинает складываться впечатление, что именно такие люди максимально наплевательски относятся к качеству кода, и пишут лишь бы работало, совершенно не заботясь о читаемости, поддерживаемости, расширяемости и т.д.
Теперь давай по пунктам пройдемся:
1) "Чистый код экономит время в долгосрочной перспективе" - да, это так. Потому что сложность имеет тенденцию со временем увеличиваться. И если что-то сейчас сделать тяп-ляп, лишь бы работало, а потом это не исправить, а оставить как есть, то через время это тяп-ляп имеет возможность превратиться в такой снежный ком неподдерживаемого переплетенного хтонического ужаса, что трогать будет уже просто страшно (особенно если нет тестов, но о них мы позже поговорим). Разумеется, каждому из нас приходилось писать костыли, потому что фикс нужен срочно, но на мой взгляд достаточно очевидно, что такой костыль следует исправить ASAP как будет возможность, а не копить тех долг где-то в бэклоге
2) "Названия должны быть самодокументирующими" - да, это так. Твой пример с UserAccountManagerFactoryBuilderSingleton тут не подходит, так как это пример плохого и не говорящего названия, слепленного из дженерик терминов. В идеале названия должны быть лаконичными и говорящими. Не всегда получается, разумеется, достичь идеала, но это не повод ведь теперь все бросить и начать называть переменные и методы абы как, верно? А если переимнование чего-либо ведет к тому, что это ломает не то что половину проекта, а хоть что-то, то... я даже хз, что надо было делать предварительно в этом проекте, чтобы ренейминг что-либо ломал. Расскажи, что ли, мне действительно интересно
3) "Функции должны быть короткими" - ну, тут соглашусь. Гнаться за коротковизной как самоцелью - так себе идея, в жизни всякое бывает, в том числе сложная логика. Тем не менее, лучше короткие функции с явно выраженной целью, понятным образом трансформирующие какие-то входные аргументы на какой-то результат, которые можно протестировать, чем полотна кода на несколько экранов
4) "Комментарии — признак плохого кода" - комментарии бывают разные. Пояснять какие-то решения - это нормально. Например, Javadoc - это тоже комментарии, и предполагается, что это высокоуровневые комментарии, которые поясняют, для чего нужен класс или метод в целом. Если же код нуждается в комментариях, чтобы понять каждую отдельную строку этого кода - то таки да, это плохой код и плохие комментарии
5) "Don’t Repeat Yourself" - да, это так. Не знаю уж как ты, автор, а я заколебался на разных проектах ковырять одну и ту же логику в разных местах, потому что программист, который ее писал, просто шлепал код как есть, не думая вообще про вынесение в общие методы. А потом еще обнаруживается, что этот человек даже с копипастой справиться нормально не сумел, поэтому в разных местах есть расхождения (и не потому, что они реально должны быть), и саппорт, дебаг и исправление ошибок превращается в натуральную пытку
6) "Тесты делают код чище" - ДА, ДА, ДА. Опять же, я готов понять, если человек пришел на проект на пару месяцев, и ему вообще пофигу как на качество кода, так и на будущий саппорт проекта. Но я вообще не понимаю, как можно настолько себя не любить, что если ты сам работаешь на проекте, и ты же развиваешь этот код, и ты же его саппортишь, чтобы не писать тесты. Тесты как минимум позволяют безопасно делать рефакторинг в будущем, как максимум - защищают от багов в проде, с которыми к тебе же и придут, чтобы ты разбирался и чинил. Работал я как-то с одним придурковатым тимлидом, который код проверял мануально, а потом запрещал трогать что-либо, потому что никаких гарантий, что изменения ничего не сломают, у него не было. Разумеется, тесты не панацея и не защитят на 100%, но это не повод от них отказываться
7) "SOLID принципы решают все проблемы" - никогда ранее не слышал подобных утверждений. SOLID - это набор рекомендаций, как писать правильный ООП-код. Рекомендаций, а не строгих правил, и разумеется их можно нарушать, но для начала неплохо бы все-таки понимать эти принципы, чтобы как раз понимать, что и когда уместно нарушать, а что лучше нет
Вообще, ни одно правило "чистого кода" не стоит воспринимать абслютно. Как вообще ни одно правильно не следует воспринимать. Все они придуманы для решения или недопускания определенных проблем. Квалификация программиста заключается в том числе в том, чтобы понимать, с какими проблемами он имеет дело в данный момент, и согласно ситуации выбирать и абстракции, и конкретные решения
UserAccountManagerFactoryBuilderSingleton
Вопрос: хорошее название для неё
Ответ: God
То есть проблема уже не в названии, а в нарушении SRP
100%. Когда работаешь долгое время над одним проектом сразу все преимущества чистого кода с тестами понимаешь. Я вот сейчас свой старый легаси проект с матами переписываю - ничего не понятно. Все перемешалось в кучу. У ИИ спрашиваю как там что устроено, но и он не всегда понимает. В итоге уже который функционал выкидываю и пишу с нуля..
Рождественская история, lol))
Ох уж эти разрушители легенд...
Чистый код не работает!
SOLID не решает!
ООП - антипаттерн!
Алгоритмы не нужны!
Пойду искать старые традиционные статьи, а то голова кругом идёт от этих прогрессивных статей.
Всё должно базироваться на ограничениях человека. Что одновременно в памяти можно держать не более 10-15 сущностей и стек следования по коду с зажатым Ctrl глубиной не более 20. Это, грубо, контекстное окно человека как у ИИ. Код нужен лишь для унификации восприятия и каждый понимает его по-своему. Поэтому чистый код - лишён кода как бы ни парадоксально это не звучало а содержит лишь то, что образно говоря, попадает в doxygen и техническое задание или документацию. Выбор имён и соглашений можно уже доверить ИИ и подобного рода инструментам, включая локальное тестирование.
Ну и что? Сложно найти человека на опыте, который всерьез бы стал спорить с посылом. Только для этого ему уже много надобно понимать, и такие вот статьи он будет читать максимум по диагонали. Для новичка, ну я себя им представил на минуту, и еще раз перечитал; да тут чуть ли не каждый тезис - предмет вопросов, сомнений и какой-то дискуссии. Какой-то. Ну а если "так и задумано", то чести это не делает.
Отличная статья. Помойка -- лучшее место для книг дяди Боба. Он вообразил себя Конфуцием и половина его текстов -- это моральные наставления. Ещё немного про "как я поборол ADHD". Остальное -- чистый мусор. К словам автора добавлю, что никто в жизни код как книгу не читает. Во-первых, зачем его читать от корки до корки? Его много, жизни не хватит. Во-вторых, в 99% вам нужно смотреть в определённое место, чтобы быстро понять что не работает, а не лазить по десяти уорвням абстракции и читать весь код начиная с самого базового класса.
А зачем вам абстракции, классы, методы и вот это все? Просто смотрите 99% времени в определенное место.
Как вы собираетесь без правильный абстракций смотреть только в одном место? Нет, если у вас не выстроены абстракции и границы между модулями, вам придется прочитать все и держать все в голове, чтобы быть в состоянии вносить изменения, ведь связано может быть что угодно с чем угодно
Если следовать советам дяди Боба, то и придётся читать всё. Это его основной концептус: код нужно читать как книгу. Я не говорил, что абстракции не нужны, особенно правильные. Но если код писать по дядибобному, то абстракции будут только мешать нормальной работе. Невозможно в современной индустрии код читать сверху вниз, его просто тупо очень много. В обычной ситуации вам приходится делать наоборот: посмотреть в одну функцию и быстро понять что происходит. Чем меньше вы при этом будете смотреть вширь, тем быстрее найдёте баг или что-то допишите.
Аргументы автора имеют настолько же узкую область применимости, как и оригинальные идеи чистого кода. Если понимаешь что код может долго не прожить, очевидно не надо упарываться в поддерживаемость, но не редко пишешь точно зная, что лет 10-20 оно проработает.
Идея про дублирование кода была неправильно понята автором: если код выглядит похожим — это вовсе не значит, что его изменение происходит по одинаковым причинам и будет иметь одинаковое влияние. Абстрагировать нужно только то что по смыслу является одной и той же логикой.
Ну и остальные тезисы похожим образом не вполне корректны
Почти для всех приведенных пунктов есть одна важная забытая деталь - границы применимости.
Они вечно теряются.
А меж тем практически каждый пункт перестает работать при чрезмерном использовании либо наоборот - стоит слишком дорого в случаях, где использование недостаточно.
Комплексные архитектуры избыточны для простого приложения от одного разработчика, а в сложном проекте нельзя сделать просто. Декомпозиция важна, чрезмерная декомпозиция делает код нечитаемым. Комментарии действительно могут устаревать и путать быстрее кода и частично замещаются хорошим неймингом, но API и сложные места/оптимизации требуют комментариев. И так далее.
Поэтому и важны нюансы, и ответы не только на вопрос "как", но и "почему".
===UserAccountManagerFactoryBuilderSingleton===
Это как раз неговорящее название, не самодокументируемое.
Есть же хорошая практика, говорящая, что имена должны быть действительно говорящими, но небольшое количество комментариев при этом всё-таки нужно. Они должны:
1. Объяснять сложные места.
2. Объяснять причины важных изменений. Чтобы потом не захотелось "улучшить" обратно к предыдущему варианту( не зная о нём, и почему от него отказались).
Итак, чистый код не нужен. А какой нужен? Автор говорит: нужен код "рабочий" и "понятный". А как понять, что мы пишем именно такой код? А никак, говорит автор, это "плохо формализуемо". Другими словами, если я его верно понял, в основе написания кода должны лежать не правила, а "наитие" и "опыт". Вот тогда код будет "правильным". Просто "пиши код сейчас так, чтобы потом не было мучительно больно". Просто на основе опыта и интуиции пиши. Правил, рецептов и советов тут нет или, вернее, их нельзя "формализовать", "озвучить", "описать в книге". Они есть предмет частных усмотрений, ощущений, догадок. Ведь иначе они имели бы "форму", а хороший код бесформен, его написанию нельзя научить словами человеческого языка. Просто заглядывай мне через плечо и смотри, как я пишу, просто учись.
Кто Вас забанил? Вы легенда.
Мне все равно, что пишут в комментариях, но я со всем согласен.
Автор статьи ПРАВ на 100%. Вкатуны в айти, в попытке найти волшебную палочку, нашли маркетинговые сказки какого то таланливого болтуна из Америки, который никогда сам не программировал, и стали на сказки МОЛИТЬСЯ :)) В итоге получается код который в несколько раз сложнее чем нужно, но адепты этого не знают, так как профильного образования у них или нет, или после ВУЗа они сразу попали под руководства адепта секты. Жрут кактусы, плачут, смотрят на сотни не нужных классов и интерфейсов, обвешивают все юнит тестами, которые проверяют 2 + 2, разбивают методы на бессмысленные куски по 3-5 строчек, и упорно не пишут комментариев -- но думают что пишут что ни на есть прекрасный и правильный Чистый Код, а остальные просто еще не постигли дзен :))
Начинаешь ценить чистый код, когда много работаешь с грязным. С функциями на 500 строк, с глобальными переменными по всей программе, с названиями вида uam (UserAccountManager, разве не понятно?) ...
Конечно, любую идею можно довести до маразма, и серебрянной пули нет. Но уж лучше чистый код, чем спагетти.
Как работает чистый код