что такое грязный код

Русские Блоги

Чистый код против грязного кода

Написание аккуратного кода является задачей каждого программиста. «Чистый код» указывал на то, что для написания хорошего кода вы должны сначала знать, что такое грязный код и что такое аккуратный код, а затем, благодаря целенаправленной практике, вы действительно можете написать аккуратный код.

WTF / min является единственным стандартом для измерения качества кода. Дядя Боб называет плохой код в книге «ванилью», что лишь подчеркивает, что мы являемся жертвами плохого кода. В Китае есть более подходящий словарный запас: программисты Шишан, хотя и не очень элегантные, но более объективные, являются жертвами и преступниками.

Что касается аккуратного кода, книга дает краткое изложение мастеров:

Среди них моим любимым является описание выразительности, слово, кажется, говорит об истинном значении хорошего кода: опишите функцию кода простым и прямым способом, не больше и не меньше.

Эта статья записывает некоторые мнения человека, который «имеет глубокое чувство того же самого» или «Dingguineng» после прочтения «чистого кода».

1. Искусство именования

Хорошее имя должно иметь следующие характеристики:

1.1 Истинно

Хорошее имя переменной говорит вам: что это такое, почему оно существует, как его использовать

Если вам нужно объяснить переменные в комментариях, вы должны быть менее достойны названия.

Ниже приведен пример кода в книге, демонстрирующий улучшение качества кода путем именования.

1.2 Избегайте введения в заблуждение

1.3 Значимое различие

Код пишется на машину для выполнения, а также для чтения человеком, поэтому концепция должна быть разграничена.

1.4 Используйте прочитанные слова

Если имя не может быть прочитано, то это будет как глупая птица во время обсуждения

1.5 Простое в использовании наименование

Длина имени должна соответствовать размеру его области

1.6 Избегайте размышлений

Например, напишите временный код в коде, тогда читатель должен будет переводить его в его истинное значение каждый раз, когда он видит слово

2. Примечания

Выразительный код не нуждается в комментариях: правильное использование комментариев должно компенсировать нашу неспособность выразить себя в коде.

Книга дает очень яркий пример для показа: используйте код для объяснения, а не комментарии

Поэтому, когда вы хотите добавить комментарий, вы можете подумать о том, сможете ли вы показать намерение кода, изменив наименование или изменив абстрактный уровень функции (кода).

Конечно, вы не тратите пищу из-за удушья. Книга указывает, что следующие ситуации являются хорошими примечаниями.

Среди них наиболее согласен личный пункт 2 и пункт 5, который легко выразить по имени, но почему он не интуитивен, особенно когда речь идет о профессиональных знаниях и алгоритмах. Кроме того, некоторый «не очень элегантный» код на первый взгляд может иметь свою особую готовность, затем следует прокомментировать такой код, чтобы объяснить, почему это так, например, чтобы повысить производительность критического пути, некоторый код может быть принесен в жертву. читаемость.

Три, функция

3.1 Единая ответственность функции

Функция должна делать только одну вещь, эта вещь должна четко отображаться именем функции. Метод суждения прост: посмотрите, может ли функция разделить функцию.

Функция будет либо делать do_sth, либо запрашивать query_sth. Самое отвратительное в том, что имя функции говорит только query_sth, но на самом деле это будет do_sth, что заставляет функцию иметь побочные эффекты. Как примеры в книге

3.2 Абстрактный уровень функции

Каждая функция имеет абстрактный уровень, и операторы в функции должны быть на одном абстрактном уровне, и разные абстрактные уровни не могут быть соединены вместе. Например, если мы хотим положить слона в холодильник, он должен выглядеть так:

Три строки кода в функции описывают три шага, связанных с порядком помещения слона в холодильник на одном уровне (высоте). Очевидно, что шаг pushElephant может содержать много подэтапов, но на уровне pushElephantIntoRefrige вам не нужно знать слишком много деталей.

Когда мы хотим понять новый проект, читая код, мы обычно применяем стратегию в ширину, читаем код сверху вниз, сначала понимаем общую структуру, а затем углубляемся в детали, представляющие интерес. Если нет хорошей абстракции деталей реализации (и сжатой функции), читатель может легко потеряться в деталях.

В какой-то степени это похоже на принцип пирамиды

