“Чистый код”: пять ключевых моментов из обязательной к прочтению книги для программистов

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

О книге

«Чистый код» был опубликован в 2008 году, и в последние годы он неизменно входит в пятерку самых продаваемых книг на Amazon. Автор, которого ласково называют «Дядя Боб», был одним из первых авторов Agile Manifesto и имеет некоторые серьезные полномочия. Книга получила средний рейтинг 4,4 на Goodreads из более чем 13 000 оценок. Достаточно сказать, что это одна из тех книг, которую должен прочитать каждый программист.

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

1. Программирование — это прикладное искусство

Я часто думал, что архитектура и строительство — плохие метафоры для программирования. Мы не создаем полный проект, чтобы потом строить (по нему) от самого фундамента до полностью готового здания.

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

В этом и есть главная суть «Чистого кода». На протяжении всей книги автор проводит идею о том, что программное обеспечение является искусством и сродни живописи. 

Но как перейти от простого написания кода к искусству программирования?

По словам Мартина, основными инструментами, которыми мы располагаем, являются непрерывный рефакторинг и разработка на основе тестирования (TDD). Они неотделимы друг от друга, как две стороны медали. Вот некоторые определения.

Рефакторинг — это процесс реструктуризации существующего программного кода без изменения его внешнего поведения.

Разработка через тестирование — это процесс, в котором требования превращаются в конкретные тестовые сценарии, а затем пишется код и проводится успешное тестирование.

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

1. Напишите тесты на еще не разработанную функциональность. Естественно, они не будут работать.
2. Реализуйте функциональность так, чтобы тесты выполнялись успешно. Пусть даже код сначала будет не самым хорошим.
3. Итеративно проводите рефакторинг кода не ломая тесты. С каждым разом ваш код будет становиться все более чистым. 

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

Таким образом, основная идея, представленная Мартином, заключается в том, что чистый код — это то, что возникает в процессе и практике разработки, а не создается за один раз.

2. Функции должны быть короткими!

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

Роберт С. Мартин

По словам Мартина, это означает две вещи.

1. Функции должны быть короткими — не длиннее 20 строк и в большинстве случаев менее 10 строк.
2. Функции должны иметь как можно меньше аргументов, желательно ни одного.

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

Автор книги делает аналогичное замечание о классах. По идее класс должен отвечать только за одну вещь. Это известно как принцип единственной ответственности (SRP).

Уменьшение размера сущностей — это стратегия «разделяй и властвуй» для того, чтобы сделать код чище. Если у нас есть большой файл с большим количеством длинного и сложного кода, можно разделить этот файл на модули, разделить модули на функции и разделить функции на подфункции, пока логика и намерение не станут ясными.

3. Делай код самодокументирующимся

«Ясный и выразительный код с небольшим количеством комментариев намного лучше загроможденного и сложного кода с большим количеством комментариев». 

Роберт С. Мартин

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

После рефакторинга:

Примечания:

• Комментарий удален.
• Условная логика заключена в метод.
• Поскольку используется метод класса, то можно использовать переменные экземпляра и создавать методы вообще без параметров.
• Методу дается содержательное название, что очень облегчает понимание его назначения.

«Чистый код» включает в себя полную главу о присвоении имени, которая, по сути, является разработкой правил Тима Оттингера. 

Вот они.

• Используйте имена, раскрывающие намерения — например, int elapsedTimeInDays, а не int days …
• Используйте произносимые имена — например, Customer, а не DtaRcrd102
• Избегайте кодировок — не используйте префикс m_ и не используйте венгерскую нотацию.
• Выберите одно слово для каждой концепции — не используйте разные наименования типа fetch, retrieve, get для одной и той же операции по сути.

4. Абстракция важна

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

Мартин иллюстрирует это следующим примером из FitNesse:

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

Примечания:

• Функция render () теперь отвечает только за создание тега hr.
• Низкоуровневые детали построения тега теперь делегируются модулю HtmlTag.
• Форматирование размера абстрагировано в отдельную функцию.

По словам Мартина:

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

Теперь я буду уделять этому большее внимание при написании кода в будущем.

5. Чистый код — это тяжелая работа и соблюдение принципов

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

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

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

Роберт С. Мартин

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

Заключение

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

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

P.s. Спасибо Zack Shapiro

В ЛАНИТ есть вакансии в области разработки. Те, кто ценит эту книгу, – милости просим к нам.

• Front-end разработчик
• Разработчик Java (Middle, Senior)
• Руководитель проекта по эксплуатации ПО