что такое чистый код в программировании

Чистый код: причины и следствия

Автор: Виктор Свирский, Senior Python Developer / Team Lead, DataArt

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

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

Что такое чистый код?

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

Стоит ли писать чистый код?

Однозначно стоит! Но не всегда и не везде стоит уделять чистоте слишком много внимания.

Не стоит забывать о целесообразности и сроке жизни вашего кода. Например, если перед вами стоит задача разработки концепции — PoC (Proof of concept), и вы доказываете, что выбранный стек технологий выполняет поставленную задачу, ваш код станет неактуален уже через неделю или две. Не стоит тратить силы на совершенствование этого функционала.

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

Что поможет улучшить ваш код?

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

Самоорганизация

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

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

Любой опыт лучше, чем его отсутствие.

Командная работа

Большинство задач решается в команде. Очень важно разделять ответственность за качество между ее участниками. Чем больше команда, тем сложнее поддерживать продукт в хорошем состоянии. Рассмотрим несколько подходов удержания кода в вышеуказанных условиях.

Во время проверки кода необходимо учитывать несколько вещей:

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

Непрерывная интеграция работает, когда вы следуете двум простым правилам:

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

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

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

Чем меньше ошибок в коде, тем выше его качество. Тщательное тестирование отфильтровывает критические ошибки и гарантирует, что код работает так, как задумано.

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

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

Когда возникает ошибка, проанализируйте ее с помощью нескольких вопросов:

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

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

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

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

Источник

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

Грязный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чистый

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

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

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

Например

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пятый пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Что такое «чистый код» в 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 (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:

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

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

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

Заключение

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

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

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

Источник