Каждый уровень должен демонстрировать точку зрения предыдущего уровня, но также нуждается в поддержке следующего уровня: несколько аргументов одного уровня должны быть отсортированы в определенных логических отношениях. pushElephantIntoRefrige является центральным аргументом и требует поддержки нескольких подэтапов, и между этими подэтапами также существует логическая последовательность.

3.3 Параметры функции

Чем больше параметров функции, тем больше входных данных объединено, тем больше нужно тестов и тем проще будет ошибиться.

Выходной параметр труден для понимания по сравнению с возвращаемым значением, которое глубоко эмпатично, а выходной параметр на самом деле не интуитивно понятен. С точки зрения вызывающей функции, возвращаемое значение можно увидеть с первого взгляда, и трудно определить выходной параметр. Выходные параметры обычно вынуждают вызывающую программу проверять сигнатуру функции, что действительно недружелюбно.

3.4 Dont repear yourself

На функциональном уровне проще всего реализовать интуитивно понятное и интуитивно понятное решение, и многим IDE также сложно помочь нам рассказать о куске кода для реконструкции функции.

Однако на практике также может возникнуть ситуация, когда фрагмент кода используется в нескольких методах, но это не совсем то же самое. Если он абстрагирован в общую функцию, то вам нужно добавить параметры и добавить, если еще. Это немного неловко, кажется, что оно исправимо, но не идеально.

Одна из причин вышеуказанной проблемы состоит в том, что этот код также нарушает принцип единой ответственности и выполняет более чем одно, что приводит к плохому повторному использованию. Решение состоит в том, чтобы разделить метод для лучшего повторного использования. Вы также можете рассмотреть метод шаблона, чтобы справиться с разницей.

Четыре, тест

Очень стыдно, что в проектах, которые я испытал, тестированию (особенно модульному тестированию) не уделялось достаточно внимания, а TDD не пробовали. Именно из-за недостатка он более ценен для хорошего тестирования.

Мы часто говорим, что хороший код должен быть читаемым, обслуживаемым и расширяемым, а хороший код и архитектура должны постоянно подвергаться рефакторингу и повторению, но автоматическое тестирование является основой для обеспечения всего этого, и нет высокого охвата Автоматизированное модульное тестирование, регрессионное тестирование, никто не решается изменить код, может только дать ему сгнить.

Поэтому проверьте три элемента кода: читаемость, читаемость и читаемость.

Принципы испытаний и руководящие принципы заключаются в следующем:

ПЕРВЫЕ критерии для тестирования:

Источник

Грязный, чистый, устремлённый

Грязный

Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?

Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

Да, мы научились определять общие закономерности, скажем, в лицах, которые считаются красивыми. Но готовы ли мы дать чёткое определение красоте? Думаю, нет.

Эта аналогия не вполне корректна (как и большинство аналогий), но примерно передаёт ощущения, возникающие при работе с кодом. Неважно – чужим ли, своим ли, написанном пару месяцев назад и уже прочно забытым. Код либо нравится, либо нет. Он либо красив, чист и приятен – либо волосат, уродлив и дурно пахнет.

И, конечно же, у каждого есть свои критерии «красоты кода». Свой, так сказать, вкус.

Но, тем не менее, есть какие-то общие точки, о которых если и спорят, то вяло и соглашательски. Не о сути, а об обрамлении.
Давайте попробуем их перечислить.

Конечно, можно начать спор о «читабельности» или «понимабельности» кода. Это совсем не формализованные термины.

Но и они интуитивно понятны: если, например, кто-то станет доказывать окружающим, что он привык писать всю программу в виде одной-двух огромных функций, «которые делают всё», а решение тех же задач при помощи хотя бы разбиения на большое количество небольших процедур и функций для него непонятно – ему намекнут, что надо бы подтянуть азы.

А желательно – основательно поковырять ООП и стараться инкапсулировать логику в отдельных классах, чтобы не приходилось напрягать головной мозг ни разбором огромных «портянок» кода на десятки экранов, ни запутанными связями процедур и функций, которые к тому же (omg) оперируют кучей глобальных переменных.

Примерно так же дело обстоит и с остальным: конечно, даже среди приведённых 4х пунктов есть взаимоисключающие параграфы (легко читаемый код далеко не всегда будет легко изменяемым, лёгкость расширяемости может конфликтовать с автоматизацией тестирования и т.п.) – но в целом обстановка понятна.

