Кажется, все сейчас стремятся к «чистому» коду. Нет почти ни одной статьи в блогах, где автор не скажет о том, насколько «чист» его подход. Команды собираются обсудить, какое из возможных решений самое чистое. Разработчики вокруг заверяют, что практикуют «чистый код».
Тем не менее, я осознал: нет такого понятия — чистый код.
Чистотой невозможно измерить что-то полезное. Код просто не может быть «чистым», ведь «чистота» просто не говорит ничего об этом коде.
Какой лицемер!
Меня тоже можно обвинить в том, что раньше я неоднократно использовал термин «чистый». Хочу также заметить, что не ставлю целью принизить тех, кто использует это понятие.
Как маркетинговый термин или описание видения, «чистый» подходит прекрасно, но как у технического определения тут есть ряд проблем…
Чистый код — хороший код, верно?
Когда кто-то говорит про чистый код, то обычно они имеют ввиду, что он хороший.
Дело в том, что хорошим код может быть по нескольким причинам:
Читабельный
Понятный
Простой
Быстрый
Безопасный
Элегантный
Легко тестируемый
Инкапсулированный
Масштабируемый
Легко поддерживаемый
Переиспользуемый
Легко удаляемый
Чистый и аккуратный
Независимый
Систематичный
Консистентный
и любой другой набор признаков
Все эти признаки в некотором роде противоречат друг другу. Самый простой код, скорее всего, сложно тестировать. Множество интерфейсов и вложенных зависимостей упрощают тестирование, но делают код сложнее.
Сильная зависимость от синглтонов позволит упростить понимание, но такое приложение сложнее обслуживать.
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание, но также могут усложнить поддержку приложения.
На самом деле, можно сказать, что некоторые из этих признаков прямо противоречат другим и они не могут быть удовлетворены одновременно. Разработка — это компромиссы, и, чтобы обсуждать их в команде, все должны иметь представление о них.
Если код хороший, то мы должны объяснить почему
Когда кто-то говорит о «чистом» решении, то обычно представляет его как наилучшее, не объясняя почему.
Для конструктивного диалога о технических решениях мы должны быть в состоянии объяснить, почему одно решение лучше другого. Неправильно спорить о том, какой подход «чище», будто есть некий чистомер для измерения этой загадочной меры.
На самом деле, довольно сложно объяснить, почему вот это решение лучше или хуже другого, но такой навык необходимо оттачивать.
Вы бы предпочли диалог в таком формате?
Мне нравится решение X, потому что оно кажется «чище»
Или в таком?
Мне нравится решение X. В этом случае разделяется основная логика и обработка ошибок. Его проще понять, потому что не приходится разбираться одновременно с и с тем и с другим. Разделение также упрощает тестирование, позволяя замокать один объект на время тестирования другого. Конечно, для этого родительскому объекту придётся вводить зависимости, но это допустимый компромисс ради упрощения тестирования.
Второй аргумент указывает на плюсы и минусы обсуждаемого подхода, а вот такой термин как «чистота» лишь отговорка, чтобы не практиковаться в умении формулировать свои идеи.
Мы должны использовать точные термины
Программирование, как правило, командная игра. Если вы работаете в одиночку, то можете делать всё, что хотите, но работая в команде нужно обсуждать свои идеи. Иметь возможность дискутировать о технических решениях, говоря на точном языке, когда у команды единое понимание терминов — бесценно для взаимопонимания.
«Чистый код» имеет разное значение для каждого.
Для одних разработчиков код чистый, потому что в нём прослеживается чёткая архитектура. Для других — просто потому, что он оформлен по оговорённым стандартам.
Такие понятия, как «инкапсулированый», «тестируемый», «переиспользуемый» или «мокабельный» имеют единое значение для всех нас. Когда мы используем точные термины для описания кода, то можем быть уверены, что все остальные правильно нас понимают.
Понятие «чистый» настолько же точное, насколько «хороший». Вы можете говорить, что код чистый или хороший, но всё это не отменяет необходимости объяснить свою позицию конкретнее.
Так что такое чистый код?
Я пришёл к выводу, что чаще всего, когда мы говорим «чистый» код, то считаем его хорошим, но не можем объяснить почему. Нам просто кажется, что это правильное решение.
Или иногда мы знаем, что этот код хороший, но не в состоянии сформулировать почему, а потом в конце статьи своего блога пишем: «Просто посмотрите, насколько стало чище!»
Конечно, здорово развивать хорошую интуицию, но этого недостаточно. Необходимо копнуть глубже, понять и сформулировать, почему мы считаем этот код хорошим. Какие качества выделяют его среди других решений? Насколько эти качества важны в нашем проекте? Может оказаться и так, что это не самое лучшее решение.
Надеюсь, я смог убедить вас в том, что вам нужен не чистый код, вам нужен ________ код. Просто подставьте те определения, что лучше подходят вашему проекту.
Комментарии (28)
r_wilco
14.02.2022 20:19+9Насколько я понимаю, термин "чистый код" появился от одноименной книги Роберта Мартина. Там сформулированы некоторые хорошие практики, которые автор рекомендует использовать и обосновывает, почему так лучше. Твой список не совпадает с тем, что предлагает автор. Еще есть "Совершенный код" Стива Макконела, там правила немного свои. Но к архитектуре это отношения не имеет. Думаю, ты слишком вольно трактуешь термин, отсюда и завышенные размытые требования к нему.
MaryRabinovich
14.02.2022 22:09-7Это переводная статья.
Полюбопытствовала, кто автор. Некий Стив Барнерген, я погуглила про него. Ну вроде синьор какой-то где-то.
Имхо, тут вопрос не столько в теме и содержании текста, сколько в том, а почему мнение некоего Стива Барнергена интересно.
S-e-n
14.02.2022 22:24+17почему мнение некоего Стива Барнергена интересно.
Потому что в более-менее развитых культурах принято смотреть на содержание и смысл текста, а не на регалии автора.
funca
14.02.2022 23:46+1Мне кажется это работает немного не так. Смотрим рейтинг статей на https://news.ycombinator.com/, выбираем что-то из свежего топа и публикуем перевод на Хабре. Поскольку там статья набрала достаточно лайков, значит и тут успех практически гарантирован. Контент и регалии дело второстепенное.
S-e-n
15.02.2022 01:06Контент и регалии дело второстепенное.
А лайки на YC из воздуха берутся? Или может быть они всё-таки функция контента, и здесь, и там?MaryRabinovich
15.02.2022 06:42+1Лайки есть функция контента И аудитории.
Лайки в количестве Х показывают только то, что есть некие Х людей, поставивших статье лайк.
Также возможно, что есть Х+У людей, поставивших статье лайки и У дизлайкнувших.
Вот как по мне, я лайки бы отменила. Если чел хочет нечто отметить насчёт статьи, пусть говорит словами. Ибо, как здесь же в статье написано, нету статей хороших или плохих, а есть неумение формулировать мысли в деталях.
Опять же, тема не новая и не специально техническая. Вот, например, блестящая совершенно (древняя уже) статья "Восстание ткани" Андрея Архангельского - она о том же. Коротко говоря, вышел фильм, и сеть разделилась на 50% пишущих "это говно полное" и 50% пишущих "фильм блестящий".
... Хотя да, лучше уж мелкие лайки, чем миллион односложных каментов. Лайки жрут меньше места. Разве что выдача лайками управляется, это вот плохо.
rombell
14.02.2022 23:48+2Хорошая заметка на эту тему есть у Юдковского в цикле про байесианский взгляд на мир. Вкратце:
Если есть возможность проверить данные непосредственно и получить прямые доказательства, например, поставить эксперимент, то регалии автора не имеют значения вообще. Чем меньше возможность такой проверки, тем большее значение имеют регалии (то есть опыт и признанность этого опыта сообществом) автора как косвенные доказательства.
Если я читаю статью по специальности, в которой у меня собственный большой опыт, мне на регалии плевать. Если я читаю статью в области, где я любитель с некоторыми познаниями, я могу смешивать оценку, базирующуюся на своих знаниях, с оценкой, базирующейся на авторитете источника. Если я читаю статью в совершенно посторонней области, кроме авторитета опереться не на что. Здравый смысл, как известно, работает только в хорошо знакомых областях.MaryRabinovich
15.02.2022 06:26+1Если я читаю статью по специальности, в которой у меня собственный большой опыт, мне на регалии плевать.
Почти. Дело, однако, в том, что вы по специальности, в которой у вас богатый собственный опыт, всё что попало не тянете в рот. Есть некий изначальный отбор статей, которые далее вы уже можете оценить чисто по содержанию.
В данном случае статья
имеет кликбейтный заголовок
в ней спутаны разные вещи, и эта путаница не очевидна людям, в чьей библиотеке дома нету бумажных "Чистого кода" и "Чистой архитектуры", к примеру.
Попробую пояснить, с цитатами из статьи.
Кажется, все сейчас стремятся к «чистому» коду. Нет почти ни одной статьи в блогах, где автор не скажет о том, насколько «чист» его подход. Команды собираются обсудить, какое из возможных решений самое чистое. Разработчики вокруг заверяют, что практикуют «чистый код».
Кто "все (сейчас стремятся)"? "Нет почти ни одной статьи в блогах..." - таких статей дофига. Где автор ни слова не говорит насчёт "чистоты" подхода. На хабре таких как минимум 90%.
"Разработчики вокруг заверяют, что практикуют..." - завидую. Легаси с файлами на 3000 строчек я буду долго ещё вспоминать, при том, что задним числом хорошо вижу их разложение на детали, в которых бы было супер-легко ориентироваться. Короче, это вот либо кликбейт, либо зажрался мужик. Либо он пишет абы чего, чтобы лайкнули, либо вокруг него реально все Практикуют. И дальше уже детали - кто именно что именно делает в рамках подобной практики.
Тем не менее, я осознал: нет такого понятия — чистый код.
Если мне предлагают чьи-либо Озарения, мне бы хотелось знать, на кого снисходит. Кто это, кто в нирвану попал так прижизненно.
... давайте проскочим сразу несколько строчек:
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание, но также могут усложнить поддержку приложения.
Вот тут вопрос. А стоит ли класть синглтоны в суп? Который в кастрюльке, да. Ну просто у каждой вещи есть разные применения. А где-то она вообще не в тему (как суп в синглтоне... ой то есть наборот, синглтоны в супе).
Но. Это же не про "чистый код", это про "архитектуру". И тут я вдруг осознаю (вот да, я же тоже порой озаряюсь), что чел не особенно различает эти две книжки Мартина. Возможно, в обеих вместе прочёл 0 строчек.
Ну и вот эта вот часть, с названием
Если код хороший, то мы должны объяснить почему
Ну? Кто бы спорил, я не понимаю. Вот так написать банальности (дальше ж банальности) и вызвать рукоплескания, это ж надо уметь.
MaryRabinovich
15.02.2022 06:33+1Грубо говоря, если ты в некоей области споришь с классикой, надо же в ней разбираться. Должно же быть видно по тексту, что ты её изучил и с ней не согласен. Тогда уже будет вопрос, в чём именно. Желательно с качественными цитатами ("Такой-то автор пишет там-то, что ХХХ - это вона чо, а я не согласен, поскольку УУУ"). Желательно - ссылки в сеть, или страницы в книгах.
Или ты споришь с узусом? Ну так тогда напиши. Напиши этим милым людям, что по твоим наблюдениям они (твои читатели) запутались и запонтовались. При том, что никто (и с тобой включительно) книжек по теме даже не открывали.
И я не уверена, что при таком раскладе лайков будет вот так же вот дофига.
Ну потому что тут одно дело - лайкать статью, где как бы подтекст "а глупые же эти люди, авторы подобных терминов, ибо слова ни о чём". И совсем другое - лайкать статью, где написано "люди, ребяты!! Я выяснил, это описано где-то! А мы тут (далее нецензурно)". И сколько бы лайков было?
rombell
15.02.2022 23:05Я вовсе не спорил с тем, что статья низкокачественная, и полностью согласен с
Грубо говоря, если ты в некоей области споришь с классикой, надо же в ней разбираться. Должно же быть видно по тексту, что ты её изучил и с ней не согласен.
Мой комментарий относился исключительно кв более-менее развитых культурах принято смотреть на содержание и смысл текста, а не на регалии автора.
violent_monkey
15.02.2022 10:32+2Поставил бы вам плюс, если бы мог, а вот автору перевода минус.
Автор же оригинальной статьи очевидно не читал эту прекрасную книгу, в которой Роберт Мартин кристально чисто определяет что такое чистый код, и очень сильно это аргументирует. Но тем не менее автор статьи:
...осознал: нет такого понятия — чистый код
Ещё и делает абсолютно не содержательный и бестолковый вывод:
Я пришёл к выводу, что чаще всего, когда мы говорим «чистый» код, то считаем его хорошим, но не можем объяснить почему. Нам просто кажется, что это правильное решение...
Не хотелось бы принадлежать к числу этих "нас"...
И сразу напрашивается вопрос: а велик ли смысл в переводе подобной статьи и какова цель? Ну а если посмотреть профили и работы автора оригинальной статьи, то не находится ничего выдающегося.
И каждый в праве высказать свое мнение и аргументировать (
как и я в своем комментарии), но в данном случае содержание статьи уж слишком слабое и субъективное.
lair
14.02.2022 21:49+6Такие понятия, как «инкапсулированый», «тестируемый», «переиспользуемый» или «мокабельный» имеют единое значение для всех нас.
Правда? Автор статьи, конечно же, легко приведет единое объективное определение "тестируемого" кода, да?
Или же автор просто предлагает заменить одну субъективную оценку другой?
kira-dev
15.02.2022 00:05Your heavy reliance on singletons may make things easy to understand, but it might not lead to a maintainable application.
Тут лучше бы перевести перефразировать как
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание происходящегоно, но точно также могут привести приложение в неподдерживаемый вид.
что сути не меняет. Оказывается, в своей работе надо понимать что ты делаешь, зачем, к каким последствиям это приведет, и прочие мозговые активности.
sepulkary
15.02.2022 07:42+2Насколько я помню, у Роберта Мартина есть весьма чёткая метрика, по которой можно отличить плохую архитектуру от хорошей — стоимость разработки и поддержки. Так что найти общий знаменатель в том длинном списке, который приводит автор, чтобы придать своим размышлениям некоторый психологический накал, от "читабельности" до "консистентности", не так уж трудно.
aelaa
15.02.2022 12:47+1Основной критерий "чистого кода" у Роберта Мартина, который он неоднократно упоминал в лекциях - WTF/min = 0. Понятно, что эта метрика зависит от команды, но в рамках конкретного проекта можно построить код так, чтобы даже у новичков вопросов не возникало
Artilirium
17.02.2022 09:16Не уверен, что автор оригинала так задумывал, но в переводе получилось жонглирование определениями
Когда кто-то говорит про чистый код, то обычно они имеют ввиду, что он хороший.
"Чистый" -> "Хороший"
Дело в том, что хорошим код может быть по нескольким причинам:
...
- Чистый и аккуратный"Хороший" -> "Чистый"
Мне кажется тут лучше подошел бы термин "Лаконичный"
NikRag
У слова "чистый" имеется определенное значение - "не содержащий лишнего, нежелательного.". Поэтому "чистый код" - "лишенный грязи".
На этом моменте можно закончить спор о терминах, и вспомнить, что в уважающих себя организациях (от 1 человека) считается вежливым иметь внутреннее определение правил кодинга. Табы-пробелы там, итд.
Код, соответствующий принятым правилам - и есть чистый. Даже если багованый, или если у других принято иначе.
Я так считаю, и проблем с понятием "чистый код" у меня таким образом нет.
Racheengel
Ну, это уже чисто формальный подход. А если таких правил нет? Или наоборот, есть несколько команд, у каждой из которых свой набор гайдлайнов?
Имхо "чистый код" понятие более утилитарное. Это код, не содержащий костылей, лапши и оверинжиниринга. В идеале - код, который невозможно сделать ещё короче без ущерба для понимания и производительности.
dedmagic
Тогда любой код с точки зрения этой конкретно команды является качественным (чистым). Поэтому любая нормальная команда начинает вырабатывать свои подходы к обеспечению качества кода.
Понятие "качество кода" определяется строго на уровне команды, не ниже, не выше.
NikRag
Несколько команд в пределах одной организации, каждая из которых имеет свои уникальные гайдлайны, но которые при этом обмениваются кодом, а не модулями с утвержденным АПИ? Это описание очень дезорганизованной коллективной деятельности, как по мне, проблемы там явно не на уровне чистоты кода.
Racheengel
Вполне обычная ситуация в рамках, скажем, большого концерна, где одна команда сидит в Индии, другая в Америке, третья в Европе, например. И они могут обмениваться между собой и готовыми модулями, и кодом в том числе.
Так что наличие собственных гайдлайнов совершенно ничего не говорит о проблемах в организации. Это говорит лишь о том, что следование гайдлайну и понятие чистоты кода - вещи ортогональные в большинстве случаев.
LaRN
Размер кода не всегда показывает чистоту. Есть ещё требование что
бы код можно было легко расширять и поддерживать. И обычно это все через «пресловутые» паттерны реализуется, которые не добавляют краткости коду.
kira-dev
Те отформатированный код в файле на 7к строк является чистым?)
TheShock
Но в гайдлайне могут быть ограничения на длину файла/класса/метода.
panzerfaust
Да, если таков консенсус команды. Дальше уже ваше дело - хотите ли вы жить с такой командой. Можете либо публично поставить сей факт под сомнение и изменить гайд, либо уйти из команды. Но будьте добры выполнять гайд, а не оспаривать его на каждом ревью.
NikRag
Я понимаю сарказм, но "все программисты мира" тоже некоторым образом - организация, с общим пониманием некоторых ключевых вещей.
Типа, не писать всю программу в одну строчку, давать осмысленные имена, итд. Да, бывают изящно выглядящие микропрограммы в одну строчку с переменными i,j,k, но я про другие кейсы.
Думаю, обобщить чистый код можно как: "удобочитаемый другими". Определение удобства вцелом уже вопрос психологии, и немного отходит от самого кода.
panzerfaust
Поддержу. Вот в грузоперезвоках особо не возникает споров габарит - не габарит. Потому что каждая грузовая компания четко определяет кто есть кто. А кто такие правила не придумал - будет постоянно огребать проблем от идиотов, желающих перевезти карьерный самосвал силами курьера на велосипеде. Никто не пишет статьи "Вот мы говорим "габарит", но не можем дать ему определение"
Аналогично, если команда не в состоянии написать гайд, то каждый залетный джун будет набрасывать на вентилятор все новые тезисы о чистом коде.