боба мартина чистый код
О книге Боба Мартина «Чистый код»
(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))
У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.
Вот и получается, что идеальной аудиторией для этих книг является продвинутый разработчик, окрепший достаточно, чтобы критически оценивать советы «гуру», но при этом не настолько матерый, чтобы эти советы не звучали из разряда «Спасибо, Кэп!».
Хотя, нужно признать, что если в книге «Принципы, паттерны и методики гибкой разработки» спорных советов с моей точки зрения было очень много, то в «Чистом коде» приводится значительно больше разумных и прагматичных советов.
Но поскольку паранойи в книге тоже достаточно, поэтому я хочу начать именно с неоднозначных моментов, а уже потом перейти к радостям.
Спорные и сомнительные моменты
В «Чистом коде» есть несколько откровенно сомнительных моментов. Во-первых, в ней довольно много кода, читать который на страницах книги очень сложно. В 15-й главе рассматривается улучшение парсера командной строки на 60 страницах, 40 из которых – это сплошной код на Java. Главы 16-17 написаны в том же формате, но они короче, поэтому следовать рассуждениям автора проще.
СОМНИТЕЛЬНЫЙ СОВЕТ
Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее. … Из сказанного выше следует, что блоки в командах if, else, while и т.д. должны состоять из одной строки, в которой обычно содержится вызов функции. Это не только делает вмещающую функцию более компактной, но и способствует документированию кода, поскольку вызываемой в блоке функции можно присвоить удобное содержательное имя.
Некоторые главы откровенно слабые. Мне вообще не понятна цель главы 13 о параллелизме, в которой даются лишь общие сведения о проблемах многопоточности, а затем в приложении А разбираются те же самые темы, но уже более детально и с необходимыми примерами.
Но больше всего меня смущает неоднозначное отношение автора к состоянию и побочным эффектам.
Побочные эффекты суть ложь. Ваша функция обещает делать что-то одно, но делает что-то другое, скрытое от пользователя. Иногда она вносит неожиданные изменения в переменные своего класса – скажем, присваивает им значения параметров, переданных функции…
Несмотря на этот совет, автор во многих примерах использует код с побочными эффектами и отговаривает всеми силами использовать аргументы, используя вместо этого состояние объекта:
СОМНИТЕЛЬНЫЙ СОВЕТ
… Аргументы создают массу проблем с точки зрения тестирования. Только представьте, как трудно составить все тестовые сценарии, проверяющие правильность работы кода со всеми комбинациями аргументов.
В чем разница с точки зрения тестирования между статическим методом с четырьмя аргументами и экземплярного метода объекта с четырьмя полями? Количество граничных условий в обоих случаях одно и тоже; просто в первом случае мы все входные данные протаскиваем явно, а во втором случае – неявно через this.
Стилю кодирования в книге уделено много внимания, при этом большинство советов вполне разумными. Но встречаются и очень неоднозначные:
СОМНИТЕЛЬНЫЙ СОВЕТ
Стандарт кодирования определяет, где объявляются переменные экземпляров; как именуются классы, методы и переменные; как располагаются фигурные скобки и т.д. Документ с явных описанием этих правил не нужен – сам код служит примером оформления.
Перевод
Перевод, мягко говоря, не порадовал. Иногда он «радовал» настолько, что приходилось лезть в оригинал, чтобы понять, о чем идет речь:
ЦИТАТА
Когда у вас появился полный набор тестов, можно заняться чисткой кода и классов.
Для этого код подвергается последовательной переработке (рефакторингу). Мы добавляем несколько строк кода, делаем паузу и анализируем новую архитектуру.
WTF! Как добавление двух строк может повлиять на архитектуру. Есть два варианта: либо мы имеем дело с очень длинными строками, или же авторы здесь говорят не об архитектуре, а о чем-то ином, например, о дизайне! Вся глава 12 (из которой взята эта цитата) полностью испорчена тем, что термин “design” переведен в ней как «архитектура», что делает многие советы автора спорными.
Как обычно, переводчики не потрудились оставить оригинальные термины, так что приходилось догадываться, что же имеется ввиду под терминами «логическая привязка» или «многопоточность» (оказывается, что это high coupling и concurrency, соответственно).
Поскольку содержимое книги относительно простое, то переводчикам удалось лишь «подпортить» впечатление, но не запороть ее полностью.
Дельные советы
На самом деле, все не настолько плохо и «дядюшка» Боб сотоварищи дают много хороших советов. Вот некоторые из них:
Об именовании
Не используйте имена, передающие информацию о реализации. Имена должны отражать уровень абстракции, на котором работает класс или функция.
О понятности кода
Легко писать код, понятный для нас самих, потому что в момент его написания мы глубоко понимаем решаемую проблему. У других программистов, которые будут заниматься сопровождением этого кода, такого понимания не будет.
О длине и выразительности имен
Длина имени должна быть связана с длиной его области видимости. Переменным с крошечной областью видимости можно присваивать очень короткие имена, но у переменных с большей областью видимости имена должны быть длинными. … Таки образом, чем длиннее область видимости, тем более длинным и точным должно быть ее имя.
О содержимом функций
Все операторы в функции должны находиться на одном уровне абстракции, который должен быть на один уровень ниже операции, описываемой именем функции.
Совет кажется простым, но он очень ценен. Код должен читаться, как хорошая проза, а для этого просто необходимо, чтобы функция содержала операторы одного уровня.
Юнит-тесты в качестве инструмента изучения библиотек
Изучение чужого кода – непростая задача. Интеграция чужого кода тоже сложна. Одновременное решение обоих задач создает двойственные сложности. А что, если пойти по другому пути? Вместо того, чтобы экспериментировать и опробовать новую библиотеку в коде продукта, можно написать тесты. Проверяющие наше понимание стороннего кода. Джим Ньюкирк (JimNewkirk) называет такие тесты «учебными тестами».
Этому совету я следую давно и использую юнит-тесты для изучения новых инструментов и библиотек. Это позволяет лучше разобраться с библиотекой и легко возвращаться к примерам использования, поскольку они всегда под рукой.
Очень повеселил один совет. Давайте так: что вам говорит магическая константа 5280? Ничего? Странно, по словам автора, это одно из значений, которое можно спокойно «хардкодить»!
Некоторые числа так легко узнаются, что их не обязательно скрывать за именованными константами – при условии, что они используются в сочетании с ясным кодом. … Число 5280 – количество футов в миле – настолько хорошо известно и уникально, что читатель сразу узнает его, даже если оно будет располагаться вне какого-либо контекста.
Качество книги можно косвенно оценить по количеству интересных цитат и количеству блог-постов, появившихся в процессе чтения. И если в процессе чтения «Принципов, паттернов и методик» появились критические статьи типа «Контракты, состояние и юнит-тесты», то в результате «Чистого кода» появились «Пять принципов чистых тестов» и «Лучшая метрика для определения качества кода».
Достоинства: приличное количество приличных советов
Недостатки: часть советов весьма спорны; иногда советы непоследовательны; перевод хромает на обе ноги.
«Чистый код» Роберт Мартин. Конспект. Как писать понятный и красивый код?
Я решил написать конспект книги, которая всем известна, а сам автор называет ее «Школой учителей Чистого кода». Пристальный взгляд Мартина как бы говорит:
«Я тебя насквозь вижу. Ты опять не следуешь принципам чистого кода?»
Глава 1. Чистый код
Что же такое этот самый чистый код по версии Мартина в нескольких словах? Это код без дублирования, с минимальным количеством сущностей, удобный для чтения, простой. В качестве девиза можно было бы выбрать: «Ясность превыше всего!».
Глава 2. Содержательные имена
Имена должны передавать намерения программиста
Имя переменной, функции или класса должно сообщить, почему эта переменная существует, что она делает и как используется. Если имя требует дополнительных комментариев, значит, оно не передает намерений программиста. Лучше написать, что именно измеряется и в каких именно единицах.
Пример хорошего названия переменной: daysSinceCreation;
Цель: убрать неочевидность.
Избегайте дезинформации
Не используйте слова со скрытыми значениями, отличными от предполагаемого. Остерегайтесь малозаметных различий в именах. Например, XYZControllerForEfficientHandlingOfStrings и XYZControllerForEfficientStorageOfStrings.
По-настоящему устрашающие примеры дезинформирующих имен встречаются при использовании строчной «L» и прописной «O» в именах переменных, особенно в комбинациях. Естественно, проблемы возникают из-за того, что эти буквы почти не отличаются от констант «1» и «0» соответственно.
Используйте осмысленные различия
Если имена различаются, то они должны обозначать разные понятия.
«Числовые ряды» вида (a1, a2,… aN) являются противоположностью сознательного присваивания имен. Они не несут информации и не дают представления о намерениях автора.
Неинформативные слова избыточны. Слово variable никогда не должно встречаться в именах переменных. Слово table никогда не должно встречаться в именах таблиц. Чем имя NameString лучше Name? Разве имя может быть, скажем, вещественным числом?
Используйте удобопроизносимые имена: generationTimestamp намного лучше genymdhms.
Выбирайте имена, удобные для поиска
Однобуквенные имена могут использоваться только для локальных переменных в коротких методах.
Избегайте схем кодирования имен
Как правило, кодированные имена плохо произносятся и в них легко сделать опечатку.
Интерфейсы и реализации
Я (автор книги) предпочитаю оставлять имена интерфейсов без префиксов. Префикс I, столь распространенный в старом коде, в лучшем случае отвлекает, а в худшем — передает лишнюю информацию. Я не собираюсь сообщать своим пользователям, что они имеют дело с интерфейсом.
Имена классов
Имена классов и объектов должны представлять собой существительные и их комбинации: Customer, WikiPage, Account и AddressParser. Старайтесь не использовать в именах классов такие слова, как Manager, Processor, Data или Info. Имя класса не должно быть глаголом.
Имена методов
Имена методов представляют собой глаголы или глагольные словосочетания: postPayment, deletePage, save и т. д. Методы чтения/записи и предикаты образуются из значения и префикса get, set и is согласно стандарту javabean.
Воздержитесь от каламбуров
Задача автора — сделать свой код как можно более понятным. Код должен восприниматься с первого взгляда, не требуя тщательного изучения. Ориентируйтесь на модель популярной литературы, в которой сам автор должен доступно выразить свои мысли.
Добавьте содержательный контекст
Контекст можно добавить при помощи префиксов: addrFirstName, addrLastName, addrState и т. д. По крайней мере читатель кода поймет, что переменные являются частью более крупной структуры. Конечно, правильнее было бы создать класс с именем Address, чтобы даже компилятор знал, что переменные являются частью чего-то большего.
Переменные с неясным контекстом:
Функция длинновата, а переменные используются на всем ее протяжении. Чтобы разделить функцию на меньшие смысловые фрагменты, следует создать класс GuessStatisticsMessage и сделать три переменные полями этого класса. Тем самым мы предоставим очевидный контекст для трех переменных — теперь абсолютно очевидно, что эти переменные являются частью GuessStatisticsMessage.
Переменные с контекстом:
Не добавляйте избыточный контекст
Короткие имена обычно лучше длинных, если только их смысл понятен читателю кода. Не включайте в имя больше контекста, чем необходимо.
Глава 3. Функции
Компактность!
Первое правило: функции должны быть компактными.
Второе правило: функции должны быть еще компактнее.
Мой практический опыт научил меня (ценой многих проб и ошибок), что функции должны быть очень маленькими. Желательно, чтобы длина функции не превышала 20 строк.
Правило одной операции
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна. Если функция выполняет только те действия, которые находятся на одном уровне под объявленным именем функции, то эта функция выполняет одну операцию.
Секции в функциях
Функцию, выполняющую только одну операцию, невозможно осмысленно разделить на секции.
Один уровень абстракции на функцию
Чтобы убедиться в том, что функция выполняет «только одну операцию», необходимо проверить, что все команды функции находятся на одном уровне абстракции.
Смешение уровней абстракции внутри функции всегда создает путаницу.
Чтение кода сверху вниз: правило понижения
Код должен читаться как рассказ — сверху вниз.
За каждой функцией должны следовать функции следующего уровня абстракции. Это позволяет читать код, последовательно спускаясь по уровням абстракции в ходе чтения списка функций. Я называю такой подход «правилом понижения».
Команды switch
Написать компактную команду switch довольно сложно. Даже команда switch всего с двумя условиями занимает больше места, чем в моем представлении должен занимать один блок или функция. Также трудно создать команду switch, которая делает что-то одно — по своей природе команды switch всегда выполняют N операций. К сожалению, обойтись без команд switch удается не всегда, но по крайней мере мы можем позаботиться о том, чтобы эти команды были скрыты в низкоуровневом классе и не дублировались в коде. И конечно, в этом нам может помочь полиморфизм.
В примере представлена всего одна операция, зависящая от типа работника.
Эта функция имеет ряд недостатков. Во-первых, она велика, а при добавлении новых типов работников она будет разрастаться. Во-вторых, она совершенно очевидно выполняет более одной операции. В-третьих, она нарушает принцип единой ответственности (Single responsibility principle), так как у нее существует несколько возможных причин изменения.
В-четвертых, она нарушает принцип открытости/закрытости (The Open Closed Principle), потому что код функции должен изменяться при каждом добавлении новых типов.
Но, пожалуй, самый серьезный недостаток заключается в том, что программа может содержать неограниченное количество других функций с аналогичной структурой, например:
isPayday(Employee e, Date date)
deliverPay(Employee e, Money pay)
Все эти функции будут иметь все ту же ущербную структуру. Решение проблемы заключается в том, чтобы похоронить команду switch в фундаменте абстрактной фабрики и никому ее не показывать. Фабрика использует команду switch для создания соответствующих экземпляров потомков Employee, а вызовы функций calculatePay, isPayDay, deliverPay и т. д. проходят полиморфную передачу через интерфейс Employee.
Мое общее правило в отношении команд switch гласит, что эти команды допустимы, если они встречаются в программе однократно, используются для создания полиморфных объектов и скрываются за отношениями наследования, чтобы оставаться невидимыми для остальных частей системы. Конечно, правил без исключений не бывает и в некоторых ситуациях приходится нарушать одно или несколько условий этого правила.
Используйте содержательные имена
Половина усилий по реализации этого принципа сводится к выбору хороших имен для компактных функций, выполняющих одну операцию. Чем меньше и специализированнее функция, тем проще выбрать для нее содержательное имя.
Не бойтесь использовать длинные имена Длинное содержательное имя лучше короткого невразумительного. Выберите схему, которая позволяет легко прочитать слова в имени функции, а затем составьте из этих слов имя, которое описывает назначение функции.
Аргументы функций
В идеальном случае количество аргументов функции равно нулю. Далее следуют функции с одним аргументом (унарные) и с двумя аргументами (бинарные). Функций с тремя аргументами (тернарных) следует по возможности избегать.
Выходные аргументы запутывают ситуацию еще быстрее, чем входные. Как правило, никто не ожидает, что функция будет возвращать информацию в аргументах. Если уж обойтись без аргументов никак не удается, постарайтесь хотя бы ограничиться одним входным аргументом.
Преобразования, в которых вместо возвращаемого значения используется выходной аргумент, сбивают читателя с толку. Если функция преобразует свой входной аргумент, то результат
должен передаваться в возвращаемом значении.
Аргументы-флаги
Аргументы-флаги уродливы. Передача логического значения функции — воистину ужасная привычка. Она немедленно усложняет сигнатуру метода, громко провозглашая, что функция выполняет более одной операции. При истинном значении флага выполняется одна операция, а при ложном — другая.
Бинарные функции
Функцию с двумя аргументами понять сложнее, чем унарную функцию. Конечно, в некоторых ситуациях форма с двумя аргументами оказывается уместной. Например, вызов Point p = new Point(0,0); абсолютно разумен. Однако два аргумента в нашем случае являются упорядоченными компонентами одного значения.
Объекты как аргументы
Если функция должна получать более двух или трех аргументов, весьма вероятно, что некоторые из этих аргументов стоит упаковать в отдельном классе. Рассмотрим следующие два объявления:
Если переменные передаются совместно как единое целое (как переменные x и y в этом примере), то, скорее всего, вместе они образуют концепцию, заслуживающую собственного имени.
Глаголы и ключевые слова
Выбор хорошего имени для функции способен в значительной мере объяснить смысл функции, а также порядок и смысл ее аргументов. В унарных функциях сама функция и ее аргумент должны образовывать естественную пару «глагол/существительное». Например, вызов вида write(name) смотрится весьма информативно.
Читатель понимает, что чем бы ни было «имя» (name), оно куда-то «записывается» (write). Еще лучше запись writeField(name), которая сообщает, что «имя» записывается в «поле» какой-то структуры.
Последняя запись является примером использования ключевых слов в имени функции. В этой форме имена аргументов кодируются в имени функции. Например, assertEquals можно записать в виде assertExpectedEqualsActual(expected, actual). Это в значительной мере решает проблему запоминания порядка аргументов.
Разделение команд и запросов
Функция должна что-то делать или отвечать на какой-то вопрос, но не одновременно. Либо функция изменяет состояние объекта, либо возвращает информацию об этом объекте. Совмещение двух операций часто создает путаницу.
Изолируйте блоки try/catch
Блоки try/catch выглядят весьма уродливо. Они запутывают структуру кода и смешивают обработку ошибок с нормальной обработкой. По этой причине тела блоков try и catch рекомендуется выделять в отдельные функции.
Обработка ошибок как одна операция
Функции должны выполнять одну операцию. Обработка ошибок — это одна операция. Значит, функция, обрабатывающая ошибки, ничего другого делать не должна. Отсюда следует, что если в функции присутствует ключевое слово try, то оно должно быть первым словом в функции, а после блоков catch/finally ничего другого быть не должно.
“Чистый код”: пять ключевых моментов из обязательной к прочтению книги для программистов
Недавно я написал о «Пять книг, которые изменили мой стиль программирования». В комментариях несколько читателей рекомендовали «Чистый код» Роберта С. Мартина. В результате я прочитал книгу и нашел ее достойной углубленного обзора.
О книге
«Чистый код» был опубликован в 2008 году, и в последние годы он неизменно входит в пятерку самых продаваемых книг на Amazon. Автор, которого ласково называют «Дядя Боб», был одним из первых авторов Agile Manifesto и имеет некоторые серьезные полномочия. Книга получила средний рейтинг 4,4 на Goodreads из более чем 13 000 оценок. Достаточно сказать, что это одна из тех книг, которую должен прочитать каждый программист.
В этом обзоре я собираюсь сжать книгу до пяти основных мыслей.
1. Программирование — это прикладное искусство
Я часто думал, что архитектура и строительство — плохие метафоры для программирования. Мы не создаем полный проект, чтобы потом строить (по нему) от самого фундамента до полностью готового здания.
Скорее мы начнем с эскиза, постепенно добавляя детали. Мы пересматриваем, дорабатываем и расширяем — работаем на разных уровнях абстракции, пока программное обеспечение не заработает так, как нам нужно. Программное обеспечение никогда по-настоящему не закончено.
В этом и есть главная суть «Чистого кода». На протяжении всей книги автор проводит идею о том, что программное обеспечение является искусством и сродни живописи.
Но как перейти от простого написания кода к искусству программирования?
По словам Мартина, основными инструментами, которыми мы располагаем, являются непрерывный рефакторинг и разработка на основе тестирования (TDD). Они неотделимы друг от друга, как две стороны медали. Вот некоторые определения.
Рефакторинг — это процесс реструктуризации существующего программного кода без изменения его внешнего поведения.
Разработка через тестирование — это процесс, в котором требования превращаются в конкретные тестовые сценарии, а затем пишется код и проводится успешное тестирование.
Итак, процесс создания программного обеспечения может выглядеть примерно так.
«Это миф, что мы можем создавать системы «с первого раза». Вместо этого, сегодня мы должны разрабатывать «истории», которые актуальны на текущий момент, затем реорганизовывать и расширять систему для реализации новых историй в будущем. Отсюда и возникает гибкость итеративного и инкрементального подхода».
Таким образом, основная идея, представленная Мартином, заключается в том, что чистый код — это то, что возникает в процессе и практике разработки, а не создается за один раз.
2. Функции должны быть короткими!
«Первое правило функций — они должны быть маленькими. Второе правило функций заключается в том, что они должны быть еще меньше».
По словам Мартина, это означает две вещи.
Краткость функции облегчает чтение кода. Это также приводит к тому, что функция выполняет одну задачу и делает это хорошо.
Автор книги делает аналогичное замечание о классах. По идее класс должен отвечать только за одну вещь. Это известно как принцип единственной ответственности (SRP).
Уменьшение размера сущностей — это стратегия «разделяй и властвуй» для того, чтобы сделать код чище. Если у нас есть большой файл с большим количеством длинного и сложного кода, можно разделить этот файл на модули, разделить модули на функции и разделить функции на подфункции, пока логика и намерение не станут ясными.
3. Делай код самодокументирующимся
«Ясный и выразительный код с небольшим количеством комментариев намного лучше загроможденного и сложного кода с большим количеством комментариев».
В разделах, посвященных комментариям, осмысленным именам и форматированию, Мартин обосновывает необходимость самодокументирования кода. Пример этого приведен ниже:
«Чистый код» включает в себя полную главу о присвоении имени, которая, по сути, является разработкой правил Тима Оттингера.
4. Абстракция важна
Согласно «Чистому коду», если мы хотим убедиться, что наши функции выполняют только одну задачу, нам нужно убедиться, что все команды в каждой функции находятся на одном уровне абстракции.
Мартин иллюстрирует это следующим примером из FitNesse:
Это сочетание как минимум двух уровней абстракции. Первая — это высокоуровневая концепция рендеринга тега hr с заданным размером, вторая — это детали фактического синтаксиса низкоуровневого построения тега. Чтобы проиллюстрировать это, код реорганизован более чисто, как показано ниже:
«Разделение уровней абстракции является одной из важнейших функций рефакторинга и одной из самых сложных для достижения успеха».
Теперь я буду уделять этому большее внимание при написании кода в будущем.
5. Чистый код — это тяжелая работа и соблюдение принципов
Я не хотел, чтобы этот обзор был просто списком пунктов и афоризмов, формирующих правила, которые мы можем просто применить, чтобы получить чистый код. Это было бы плохой услугой для книги, так как сам по себе такой догматический подход далек от истины.
Скорее, у меня складывается впечатление, что Мартин уговаривает нас развить сильное чувство личных принципов и постоянно демонстрирует усилия и добросовестность, необходимые для того, чтобы сделать код из грязного чистым. В книге это называется «смыслом кода», то, что требует «дисциплинированного использования множества маленьких приемов, применяемых через тщательно приобретенное чувство чистоты».
«Чистый код пишется не по правилам. Вы не станете мастером программного обеспечения, изучив список приемов. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину».
Лично я, как человек, который страдает от недостатка уверенности, очень оценил этот акцент. Приятно знать, что даже дядя Боб твердо верит, что кодирование — сложное занятие и требует серьезной работы и дисциплины. Чтобы действительно стать профессионалами в написании чистого кода, нам нужно подходить к нашему развитию как программистов итеративно — так же как к написанию кода.
Заключение
Не каждая идея в «Чистом коде» принадлежит дяде Бобу, и он открыто признает это в разных местах книги. Во всяком случае, одна из вещей, которая делает книгу настолько успешной — это квинтэссенция мудрости из различных сообществ программистов, наполненная практическими примерами.
Если для меня и есть один небольшой недочет, так это то, что немного нарушен баланс между главами о деталях и с главами о концепциях более высокого уровня. Глава, посвященная системам, содержит всего 13 страниц, и почти половина посвящена комментариям. Тем не менее, я подозреваю, что автор специально уделил мало внимания системам, чтобы сохранить это обсуждение для его более поздней книги «Чистая архитектура», которая будет в моем списке литературы на 2021 год. Но все же, это одна из лучших книг по программированию.
P.s. Спасибо Zack Shapiro
В ЛАНИТ есть вакансии в области разработки. Те, кто ценит эту книгу, – милости просим к нам.