В принципе, руководствуясь этими пунктами (усиливая или ослабляя каждый из них в зависимости от требований конкретных задач), можно легко отличить грязный код от чистого.

Хотя лучше всего, если это происходит само собой, без чересчур подробного анализа. Когда есть «нюх», позволяющий быстро понять, что код грязен и воняет.

Чистый

Теперь давайте всё-таки попробуем разобраться – зачем же он вообще нужен, этот чистый код? И так ли уж плох код грязный и волосатый?

Ну, для начала нужно сказать: it depends.
Бывают моменты, когда написать «быстро и грязно» куда важнее, чем «долго и чисто». Хотя нужно отметить, что «грязно» далеко не всегда означает «быстро». Бывает, что ровно наоборот.

В общем, давайте попробуем рассмотреть более-менее жизненные примеры и постараться понять в каждом случае – когда грязное кодирование бывает оправдано, а когда абсолютно недопустимо.

Например

На сервере что-то происходит, логи пишутся – но они огромны, и читать их некому. Нужно написать небольшую утилитку, которая прочитает логи, вытащит оттуда какие-то численные данные и представит их в виде таблицы. На входе – лог-файл, на выходе – текст с цифирями.

Такую задачу вполне можно написать как угодно грязно – лишь бы утилька работала, а написание не заняло много времени. Ведь мы решаем здесь одну сиюминутную задачу.
Решить же задачу долговременную куда как лучше, изменив систему регистрации ошибок (писать те же численные данные в базу, например).

То есть утилиту эту в идеале используют один-два раза, после чего выкинут. Чистота кода здесь совершенно не важна.

Другой пример

Сервер иногда падает, почему – никто не знает. Анализатор логов позволил понять, что падение вызывается большим количеством однотипных запросов, приходящих с вполне определёнными значениями параметров, и эту ситуацию необходимо срочно воспроизвести.
Нужно написать небольшую утилитку, которая будет в точности воспроизводить это поведение.

Казалось бы – всё один в один повторяет первый пример. Однако здесь возникает вопрос: раз процесс тестирования не предусматривает воспроизведение подобных ситуаций, то не возникнет ли необходимость дальнейшего развития этой утилиты в качестве инструмента тестирования? Не станет ли она самостоятельным приложением, которым пользуются регулярно?

Если ответ – «да» или хотя бы «возможно», то стоит уделить немного внимания тому, чтобы код был понятен хотя бы самому разработчику через месяц-другой, и в то же время позволял бы как-то себя расширять.
К примеру, добавлять другие последовательности запросов, конфигурировать адрес сервера и число запросов, значения ключевых параметров и т.д.

Это ненамного замедлит разработку утилиты «здесь и сейчас» — зато, когда вновь встанет вопрос о воспроизведении последовательности запросов на сервер – утилита будет тут как тут и потребует минимального допиливания; а главное – минимального времени на вспоминание, что там к чему.

Третий пример

Разработка программного модуля для основного программного продукта компании, уже несколько лет успешно развивающегося на рынке.

Казалось бы – модуль изолирован, интерфейсы взаимодействия с другими модулями определены. «Кручу-верчу, говнокод писать хочу». Но тут возникает серьёзное «НО».

Что будет с этим модулем через полгода? Год? Потребует ли он поддержки? Изменения? Расширения функционала? Возможно, в итоге разовьётся в отдельный продукт?
Если хотя бы на один вопрос можно дать хотя бы ответ «вероятно» — то говнокодить, увы и ах, строго не рекомендуется.

Но это не весь список вопросов. А кто будет работать с этим модулем через два-три года? Тот, кто его писал, или кто-то другой?

Если кто-то другой – то ведь ему придётся в этом коде разбираться.
И если это будет плохой, негодный код – то либо плакать и жевать кактус, проклиная создателя, либо выкинуть всё на помойку и переписать заново, получая при этом поджопники от начальства за срыв сроков.

Если же работать с этим кодом будет сам разработчик – то тем более. Да он через полгода уже не будет помнить: что, где и как работает! Ему придётся разбираться в этом коде так, как будто код совершенно чужой. Не враг же он самому себе?

Четвёртый пример

Разработка приложения (сайта, базы данных с простейшим интерфейсом – чего угодно) под заказ в сжатые сроки за небольшие деньги.

С одной стороны – code and forget, можно писать что угодно и как угодно, лишь бы работало.

