Comments 29
У слова "чистый" имеется определенное значение - "не содержащий лишнего, нежелательного.". Поэтому "чистый код" - "лишенный грязи".
На этом моменте можно закончить спор о терминах, и вспомнить, что в уважающих себя организациях (от 1 человека) считается вежливым иметь внутреннее определение правил кодинга. Табы-пробелы там, итд.
Код, соответствующий принятым правилам - и есть чистый. Даже если багованый, или если у других принято иначе.
Я так считаю, и проблем с понятием "чистый код" у меня таким образом нет.
Ну, это уже чисто формальный подход. А если таких правил нет? Или наоборот, есть несколько команд, у каждой из которых свой набор гайдлайнов?
Имхо "чистый код" понятие более утилитарное. Это код, не содержащий костылей, лапши и оверинжиниринга. В идеале - код, который невозможно сделать ещё короче без ущерба для понимания и производительности.
А если таких правил нет?
Тогда любой код с точки зрения этой конкретно команды является качественным (чистым). Поэтому любая нормальная команда начинает вырабатывать свои подходы к обеспечению качества кода.
Или наоборот, есть несколько команд, у каждой из которых свой набор гайдлайнов?
Понятие "качество кода" определяется строго на уровне команды, не ниже, не выше.
Несколько команд в пределах одной организации, каждая из которых имеет свои уникальные гайдлайны, но которые при этом обмениваются кодом, а не модулями с утвержденным АПИ? Это описание очень дезорганизованной коллективной деятельности, как по мне, проблемы там явно не на уровне чистоты кода.
Вполне обычная ситуация в рамках, скажем, большого концерна, где одна команда сидит в Индии, другая в Америке, третья в Европе, например. И они могут обмениваться между собой и готовыми модулями, и кодом в том числе.
Так что наличие собственных гайдлайнов совершенно ничего не говорит о проблемах в организации. Это говорит лишь о том, что следование гайдлайну и понятие чистоты кода - вещи ортогональные в большинстве случаев.
Размер кода не всегда показывает чистоту. Есть ещё требование что
бы код можно было легко расширять и поддерживать. И обычно это все через «пресловутые» паттерны реализуется, которые не добавляют краткости коду.
Те отформатированный код в файле на 7к строк является чистым?)
Но в гайдлайне могут быть ограничения на длину файла/класса/метода.
Да, если таков консенсус команды. Дальше уже ваше дело - хотите ли вы жить с такой командой. Можете либо публично поставить сей факт под сомнение и изменить гайд, либо уйти из команды. Но будьте добры выполнять гайд, а не оспаривать его на каждом ревью.
Я понимаю сарказм, но "все программисты мира" тоже некоторым образом - организация, с общим пониманием некоторых ключевых вещей.
Типа, не писать всю программу в одну строчку, давать осмысленные имена, итд. Да, бывают изящно выглядящие микропрограммы в одну строчку с переменными i,j,k, но я про другие кейсы.
Думаю, обобщить чистый код можно как: "удобочитаемый другими". Определение удобства вцелом уже вопрос психологии, и немного отходит от самого кода.
Поддержу. Вот в грузоперезвоках особо не возникает споров габарит - не габарит. Потому что каждая грузовая компания четко определяет кто есть кто. А кто такие правила не придумал - будет постоянно огребать проблем от идиотов, желающих перевезти карьерный самосвал силами курьера на велосипеде. Никто не пишет статьи "Вот мы говорим "габарит", но не можем дать ему определение"
Аналогично, если команда не в состоянии написать гайд, то каждый залетный джун будет набрасывать на вентилятор все новые тезисы о чистом коде.
Насколько я понимаю, термин "чистый код" появился от одноименной книги Роберта Мартина. Там сформулированы некоторые хорошие практики, которые автор рекомендует использовать и обосновывает, почему так лучше. Твой список не совпадает с тем, что предлагает автор. Еще есть "Совершенный код" Стива Макконела, там правила немного свои. Но к архитектуре это отношения не имеет. Думаю, ты слишком вольно трактуешь термин, отсюда и завышенные размытые требования к нему.
Это переводная статья.
Полюбопытствовала, кто автор. Некий Стив Барнерген, я погуглила про него. Ну вроде синьор какой-то где-то.
Имхо, тут вопрос не столько в теме и содержании текста, сколько в том, а почему мнение некоего Стива Барнергена интересно.
почему мнение некоего Стива Барнергена интересно.Потому что в более-менее развитых культурах принято смотреть на содержание и смысл текста, а не на регалии автора.
Мне кажется это работает немного не так. Смотрим рейтинг статей на https://news.ycombinator.com/, выбираем что-то из свежего топа и публикуем перевод на Хабре. Поскольку там статья набрала достаточно лайков, значит и тут успех практически гарантирован. Контент и регалии дело второстепенное.
Контент и регалии дело второстепенное.А лайки на YC из воздуха берутся? Или может быть они всё-таки функция контента, и здесь, и там?
Лайки есть функция контента И аудитории.
Лайки в количестве Х показывают только то, что есть некие Х людей, поставивших статье лайк.
Также возможно, что есть Х+У людей, поставивших статье лайки и У дизлайкнувших.
Вот как по мне, я лайки бы отменила. Если чел хочет нечто отметить насчёт статьи, пусть говорит словами. Ибо, как здесь же в статье написано, нету статей хороших или плохих, а есть неумение формулировать мысли в деталях.
Опять же, тема не новая и не специально техническая. Вот, например, блестящая совершенно (древняя уже) статья "Восстание ткани" Андрея Архангельского - она о том же. Коротко говоря, вышел фильм, и сеть разделилась на 50% пишущих "это говно полное" и 50% пишущих "фильм блестящий".
... Хотя да, лучше уж мелкие лайки, чем миллион односложных каментов. Лайки жрут меньше места. Разве что выдача лайками управляется, это вот плохо.
Если есть возможность проверить данные непосредственно и получить прямые доказательства, например, поставить эксперимент, то регалии автора не имеют значения вообще. Чем меньше возможность такой проверки, тем большее значение имеют регалии (то есть опыт и признанность этого опыта сообществом) автора как косвенные доказательства.
Если я читаю статью по специальности, в которой у меня собственный большой опыт, мне на регалии плевать. Если я читаю статью в области, где я любитель с некоторыми познаниями, я могу смешивать оценку, базирующуюся на своих знаниях, с оценкой, базирующейся на авторитете источника. Если я читаю статью в совершенно посторонней области, кроме авторитета опереться не на что. Здравый смысл, как известно, работает только в хорошо знакомых областях.
Если я читаю статью по специальности, в которой у меня собственный большой опыт, мне на регалии плевать.
Почти. Дело, однако, в том, что вы по специальности, в которой у вас богатый собственный опыт, всё что попало не тянете в рот. Есть некий изначальный отбор статей, которые далее вы уже можете оценить чисто по содержанию.
В данном случае статья
имеет кликбейтный заголовок
в ней спутаны разные вещи, и эта путаница не очевидна людям, в чьей библиотеке дома нету бумажных "Чистого кода" и "Чистой архитектуры", к примеру.
Попробую пояснить, с цитатами из статьи.
Кажется, все сейчас стремятся к «чистому» коду. Нет почти ни одной статьи в блогах, где автор не скажет о том, насколько «чист» его подход. Команды собираются обсудить, какое из возможных решений самое чистое. Разработчики вокруг заверяют, что практикуют «чистый код».
Кто "все (сейчас стремятся)"? "Нет почти ни одной статьи в блогах..." - таких статей дофига. Где автор ни слова не говорит насчёт "чистоты" подхода. На хабре таких как минимум 90%.
"Разработчики вокруг заверяют, что практикуют..." - завидую. Легаси с файлами на 3000 строчек я буду долго ещё вспоминать, при том, что задним числом хорошо вижу их разложение на детали, в которых бы было супер-легко ориентироваться. Короче, это вот либо кликбейт, либо зажрался мужик. Либо он пишет абы чего, чтобы лайкнули, либо вокруг него реально все Практикуют. И дальше уже детали - кто именно что именно делает в рамках подобной практики.
Тем не менее, я осознал: нет такого понятия — чистый код.
Если мне предлагают чьи-либо Озарения, мне бы хотелось знать, на кого снисходит. Кто это, кто в нирвану попал так прижизненно.
... давайте проскочим сразу несколько строчек:
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание, но также могут усложнить поддержку приложения.
Вот тут вопрос. А стоит ли класть синглтоны в суп? Который в кастрюльке, да. Ну просто у каждой вещи есть разные применения. А где-то она вообще не в тему (как суп в синглтоне... ой то есть наборот, синглтоны в супе).
Но. Это же не про "чистый код", это про "архитектуру". И тут я вдруг осознаю (вот да, я же тоже порой озаряюсь), что чел не особенно различает эти две книжки Мартина. Возможно, в обеих вместе прочёл 0 строчек.
Ну и вот эта вот часть, с названием
Если код хороший, то мы должны объяснить почему
Ну? Кто бы спорил, я не понимаю. Вот так написать банальности (дальше ж банальности) и вызвать рукоплескания, это ж надо уметь.
Грубо говоря, если ты в некоей области споришь с классикой, надо же в ней разбираться. Должно же быть видно по тексту, что ты её изучил и с ней не согласен. Тогда уже будет вопрос, в чём именно. Желательно с качественными цитатами ("Такой-то автор пишет там-то, что ХХХ - это вона чо, а я не согласен, поскольку УУУ"). Желательно - ссылки в сеть, или страницы в книгах.
Или ты споришь с узусом? Ну так тогда напиши. Напиши этим милым людям, что по твоим наблюдениям они (твои читатели) запутались и запонтовались. При том, что никто (и с тобой включительно) книжек по теме даже не открывали.
И я не уверена, что при таком раскладе лайков будет вот так же вот дофига.
Ну потому что тут одно дело - лайкать статью, где как бы подтекст "а глупые же эти люди, авторы подобных терминов, ибо слова ни о чём". И совсем другое - лайкать статью, где написано "люди, ребяты!! Я выяснил, это описано где-то! А мы тут (далее нецензурно)". И сколько бы лайков было?
Грубо говоря, если ты в некоей области споришь с классикой, надо же в ней разбираться. Должно же быть видно по тексту, что ты её изучил и с ней не согласен.
Мой комментарий относился исключительно к
в более-менее развитых культурах принято смотреть на содержание и смысл текста, а не на регалии автора.
Поставил бы вам плюс, если бы мог, а вот автору перевода минус.
Автор же оригинальной статьи очевидно не читал эту прекрасную книгу, в которой Роберт Мартин кристально чисто определяет что такое чистый код, и очень сильно это аргументирует. Но тем не менее автор статьи:
...осознал: нет такого понятия — чистый код
Ещё и делает абсолютно не содержательный и бестолковый вывод:
Я пришёл к выводу, что чаще всего, когда мы говорим «чистый» код, то считаем его хорошим, но не можем объяснить почему. Нам просто кажется, что это правильное решение...
Не хотелось бы принадлежать к числу этих "нас"...
И сразу напрашивается вопрос: а велик ли смысл в переводе подобной статьи и какова цель? Ну а если посмотреть профили и работы автора оригинальной статьи, то не находится ничего выдающегося.
И каждый в праве высказать свое мнение и аргументировать (как и я в своем комментарии), но в данном случае содержание статьи уж слишком слабое и субъективное.
Такие понятия, как «инкапсулированый», «тестируемый», «переиспользуемый» или «мокабельный» имеют единое значение для всех нас.
Правда? Автор статьи, конечно же, легко приведет единое объективное определение "тестируемого" кода, да?
Или же автор просто предлагает заменить одну субъективную оценку другой?
Your heavy reliance on singletons may make things easy to understand, but it might not lead to a maintainable application.
Тут лучше бы перевести перефразировать как
Если вы активно используете синглтоны, то они, возможно, и упрощают понимание происходящегоно, но точно также могут привести приложение в неподдерживаемый вид.
что сути не меняет. Оказывается, в своей работе надо понимать что ты делаешь, зачем, к каким последствиям это приведет, и прочие мозговые активности.
Насколько я помню, у Роберта Мартина есть весьма чёткая метрика, по которой можно отличить плохую архитектуру от хорошей — стоимость разработки и поддержки. Так что найти общий знаменатель в том длинном списке, который приводит автор, чтобы придать своим размышлениям некоторый психологический накал, от "читабельности" до "консистентности", не так уж трудно.
Основной критерий "чистого кода" у Роберта Мартина, который он неоднократно упоминал в лекциях - WTF/min = 0. Понятно, что эта метрика зависит от команды, но в рамках конкретного проекта можно построить код так, чтобы даже у новичков вопросов не возникало
Не уверен, что автор оригинала так задумывал, но в переводе получилось жонглирование определениями
Когда кто-то говорит про чистый код, то обычно они имеют ввиду, что он хороший.
"Чистый" -> "Хороший"
Дело в том, что хорошим код может быть по нескольким причинам:
...
- Чистый и аккуратный
"Хороший" -> "Чистый"
Мне кажется тут лучше подошел бы термин "Лаконичный"
Чистый код - это антоним грязного кода. А вот грязный код точно существует.
Нет такого понятия — чистый код