чистый код что это
Как писать чистый код?
Aug 30, 2019 · 5 min read
Роберт Мартин: «Единственная адекватная мера качества кода — это количество восклицаний « какого чёрта!» в минуту».
Позвольте объяснить. Делая код-ревью, я испытываю три эмоции:
Что же так влияет на нас, когда мы видим код?
Мы часто говорим, что пишем код, но относимся к этому иначе, чем к статье или рассказу. На самом деле это очень похоже на историю, следующую принципу Хемингуэя:
Первый черновик любой статьи не должен публиковаться. Автору будет стыдно. Так и первые мысли разработчика вряд ли ясны. Код будет, вероятно, беспорядком из мутных идей и синтаксиса. В этом сущность черновика.
Тем не менее разраб о тчики нагло совершают преступление, оставляя такой код в проекте, поскольку он в значительной мере скрыт. Никто не читает его в течение нескольких месяцев, пока проект не получит фонтан проблем. Тогда кто-то пробегается по «коду с душком». И он становится ещё хуже, превращаясь в неподдерживаемый кошмар.
Поэтому важно вкладываться в качество кода. Это как инвестирование времени, денег и усилий в фундамент здания, чтобы оно было крепким. Наступит шторм — и это здание устоит, а те, у которых фундамент не был в приоритете, рухнут.
Чистый код почти всегда окупается в считанные месяцы (в зависимости от масштаба проекта). Четко выражающий свою цель код без сюрпризов легче понять. Поэтому он с меньшей вероятностью содержит ошибки.
Чистота кода должна стать частью мышления. Для этого требуется практика, и вы научитесь писать чисто со временем. Но вы должны начать с мышления. Так вы привыкнете просматривать и пересматривать свой код, чтобы он был предельно чистым. Но как овладеть искусством чистого кода? Ответы ниже.
Именование
Кендрик Ламар: «Если я собираюсь рассказать реальную историю, то начну с моего имени ».
В программном обеспечении имена везде. Мы именуем функции, классы, аргументы, пакеты и много чего ещё. Мы называем исходные файлы, каталоги и все, что в них. Мы постоянно называем, называем и называем. Это становится самым важным препятствием на пути к чистому коду.
Имя должно раскрывать намерение. Выбор имен отнимает время, но экономит его ещё больше, когда становится тяжело. Позаботьтесь о своих именах. Поменяйте их, когда найдете лучшие варианты. Читающие код люди будут безмерно благодарны.
Всегда помните, что имя любой переменной, функции или класса должно отвечать на три вопроса:
Это требует не только хороших навыков описания, но и общего культурного фона. Никто не может научить вас этому лучше, чем вы сами.
Функция должна делать что-то одно
Любая система в ООП построена из предметно-ориентированного языка, который создан программистами для её точного описания. Функции — это глаголы, классы — существительные. Обычно первая линия организации кода на любом языке — функции. Их правильное написание — суть хорошего кода. Есть два золотых правила:
Ваша функция не должна быть настолько большой, чтобы содержать вложенные структуры. Не более одного или двух отступов. Эта техника облегчает чтение, понимание и усвоение. Мы также должны убедиться, что выражения функции находятся на одном уровне абстракции. Смешивание уровней запутывает и приводит к неуправляемому коду.
Опытные программисты думают о функциях как об историях. Они используют возможности языка для создания более богатого, выразительного и чистого блока кода, работающего как идеальный рассказчик.
Комментарии не маскируют плохой код
Винус Уильямс: «Каждый оставляет свои комментарии. Вот откуда берутся слухи».
Всегда помните, что ясный и выразительный код с небольшим количеством комментариев намного превосходит загроможденный и сложный код с большим количеством комментариев. Не тратьте время на объяснение беспорядка. Посвятите время его устранению.
Форматирование — приоритет
Робер Мартин: «Форматирование кода — это общение, а общение — первостепенная задача профессионального разработчика».
Это утверждение нельзя переоценить, и способность к коммуникации — одна из важнейших черт профессионала.
Отформатированный код — окно в ваш разум. Мы хотим, чтобы люди были впечатлены нашей упорядоченностью, вниманием к деталям и ясностью мышления. Но если они видят массу неоднородного кода, не имеющего четкого начала и конца, это сразу подрывает нашу репутацию. В этом нет никаких сомнений!
Если вы думаете, что «заставить код работать» — первостепенная задача профессионального разработчика, вы сильно заблуждаетесь. Создаваемые сегодня функции с большой вероятностью будут изменены, но читаемость кода никогда не изменится. Стиль и читаемость продолжают влиять на удобство сопровождения кода даже после того, как его изменят до неузнаваемости.
Всегда помните, что вас будут помнить за ваш стиль и дисциплину, и очень редко — за код. Поэтому нужно позаботиться о том, чтобы он был хорошо отформатирован и подчинялся простым правилам, понятным всей команде.
Начинайте с try-catch-finally
Жорж Кангилем: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».
Обработка ошибок — это то, что делают все программисты. Данные могут быть неправильными, а устройства могут отказывать. Как разработчики мы должны убедиться, что код выполняет то, что от него ожидают. Но задача заключается не просто в обработке ошибок, а в их обработке понятным образом.
В коде преобладает обработка ошибок. Иногда она настолько не организована, что полностью уничтожает цель и логику основного кода. Код должен быть чистым и надежным, он должен обрабатывать ошибки изящно и в соответствии со стилем. Правильное вложение и обработка ошибок отличают мастера.
Всегда помните: каждое создаваемое исключение должно содержать достаточно информации, чтобы понять его источник. Творческие, информативные сообщения об ошибках запоминаются, оставаясь в проекте и после ухода программиста.
Заключение
Каким выражением можно подвести итог? Ответ — чувство кода. Здравый смысл.
По словам Роберта Мартина, написание чистого кода требует дисциплинированного использования множества небольших техник, применяемых через болезненно приобретенное чувство «чистоты». Эти техники вместе называются чувством кода. Некоторые из нас рождаются с ним, другим приходится мучительно приобретать его практикой, настойчивостью и ещё раз настойчивостью. Это чувство помогает нам не только различать хороший и плохой код, но также формировать стратегии для преобразования плохого кода в хороший.
Говоря коротко, программист с чувством кода — это художник, который может превратить пустой экран в изящное произведение искусства, которое запомнится на долгие годы.
Гарольд Абельсон: «Программа должна быть написана для человека, который будет ее читать, и только попутно — для машины, которая будет ее выполнять».
Вероятно, хватит рекомендовать «Чистый код»
Возможно, мы никогда не сможем прийти к эмпирическому определению «хорошего кода» или «чистого кода». Это означает, что мнение одного человека о мнении другого человека о «чистом коде» обязательно очень субъективно. Я не могу рассматривать книгу Роберта Мартина «Чистый код» 2008 года с чужой точки зрения, только со своей.
Тем не менее, для меня главная проблема этой книги заключается в том, что многие примеры кода в ней просто ужасны.
В третьей главе «Функции» Мартин даёт различные советы для написания хороших функций. Вероятно, самый сильный совет в этой главе состоит в том, что функции не должны смешивать уровни абстракции; они не должны выполнять задачи как высокого, так и низкого уровня, потому что это сбивает с толку и запутывает ответственность функции. В этой главе есть и другие важные вещи: Мартин говорит, что имена функций должны быть описательными и последовательными, и должны быть глагольными фразами, и должны быть тщательно выбраны. Он говорит, что функции должны делать только одно, и делать это хорошо. Он говорит, что функции не должны иметь побочных эффектов (и он приводит действительно отличный пример), и что следует избегать выходных аргументов в пользу возвращаемых значений. Он говорит, что функции обычно должны быть либо командами, которые что-то делают, либо запросами, которые на что-то отвечают, но не обоими сразу. Он объясняет DRY. Это всё хорошие советы, хотя немного поверхностные и начального уровня.
Но в этой главе есть и более сомнительные утверждения. Мартин говорит, что аргументы логического флага — плохая практика, с чем я согласен, потому что неприкрашенные true или false в исходном коде непрозрачны и неясны по сравнению с явными IS_SUITE или IS_NOT_SUITE … но рассуждения Мартина скорее сводятся к тому, что логический аргумент означает, что функция делает больше, чем одну вещь, чего она не должна делать.
Мартин говорит, что должно быть возможно читать один исходный файл сверху вниз как повествование, причем уровень абстракции в каждой функции снижается по мере чтения, а каждая функция обращается к другим дальше вниз. Это далеко не универсально. Многие исходные файлы, я бы даже сказал, большинство исходных файлов, нельзя аккуратно иерархизировать таким образом. И даже для тех, которые можно, IDE позволяет нам тривиально прыгать от вызова функции к реализации функции и обратно, точно так же, как мы просматриваем веб-сайты. Кроме того, разве мы по-прежнему читаем код сверху вниз? Ну, может быть, некоторые из нас так и делают.
А потом это становится странным. Мартин говорит, что функции не должны быть достаточно большими, чтобы содержать вложенные структуры (условные обозначения и циклы); они не должны иметь отступов более чем на два уровня. Он говорит, что блоки должны быть длиной в одну строку, состоящие, вероятно, из одного вызова функции. Он говорит, что идеальная функция не имеет аргументов (но всё равно никаких побочных эффектов??), и что функция с тремя аргументами запутанна и трудна для тестирования. Самое странное, что Мартин утверждает, что идеальная функция — это две-четыре строки кода. Этот совет фактически помещен в начале главы. Это первое и самое важное правило:
Первое правило: функции должны быть компактными. Второе правило: функции должны быть ещё компактнее. Я не могу научно обосновать своё утверждение. Не ждите от меня ссылок на исследования, доказывающие, что очень маленькие функции лучше больших. Я могу всего лишь сказать, что я почти четыре десятилетия писал функции всевозможных размеров. Мне доводилось создавать кошмарных монстров в 3000 строк. Я написал бесчисленное множество функций длиной от 100 до 300 строк. И я писал функции от 20 до 30 строк. Мой практический опыт научил меня (ценой многих проб и ошибок), что функции должны быть очень маленькими.
Когда Кент показал мне код, меня поразило, насколько компактными были все функции. Многие из моих функций в программах Swing растягивались по вертикали чуть ли не на километры. Однако каждая функция в программе Кента занимала всего две, три или четыре строки. Все функции были предельно очевидными. Каждая функция излагала свою историю, и каждая история естественным образом подводила вас к началу следующей истории. Вот какими короткими должны быть функции!
Весь этот совет завершается листингом исходного кода в конце главы 3. Этот пример кода является предпочтительным рефакторингом Мартина класса Java, происходящего из опенсорсного инструмента тестирования FitNesse.
Повторю ещё раз: это собственный код Мартина, написанный по его личным стандартам. Это идеал, представленный нам в качестве учебного примера.
На этом этапе я признаюсь, что мои навыки Java устарели и заржавели, почти так же устарели и заржавели, как эта книга, которая вышла в 2008 году. Но ведь даже в 2008 году этот код был неразборчивым мусором?
Давайте проигнорируем import с подстановочными знаками.
Но это неправильное предположение! Вот собственное определение Мартина из более ранней части этой главы:
Побочные эффекты суть ложь. Ваша функция обещает делать что-то одно, но делает что-то другое, скрытое от пользователя. Иногда она вносит неожиданные изменения в переменные своего класса — скажем, присваивает им значения параметров, переданных функции, или глобальных переменных системы. В любом случае такая функция является коварной и вредоносной ложью, которая часто приводит к созданию противоестественных временных привязок и других зависимостей.
Мне нравится это определение! Я согласен с этим определением! Это очень полезное определение! Я согласен, что плохо для функции вносить неожиданные изменения в переменные своего собственного класса.
Так почему же собственный код Мартина, «чистый» код, не делает ничего, кроме этого? Невероятно трудно понять, что делает любой из этих кодов, потому что все эти невероятно крошечные методы почти ничего не делают и работают исключительно через побочные эффекты. Давайте просто рассмотрим один приватный метод.
Мартин утверждает в этой самой главе, что имеет смысл разбить функцию на более мелкие функции, «если вы можете извлечь из неё другую функцию с именем, которое не является просто повторением её реализации». Но потом он даёт нам:
Примечание: некоторые плохие аспекты этого кода не являются виной Мартина. Это рефакторинг уже существующего фрагмента кода, который, по-видимому, изначально не был написан им. Этот код уже имел сомнительный API и сомнительное поведение, оба из которых сохраняются в рефакторинге. Во-первых, имя класса SetupTeardownIncluder ужасно. Это, по крайней мере, именная фраза, как и все имена классов, но это классическая фраза с придушенным глаголом. Это такое имя класса, которое вы неизменно получаете, когда работаете в строго объектно-ориентированном коде, где всё должно быть классом, но иногда вам действительно нужна всего лишь одна простая функция.
*
Неужели вся книга такая?
В основном, да. «Чистый код» смешивает обезоруживающую комбинацию сильных, вечных советов и советов, которые очень сомнительны или устарели. Книга фокусируется почти исключительно на объектно-ориентированном коде и призывает к достоинствам SOLID, исключая другие парадигмы программирования. Он фокусируется на коде Java, исключая другие языки программирования, даже другие объектно-ориентированные языки. Есть глава «Запахи и эвристические правила», которая представляет собой не более чем список довольно разумных признаков, которые следует искать в коде. Но есть несколько в основном пустословных глав, где внимание сосредоточено на трудоёмких отработанных примерах рефакторинга Java-кода. Есть целая глава, изучающая внутренние компоненты JUnit (книга написана в 2008 году, так что вы можете себе представить, насколько это актуально сейчас). Общее использование Java в книге очень устарело. Такого рода вещи неизбежны — книги по программированию традиционно быстро устаревают — но даже для того времени предоставленный код плох.
Там есть глава о модульном тестировании. В этой главе много хорошего — хотя и базового — о том, как модульные тесты должны быть быстрыми, независимыми и воспроизводимыми, о том, как модульные тесты позволяют более уверенно производить рефакторинг исходного кода, о том, что модульные тесты должны быть примерно такими же объёмными, как тестируемый код, но гораздо проще для чтения и понимания. Затем автор показывает модульный тест, где, по его словам, слишком много деталей:
и гордо переделывает его:
Это делается как часть общего урока о ценности изобретения нового языка тестирования для конкретной области для ваших тестов. Я был так сбит с толку этим утверждением. Я бы использовал точно такой же код, чтобы продемонстрировать совершенно противоположный совет! Не делайте этого!
*
Автор представляет три закона TDD:
Первый закон. Не пишите код продукта, пока не напишете отказной модульный тест.
Второй закон. Не пишите модульный тест в объёме большем, чем необходимо для отказа. Невозможность компиляции является отказом.
Третий закон. Не пишите код продукта в объёме большем, чем необходимо для прохождения текущего отказного теста.
Эти три закона устанавливают рамки рабочего цикла, длительность которого составляет, вероятно, около 30 секунд. Тесты и код продукта пишутся вместе, а тесты на несколько секунд опережают код продукта.
… но Мартин не обращает внимания на тот факт, что разбиение задач программирования на крошечные тридцатисекундные кусочки в большинстве случаев безумно трудоёмко, часто очевидно бесполезно, а зачастую невозможно.
*
Есть глава «Объекты и структуры данных», где автор приводит такой пример структуры данных:
и такой пример объекта (ну, интерфейс для одного объекта):
Два предыдущих примера показывают, чем объекты отличаются от структур данных. Объекты скрывают свои данные за абстракциями и предоставляют функции, работающие с этими данными. Структуры данных раскрывают свои данные и не имеют осмысленных функций. А теперь ещё раз перечитайте эти определения. Обратите внимание на то, как они дополняют друг друга, фактически являясь противоположностями. Различия могут показаться тривиальными, но они приводят к далеко идущим последствиям.
Да, вы всё правильно поняли. Определение Мартина «структуры данных» расходится с определением, которое используют все остальные! В книге вообще ничего не говорится о чистом кодировании с использованием того, что большинство из нас считает структурами данных. Эта глава намного короче, чем вы ожидаете, и содержит очень мало полезной информации.
*
Я не собираюсь переписывать все остальные мои заметки. У меня их слишком много, и перечислять всё, что я считаю неправильным в этой книге, заняло бы слишком много времени. Я остановлюсь на ещё одном вопиющем примере кода. Это генератор простых чисел из главы 8:
Если таково качество кода, который создаёт этот программист — на досуге, в идеальных условиях, без давления реальной производственной разработки программного обеспечения — тогда зачем вообще обращать внимание на остальную часть его книги? Или другие его книги?
*
Я написал это эссе, потому что постоянно вижу, как люди рекомендуют «Чистый код». Я почувствовал необходимость предложить антирекомендацию.
Первоначально я читал «Чистый код» в группе на работе. Мы читали по главе в неделю в течение тринадцати недель.
Так вот, вы не хотите, чтобы группа к концу каждого сеанса выражала только единодушное согласие. Вы хотите, чтобы книга вызвала какую-то реакцию у читателей, какие-то дополнительные комментарии. И я предполагаю, что в определённой степени это означает, что книга должна либо сказать что-то, с чем вы не согласны, либо не раскрыть тему полностью, как вы считаете должным. Исходя из этого, «Чистый код» оказался годным. У нас состоялись хорошие дискуссии. Мы смогли использовать отдельные главы в качестве отправной точки для более глубокого обсуждения актуальных современных практик. Мы говорили о многом, что не было описано в книге. Мы во многом расходились во мнениях.
Порекомендовал бы я вам эту книгу? Нет. Даже в качестве текста для начинающих, даже со всеми оговорками выше? Нет. Может быть, в 2008 году я рекомендовал бы вам эту книгу? Могу ли я рекомендовать его сейчас как исторический артефакт, образовательный снимок того, как выглядели лучшие практики программирования в далёком 2008 году? Нет, я бы не стал.
*
Итак, главный вопрос заключается в том, какую книгу(и) я бы рекомендовал вместо этого? Я не знаю. Предлагайте в комментариях, если только я их не закрыл.
“Чистый код”: пять ключевых моментов из обязательной к прочтению книги для программистов
Недавно я написал о «Пять книг, которые изменили мой стиль программирования». В комментариях несколько читателей рекомендовали «Чистый код» Роберта С. Мартина. В результате я прочитал книгу и нашел ее достойной углубленного обзора.
О книге
«Чистый код» был опубликован в 2008 году, и в последние годы он неизменно входит в пятерку самых продаваемых книг на Amazon. Автор, которого ласково называют «Дядя Боб», был одним из первых авторов Agile Manifesto и имеет некоторые серьезные полномочия. Книга получила средний рейтинг 4,4 на Goodreads из более чем 13 000 оценок. Достаточно сказать, что это одна из тех книг, которую должен прочитать каждый программист.
В этом обзоре я собираюсь сжать книгу до пяти основных мыслей.
1. Программирование — это прикладное искусство
Я часто думал, что архитектура и строительство — плохие метафоры для программирования. Мы не создаем полный проект, чтобы потом строить (по нему) от самого фундамента до полностью готового здания.
Скорее мы начнем с эскиза, постепенно добавляя детали. Мы пересматриваем, дорабатываем и расширяем — работаем на разных уровнях абстракции, пока программное обеспечение не заработает так, как нам нужно. Программное обеспечение никогда по-настоящему не закончено.
В этом и есть главная суть «Чистого кода». На протяжении всей книги автор проводит идею о том, что программное обеспечение является искусством и сродни живописи.
Но как перейти от простого написания кода к искусству программирования?
По словам Мартина, основными инструментами, которыми мы располагаем, являются непрерывный рефакторинг и разработка на основе тестирования (TDD). Они неотделимы друг от друга, как две стороны медали. Вот некоторые определения.
Рефакторинг — это процесс реструктуризации существующего программного кода без изменения его внешнего поведения.
Разработка через тестирование — это процесс, в котором требования превращаются в конкретные тестовые сценарии, а затем пишется код и проводится успешное тестирование.
Итак, процесс создания программного обеспечения может выглядеть примерно так.
«Это миф, что мы можем создавать системы «с первого раза». Вместо этого, сегодня мы должны разрабатывать «истории», которые актуальны на текущий момент, затем реорганизовывать и расширять систему для реализации новых историй в будущем. Отсюда и возникает гибкость итеративного и инкрементального подхода».
Таким образом, основная идея, представленная Мартином, заключается в том, что чистый код — это то, что возникает в процессе и практике разработки, а не создается за один раз.
2. Функции должны быть короткими!
«Первое правило функций — они должны быть маленькими. Второе правило функций заключается в том, что они должны быть еще меньше».
По словам Мартина, это означает две вещи.
Краткость функции облегчает чтение кода. Это также приводит к тому, что функция выполняет одну задачу и делает это хорошо.
Автор книги делает аналогичное замечание о классах. По идее класс должен отвечать только за одну вещь. Это известно как принцип единственной ответственности (SRP).
Уменьшение размера сущностей — это стратегия «разделяй и властвуй» для того, чтобы сделать код чище. Если у нас есть большой файл с большим количеством длинного и сложного кода, можно разделить этот файл на модули, разделить модули на функции и разделить функции на подфункции, пока логика и намерение не станут ясными.
3. Делай код самодокументирующимся
«Ясный и выразительный код с небольшим количеством комментариев намного лучше загроможденного и сложного кода с большим количеством комментариев».
В разделах, посвященных комментариям, осмысленным именам и форматированию, Мартин обосновывает необходимость самодокументирования кода. Пример этого приведен ниже:
«Чистый код» включает в себя полную главу о присвоении имени, которая, по сути, является разработкой правил Тима Оттингера.
4. Абстракция важна
Согласно «Чистому коду», если мы хотим убедиться, что наши функции выполняют только одну задачу, нам нужно убедиться, что все команды в каждой функции находятся на одном уровне абстракции.
Мартин иллюстрирует это следующим примером из FitNesse:
Это сочетание как минимум двух уровней абстракции. Первая — это высокоуровневая концепция рендеринга тега hr с заданным размером, вторая — это детали фактического синтаксиса низкоуровневого построения тега. Чтобы проиллюстрировать это, код реорганизован более чисто, как показано ниже:
«Разделение уровней абстракции является одной из важнейших функций рефакторинга и одной из самых сложных для достижения успеха».
Теперь я буду уделять этому большее внимание при написании кода в будущем.
5. Чистый код — это тяжелая работа и соблюдение принципов
Я не хотел, чтобы этот обзор был просто списком пунктов и афоризмов, формирующих правила, которые мы можем просто применить, чтобы получить чистый код. Это было бы плохой услугой для книги, так как сам по себе такой догматический подход далек от истины.
Скорее, у меня складывается впечатление, что Мартин уговаривает нас развить сильное чувство личных принципов и постоянно демонстрирует усилия и добросовестность, необходимые для того, чтобы сделать код из грязного чистым. В книге это называется «смыслом кода», то, что требует «дисциплинированного использования множества маленьких приемов, применяемых через тщательно приобретенное чувство чистоты».
«Чистый код пишется не по правилам. Вы не станете мастером программного обеспечения, изучив список приемов. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину».
Лично я, как человек, который страдает от недостатка уверенности, очень оценил этот акцент. Приятно знать, что даже дядя Боб твердо верит, что кодирование — сложное занятие и требует серьезной работы и дисциплины. Чтобы действительно стать профессионалами в написании чистого кода, нам нужно подходить к нашему развитию как программистов итеративно — так же как к написанию кода.
Заключение
Не каждая идея в «Чистом коде» принадлежит дяде Бобу, и он открыто признает это в разных местах книги. Во всяком случае, одна из вещей, которая делает книгу настолько успешной — это квинтэссенция мудрости из различных сообществ программистов, наполненная практическими примерами.
Если для меня и есть один небольшой недочет, так это то, что немного нарушен баланс между главами о деталях и с главами о концепциях более высокого уровня. Глава, посвященная системам, содержит всего 13 страниц, и почти половина посвящена комментариям. Тем не менее, я подозреваю, что автор специально уделил мало внимания системам, чтобы сохранить это обсуждение для его более поздней книги «Чистая архитектура», которая будет в моем списке литературы на 2021 год. Но все же, это одна из лучших книг по программированию.
P.s. Спасибо Zack Shapiro
В ЛАНИТ есть вакансии в области разработки. Те, кто ценит эту книгу, – милости просим к нам.