С другой стороны – а что, если этот заказчик через месяц вернётся и попросит за дополнительные деньги что-то добавить или переделать? Будем плакать, колоться, но жевать кактус? Откажемся от заказа?

А что, если он обратится к другому разработчику (компании), получит негативный feedback о качестве исполнения проекта, и больше никогда не вернётся к «злым говнокодерам», да ещё своим друзьям отсоветует?

Я уже не говорю о таких вещах, как качество кармы и память потомков.

Пятый пример

Самый жёсткий случай абсолютного недопущения говнокодирования.
Мне сложно даже представить себе какие-либо аргументы в пользу осознанного выбора плохого кода в случае командной разработки.

Да что там говорить – один говнокодер способен принести вреда больше, чем вражеский агент в тылу врага!
Если команда не изолирует его, бросив на написание никому не вредящих, ни с чем не связанных, абсолютно левых утилит и мини-приложений – то его продуктивность в команде будет не то, что нулевой – она будет отрицательной!

Необходимость читать, вникать, исправлять, матерясь – а в итоге выкидывать и переписывать заново – мало того, что занимает больше времени, чем самостоятельная разработка хорошего кода, так ещё и портит общую атмосферу в команде и минусует мораль всех разработчиков, вынужденных сталкиваться с говнокодом не по своей вине.

А тестирование? Сопровождение? Расширение функционала??

Я мог бы написать ещё пару хулительных абзацев – но нет. Не могу.
Клавиатура выпадает из ослабевших пальцев при мысли о том, сколько вреда может принести говнокод в команде…
Это ужасно… ужасно…

Устремлённый

Итак, мы примерно понимаем, что такое грязный код и чем он плох. Мы всё ещё не вполне понимаем, что такое чистый код, но ощущаем его необходимость.
Почему же он всегда есть, этот грязный код, почему он всегда присутствует и портит жизнь всем – в том числе и своим авторам?

На мой взгляд, всё предельно просто: писать чистый код – это искусство, это сверхспособность, развить которую в себе может практически каждый; но далеко не каждый даже задумывается о необходимости её развития.

Не говоря уже о том, чтобы получать представление о сиём предмете в профильном университете или на профильных курсах – там дают лишь самые верхушки «нужных» технологий, платформ и языков – немногие вообще уделяют специальное внимание улучшению собственных навыков чистого кодирования.

Конечно, с течением времени, если у разработчика развит «нюх на грязый код», он неизбежно начинает писать всё чище и лучше.
Он читает на досуге интересные статьи, он изучает паттерны проектирования. Но бывает, что он делает это потому, что ему интересно – а не потому, что осознаёт необходимость развития своих навыков написания чистого кода.

И при этом, в идеале, он всегда ощущает, что его код всё ещё недостаточно хорош, что ему ещё далеко до совершенства. И пусть его сегодняшний «говнокод» на голову выше самого лучшего, что он писал два-три года назад – всё равно есть куда расти.

В связи с этим мне вспоминается один интереснейший разговор с моим коллегой, которому, как и мне, довелось провести не одно собеседование с кандидатами на должность разработчика – возможно, даже больше, чем собеседований в качестве такового кандидата.

Мы говорили о молодых программистах и о том, какие их качества более всего свидетельствуют о потенциале профессионального развития.
В итоге всё свелось к нескольким простейшим пунктам, в порядке важности:

1) Хорошо работающая голова (поэтому у нас всегда есть задачки на логику)
2) Высокий уровень самокритичности (поэтому всегда есть задачки на написание кода и поиск ошибок в нём)
3) Интерес к программированию (важен в меньшей степени, задачками не определяется в принципе)

То есть понятно, что если голова работает плохо – то разработчиком не станешь при всём желании и старании. Однако, если она даже золотая и светится от разумности – это ещё далеко не гарантия.

Частенько бывает, что молодой специалист, видя, как легко ему всё даётся (особенно – в сравнении с большинством своих одногруппников, сокурсников, просто ровесников) начинает искренне считать, что круче бывают только яйца.
И, хотя наверняка к этому есть некоторые основания, но ЧСВ зашкаливает настолько, что в итоге в один прекрасный момент он просто перестаёт развиваться, считая, что «я и так умный, а кто пытается это оспорить – тот дундук».

И хорошо, если при этом у него остаётся живой, острый интерес к своей работе. Если он продолжает читать статьи и книги «потому, что интересно». Тогда у него остаётся небольшой шанс не застыть, а продолжать развиваться.

