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

Введение

Об авторе, Роберте С. Мартине, он считается одним из старейших инженеров в индустрии программного обеспечения. Имеет многолетний опыт работы в сфере программного обеспечения на различных позициях, от разработчика, менеджера, до генерального директора. Он наиболее известен написанием руководств по программному обеспечению, в которых описываются принципы программного обеспечения, шаблоны программного обеспечения и методы работы с программным обеспечением. Он опубликовал множество книг, таких как «Чистый код», «Чистый код», «Чистая архитектура» и т. д. «Чистый код» — одна из книг по программному обеспечению, которую рекомендуется читать многим инженерам-программистам в мире.
Автор сказал, что «Со временем беспорядок становится таким большим, таким глубоким и таким высоким, что они не могут его убрать». Нам нужно много читать, думать, прежде чем писать код. Мы не должны писать код в спешке. Поспешное написание паршивого кода приведет к тому, что позже вы потратите больше времени на поддержку. Чистый код фокусируется на технических аспектах: обучение программиста тому, как организовать код и писать чистый код. Вы не будете изучать какие-либо новые фреймворки, но это даст вам фундаментальный набор правил стиля кодирования. Стоит прочитать книгу.

Содержание книги

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

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

Бьерн Страуструп (изобретатель C++): Elegant, Efficiency.
Грэди Буч (автор объектно-ориентированного анализа): Readability.
Дэвид Томас (основатель OTI): Easy for other people to enhance it.
Уорн Каннингем (изобретатель) из Wiki): Make the language look simple.
Я: To be able to remember what you write in a month ago.

Критерии оценки чистого кода

Общий

  • Не повторяйтесь: дублирование может быть корнем всех зол в программном обеспечении. Многие принципы и практики были созданы с целью контролировать или устранять его. Иногда мы можем использовать шаблон Template method для удаления дублирования более высокого уровня.

Именование переменных, методов, аргументов, классов, файлов

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

Комментарии

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

Функции

  • Функции должны быть небольшими: менее 100 строк. Это делает функцию более легкой для чтения и понимания.
  • Функции должны делать только одно.
  • Функции должны иметь небольшое количество аргументов (менее 4 аргументов).
  • Не передавайте логические значения в качестве аргументов.
  • Функции, которые никогда не вызываются, должны быть удалены.
  • Отделите обработку ошибок от обычной обработки.
  • Инкапсулируйте условные операторы.

Обработка ошибок

  • Обработка ошибок важна, но если она затемняет логику, это неправильно.
  • Не возвращайте Null: рассмотрите возможность создания исключения или возврата объекта SPECIAL CASE. Если вы кодируете таким образом, вы минимизируете вероятность NullPointerException, и ваш код будет чище.
  • Не передавайте Null в качестве аргументов.

Границы

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

Классы

  • Класс должен быть небольшим: мы измеряем его обязанностями. (Мы знаем это как принцип SRP)
  • Код следует размещать там, где его, естественно, ожидает читатель. (Куда должна идти PIconstant? Должна ли она быть в классе Match? Или, может быть, в классе Circle?).
  • Будьте внимательны при создании статических методов. Статический метод не работает с одним экземпляром. Все данные, которые использует метод, поступают из его аргументов, а не из каких-либо экземпляров этого класса. Кроме того, убедитесь, что вы не хотите, чтобы он вел себя полиморфно.

параллелизм

  • Есть несколько основных определений, которые мы должны знать, когда говорим о параллелизме и потоках: связанные ресурсы, взаимное исключение, голодание, взаимоблокировка и динамическая блокировка.
  • Параллелизм не всегда улучшает производительность. Иногда это влечет за собой некоторые накладные расходы, и возникающие из-за этого ошибки обычно не повторяются.
  • Ограничьте доступ к данным, которые совместно используются более чем двумя потоками. Используйте копии данных, если есть возможность.
  • Старайтесь, чтобы синхронизируемые разделы были как можно меньше, потому что блокировки создают задержки и увеличивают нагрузку. Они дорогие.
  • Многопоточный код ведет себя по-разному в разных средах: запускайте тесты в каждой потенциальной среде развертывания.

Что я люблю

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

Что мне не нравится

  • В качестве примеров в книге автор использует код Java. Иногда, чтобы понять идеи автора, нам нужно узнать больше о концепциях Java. (Среда Spring, среда JUnit, тип исключений и т. д.)
  • Идеи автора дублируются в некоторых главах.

В целом

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