И, наконец, бывает, что парень (или девушка – что встречается гораздо реже, уж извините меня за эту неполиткорректную реальность) и умный, и самокритичный – редко остаётся довольным своим кодом и вообще считает, что ему ещё расти и расти – в какой-то момент теряет (хорошо, если не полностью) интерес к профессии, начинает меньше читать, меньше экспериментировать.

Начинает чаще выполнять задачи «строго по спецификации», желательно – уже знакомые задачи, из знакомых сфер. Меньше уделять внимания новым языкам, платформам, концепциям.

И становится вполне хорошим, годным специалистом. Зачастую даже не очень узким, а относительно многопрофильным. Вполне себе уважаемым.

Но так и не достигает вершины своего изначального потенциала.

И лишь в очень редких случаях умный, способный, в высшей степени самокритичный молодой человек с горящими глазами растёт ежегодно, ежечасно – и в итоге становится звездой. Бывает, что очень быстро становится «локальным светилом» – но не застывает, не ограничивается этим, а продолжает расти, развиваться, совершенствоваться.

Ах, как прекрасна эта картина – так и хочется смахнуть несуществующую слезу! Как прекрасен он, этот устремлённый в бесконечность молодой человек, своим духовным порывом приподнимающий самые небеса, в которые нацелен его всепроникающий взгляд!

Как счастливы люди, окружающие его, когда они понимают, сколь величествен его путь, и делают, в свою очередь, хоть два-три шага рядом с ним. Приближаясь хоть на волос к той прекрасной бесконечности возможностей, куда летит он на всех парах!

Как хочется видеть побольше горящих глаз, светлых умов, обращённых в эту бесконечность. Как хочется хотя бы немного помочь этим атлантам на их пути, хоть на мгновение поддержать, подтолкнуть ввысь, приблизить их к этой недостижимой и прекрасной цели.

И остаться внизу, с щемящей радостью наблюдая, как пронизывают они пространство и время в своём стремлении.

И знать, что хотя бы немного, хотя бы чуть-чуть – помог, поддержал, а не стоял в стороне, застывший в своём упоении собственной важностью, не бросал презрительных взглядов – «пхе… молодёжь..»

Источник

8 признаков плохого кода

Авторизуйтесь

8 признаков плохого кода

Порой для того, чтобы определить, что перед вами плохой код достаточно одного взгляда на него: форматирование и регистр имён сущностей сразу бросаются в глаза. В этой статье перечислены признаки, которые помогут вам понять, что перед вами действительно плохой код.

Загадочные имена

Одна из основных особенностей плохого кода — стратегия именования сущностей. Если в команде отсутствуют соглашения об именовании, их следует принять. С ростом приложения правильное именование становится критически важным.

Общие принципы именования помогут команде (особенно если в ней есть разработчики разного уровня) находить общий язык и лишний раз не ломать голову в попытках понять\придумать имя для переменной.

Вот принципы которые вы можете использовать:

Огромные методы

Слишком большие методы являются источником ошибок и сложны для понимания. Есть правило: функция должна выполнять одну задачу и выполнять её хорошо.

Божественный объект

Так называют огромный класс, который делает слишком много разных вещей. Класс, как и функция, должен иметь одну цель существования. Поэтому божественный объект должен быть разделён на несколько сущностей, каждая из которых имеет только одну задачу.

Дублирующийся код

Идентичный код, который разбросан по всему приложению. Он увеличивает сложность поддержки и тестирования системы. Повторяющиеся куски кода являются признаком того, что вам пора задуматься о рефакторинге.

Избыток параметров

Длинный список параметров усложняет чтение, вызов и тестирование функций. Уменьшение числа параметров позволит вам сократить время на изучение и тестирование кода.

Неуместная сложность

Принудительное использование чрезмерно сложных шаблонов проектирования там, где более простой архитектуры было бы достаточно.

Использование сложных паттернов без необходимости показывает не ваш скилл, а неспособность увидеть картину целиком и избежать излишней сложности.

Хирургия дробовиком

Термин shotgun surgery используется для случая, когда одно изменение в коде влечёт за собой множество других изменений.

Изменения в классе A требуют множества незначительных изменений в других классах

Изменяемость переменных

Код, переменные в котором изменяются непредсказуемо, сложно отлаживать и проводить рефакторинг.

Источник

Что такое «чистый код» в 2020-м?

«Чистый код» и чистый кот

Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».

Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.

Нам стало интересно: в 2020-м представления человечества о чистом коде остались теми же, или с выхода книги как-то изменились? Различаются ли мнения у разных айтишников: может, бэкендеры видят всё с одного ракурса, а тестировщики с другого?

А поскольку тема холиварная, наверняка кто-то из вас окажется не согласен с какими-то из мнений. В таком случае айда спорить в комментариях, это тоже весело!

UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.

DotNext

Джон Скит

Джон — легенда Stack Overflow, автор книги «C# in Depth» и один из самых известных дотнетчиков планеты. Он дал нам такое определение:

«Для меня чистый код — это скучный код, с точки зрения имплементации. Единственный сюрприз в нём — это то, насколько он лишён сюрпризов. Я должен чувствовать „Да, я бы мог такое написать”, даже если бы на самом деле я и не мог — по тому, насколько хорошо он спроектирован.

Когда абстракция выбрана верно, имплементация выводится естественным образом. В идеале эта абстракция также должна ощущаться простой и очевидной — хотя на самом деле доведение её до такого состояния могло занять часы, недели, месяцы размышления и экспериментов.

Упомянутое отсутствие сюрпризов позже переносится и на использование: когда я пишу код, используя хорошо спроектированный API, мой код тоже становится очевидным и скучным».

Андрей Акиньшин

Когда мы спросили, что он думает про чистый код, Андрей сослался на два своих старых хабрапоста: «Совершенный код и реальные проекты» и «Комментировать или не комментировать». И мы выбрали для вас пару абзацев оттуда, с которыми кто-то наверняка захочет поспорить:

«Я люблю совершенный код. Ведь это не только правильный подход к написанию программ, но и настоящее искусство. От чтения хорошего листинга я получаю не меньше удовольствия, чем от чтения хорошей книги. Проектировать архитектуру большого проекта ничуть не легче, чем проектировать архитектуру большого здания, а в случае хорошей работы — результат не менее прекрасен. Порой меня завораживает то, как изящно переплелись паттерны проектирования в создании совершенной программной системы. Меня восхищает внимание к деталям, когда абсолютно каждый метод настолько прост и понятен, что претендует на место классического примера совершенного кода.

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно».

Дилан Битти

Хабрачитатели могут помнить Дилана по его вдумчивому и яркому докладу про работу с легаси-кодом: для Хабра мы делали его расшифровку. И когда мы обратились к Дилану по поводу чистого кода, он написал такой развёрнутый и продуманный текст, что его хоть отдельным постом публикуй:

«Для меня интересно, что понятие «чистый код» распространилось далеко за пределы круга людей, читавших книгу Роберта Мартина. Я общался с многими, многими разработчиками, которые слышали слова «clean code», но не читали книгу. Я даже встречал их в кодревью: «Тут всё довольно хорошо, но можешь немного почистить?» — и такая просьба может быть раздражающе неточной, если неочевидно, что «чистый» означает в данном конкретном контексте.

В английском есть слова, которые часто встречаются вместе — «clean», «tidy», «organised», «neat» — и для меня как носителя английского они все означают немного разные вещи. Я думаю, что полезно рассмотреть некоторые коннотации этих слов применительно к разработке софта.

Представим, например, кухню ресторана. У слова «clean» в этом контексте будут очень конкретные коннотации. Всё вымыто, стерилизовано, нет никакой угрозы заражения из-за сырых продуктов, и тому подобное.

Но это не означает автоматически, что здесь всё хорошо организовано. Если вы когда-нибудь пытались приготовить еду у друга или в квартире, снятой на Airbnb, вы знаете, как раздражает, когда вещи не на своих местах. Средство для мытья посуды стоит в буфете, в котором рассчитываешь увидеть кастрюли, а чеснокодавилка вообще непонятно где. Да, всё чистое — нет угрозы, что кто-то отравится едой, приготовленной на этой кухне — но работать в таких условиях раздражает.

А теперь представим деревообрабатывающий цех. В этом месте грязь тоже может вызывать проблемы, но здесь у вас совсем не такое определение «чистоты», как на кухне. Вы можете начищать зубило, пока оно не начнёт сверкать, но вы всё равно вряд ли стали бы резать им сосиски. Так что слово «clean» может быть очень субъективным.

Но для меня слова вроде «tidy» и «organised» работают и таких контекстах, где «clean» не очень хорошо подходит. «Organised» означает, что кто-то как следует подумал, как расположить элементы конкретного рабочего места, а «tidy» означает, что эти элементы действительно находятся на отведённых им местах. Как говорится в старой поговорке, «всему есть своё место и всё на своём месте».

Возможно, в случае с кодом нам стоит думать о словах «clean», «tidy» и «organised» как о трёх разных понятиях. «Clean» означает, что вы смотрите на составные части кодовой базы — методы, функции, интерфейсы — и не видите никаких причин для беспокойства. В именовании придерживаются конвенций; названия переменных и методов написаны без ошибок; в деталях вроде отступов и скобок придерживаются единого стиля; куда ни посмотри, видишь подтверждения того, что на базовом уровне этим заправляют люди, подходящие к делу серьёзно. Это противоположность «грязного кода» — такого, где в названиях куча опечаток, фигурные скобки и отступы захотичны, несоответствующие названия файлов. Это те вещи, которые магически оказываются исправлены, когда вызываешь инструмент «code cleanup» в чём-то вроде ReSharper.

«Organised» — это про архитектуру. Это о том, что можно нырнуть в незнакомую кодовую базу и найти вещи там, где ожидаешь их увидеть. Интерфейсы и доменные границы помогают, а не мешают; методы и переменные названы не просто корректно названы с точки зрения языка, но и отражают единый язык бизнеса, с которым работаешь.

А «tidy» — это про уважение локальных конвенций… кодовая база, в которой можешь найти нужные вещи в соответствующих им местах, даже если конкретная организационная модель вам в этот момент не слишком понятна.

Я думаю, что когда говорят о борьбе за «чистый код», этим обычно подразумевают все три эти вещи. Но ставить целью полностью «чистый код», особенно когда работаешь со сложным легаси-проектом, может быть довольно устрашающей перспективой. Возможно, нам всем было бы полезно задуматься немного глубже и разобраться, что именно из составляющих «чистого кода» по-настоящему принесёт пользу проекту, над которым мы в данный момент работаем».

Heisenbug

Это «конференция по тестированию не только для тестировщиков»: она на стыке тестирования и разработки. Поэтому многие её спикеры понимают специфику обоих этих миров сразу.

Иван Крутов и Анна Чернышева

Иван и Анна работают в разных компаниях, но кое-что их объединяет: оба много знают про Selenium. Мы общались с ними одновременно, так что получилось совместное определение:

Иван: «Для меня самое простое определение чистого кода — это код, который понятен без комментариев, «самодокументирующийся». Код, который завален комментариями, которые пытаются объяснить, что он делает — это не чистый код».

Анна: «У меня похоже: это код, в котором можно быстро разобраться, исправить баг, легко расширить его, дополнить».

Иван: «Ещё можно сказать, что это «код, за который не стыдно». Вообще говорят, что если ты смотришь код, который написал полгода назад, и не ужасаешься, то ты не развиваешься. Получается, что с каждым годом твой код должен становиться всё чище».

Себастиан Дашнер

Себастиан — Lead Java Developer Advocate в IBM, и его часто можно увидеть на Java-конференциях. Но поскольку сейчас он прилетает на Heisenbug, мы спросили его о чистом коде именно в контексте тестирования, и он ответил:

«По моему опыту, качество кода важно не только в случае продакшн-кода, но и для наших тестов. В тестах чистым кодом, правильными абстракциями и делегацией часто пренебрегают, что приводит к такому коду тестов, который не поддержишь. Когда мы рефакторим продакшн-код и меняем его поведение, становится видно, хорошую работу ли мы проделали над моделированием и имплементацией наших тестов».

Андрей Лушников

Андрей работает над инструментом для браузерной автоматизации Playwright, о котором мы недавно писали. Его определение оказалось самым лаконичным:

«Чистый код — это тупой, очень понятный код. И чем тупее, тем лучше».

Александра Сватикова

Александра — эксперт по информационной безопасности в Одноклассниках, которая «начинала в IT как Java-разработчик, но свернула не туда». Её определение оказалось таким:

«Чистый код обладает тремя свойствами: другой разработчик может легко прочесть и понять его, незначительные доработки требуют соразмерных усилий, и эффект от конкретного изменения может быть предсказан.

На деле это означает, что код структурирован, лаконичен, следует общепринятым практикам для того языка на котором написан, не содержит неявных зависимостей или побочных эффектов и покрыт тестами».

HolyJS

Андрей Мелихов

Андрей известен многим по проекту «Девшахта». Неудивительно, что человек, постоянно формулирующий свои мысли в «Девшахта-подкасте», и свою позицию сформулировал чётко:

«Роберт «Дядя» Мартин тремя своими главными книгами («Clean Code», «The Clean Coder» и «Clean Architecture»), как мне кажется, пытается для себя ответить на вопросы: кто, что и как должен писать. Можно поспорить о корректности некоторых его выводов, но вот что, неоспоримо — эти книги построены на богатом личном опыте и здравом смысле. И в рамках этой идеи я могу сказать, что для меня чистый код — это код, который написал бы человек, споткнувшийся о немалое количество подводных камней в своей жизни и в этом болезненном процессе научившийся идти осторожной походкой, позволяющей этих камней избегать.

Вам может быть неудобен стиль этого человека, но если вы будете ему следовать, вы точно останетесь целы. Вы можете взять этот стиль и переработать его, сделать удобным для себя. Или вы можете отчаянно нырнуть в реку набивать собственные шишки, вырабатывать свой собственный стиль, пока остальные будут смотреть на вас с недоумением, двигаясь под присмотром старших товарищей.

Чистый код — это код, который легко читается, легко поддерживается и легко расширяется. Именно эти три аспекта закладывают прочный фундамент под приложениями, которым предстоит жить годами в условиях изменчивости внешних требований. А именно такие приложения мы пишем в крупных компаниях»

Александра Калинина

Александра состоит в программном комитете HolyJS, у неё большой опыт в программировании — и, хотя она не с Heisenbug, с тестами она тоже знакома не понаслышке (unit, integration, E2E, B2B). Вот её текст:

«Clean code — сейчас это простое понятие, но понять его довольно трудно. Мне кажется, что чистый код может получиться при соблюдении следующих правил:

— каждый отдельный кусочек кода должен иметь возможность масштабироваться или расти/улучшаться независимо от других кусочков, но при этом сохранять изначальную идею/интеграцию с другими кусочками (в этом очень помогает SOLID, а также правило «все решения, которые могут быть приняты позже, должны приниматься позже»).
— код должен читаться как увлекательная книга, с понятными типичными названиями и обозначениями. К примеру, если вы задумаете писать рассказ, то у него, вероятнее всего будет типичная структура вроде вступления, завязки, кульминации и развязки. Даже если только вы один работаете на проекте, код должен читаться легко вами же спустя любое время, независимо от выбранной архитектуры, языка, фреймворков.
— код должен иметь понятную структуру. Т.е. должна быть понятна причина, по которой тот или иной кусочек кода находится в проекте.
— каждая строчка кода должна быть обоснована с точки зрения бизнеса»

Nicolò Ribaudo

Николо, будучи ещё студентом, стал одним из ключевых разработчиков компилятора Babel (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:

«Чистый код — это код, который можно легко разделить на маленькие атомарные составляющие.

«Атом кода» — это наименьший возможный набор инструкций, обладающий самостоятельным смыслом, не зависящие излишне от окружающего контекста: имена переменных и операций достаточно описательные, чтобы читающему их не требовалось выделять в голове дополнительную память для хранения их значений и возможных модификаций, а также не требовалось смотреть ещё куда-то в коде, чтобы понять, что означает результат этого «атома». Чем меньше атомы, тем проще понять, что делает код.

Код может быть чистым вне зависимости от языка программирования или парадигмы: атомы можно реализовать как маленькие объекты, функции, или даже как маленькие фрагменты кода, не изолированные синтаксически».

Заключение

Наконец, когда мнения были собраны, мы показали их самому Дядюшке Бобу и спросили, хочется ли ему что-то сказать. Ответ оказался таким:

«Я полностью поддерживаю комментаторов выше. Я бы добавил только одну вещь, которую когда-то сказал Майкл Фезерс: “Чистый код всегда выглядит так, будто его писал человек, которому не всё равно”».

Его заключение звучит очень дружелюбно. Но чистый код — такая дискуссионная тема, что пока кто-то из вас согласно кивает, кто-то другой наверняка горит, ощущая что-то такое:

Источник