Неуместная близость»? «Оргия объектов»? «Принцип KISS»? А мы точно о программировании?

Привет, Хаброжители! Если ваша первая и единственная реакция на эти словосочетания — смех, то вполне вероятно, что от вашего кода «пахнет». Запах кода (code smell) — термин, который был введен разработчиком Кентом Беком и популяризирован Мартином Фаулером. По сути, запах кода — это симптом, признак проблемы; он указывает на такой фрагмент кода, который можно (и нужно) улучшить.

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

Проверенные рецепты на JavaScript, PHP, Python, Java и других языках программирования помогут масштабировать и поддерживать большие системы. В каждом разделе рассматриваются такие фундаментальные понятия, как читаемость кода, связанность, тестируемость, безопасность и расширяемость, а также запахи кода и соответствующие рецепты их устранения.

Принцип YAGNI

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

Фредерик Брукс «Мифический человеко-месяц, или Как создаются программные системы»

Введение

Принцип YAGNI, что расшифровывается как «Вам это не понадобится» (You Ain’t Gonna Need It), советует разработчикам реализовывать только те функции или функциональность, которые действительно необходимы в данный момент, а не добавлять ненужные функции или функционал, который может никогда не пригодиться в будущем. Идея YAGNI заключается в том, чтобы свести к минимуму ненужную сложность и сосредоточиться на наиболее важных задачах.

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

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

Удаление мертвого кода

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

Решение
Не храните код «на всякий случай». Удаляйте его.

Обсуждение
Мертвый код ухудшает обслуживаемость и нарушает принцип KISS (см. рецепт 6.2 «Удаление пустых строк»), поскольку, если код не работает, никто его не поддерживает. Рассмотрим следующий пример с так называемым «золочением» кода:

class Robot {
  walk(){
    //...
  }
  serialize(){
    //...
  }
  persistOnDatabase(database){
    //...
  }
}

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

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

class Robot {
  walk(){
   // ...
   }
}

Тесты могут находить мертвый (неохваченный) код при обеспечении должного покрытия. Но учтите, что его сложно обеспечить при метапрограммировании (см. главу 23 «Метапрограммирование»). При метапрограммировании очень трудно найти ссылки на код. Для простоты удалите мертвый код. Если вы не уверены в коде, временно отключите его с помощью переключателей функций. Удаление кода всегда предпочтительнее, чем добавление, и его всегда можно найти в истории Git (см. рецепт 8.1 «Удаление закомментированного кода»).

Использование кода вместо диаграмм

Проблема
Для документирования работы продукта используются диаграммы.

Решение
Используйте код и тесты в качестве самостоятельной документации.

Обсуждение
Большинство диаграмм фокусируются на структуре (что несущественно), а не на поведении (что существенно). Их следует использовать только для передачи идей. Доверяйте тестам. Они живут и должным образом обслуживаются.
На рис. 12.1 представлен пример диаграммы на унифицированном языке моделирования (Unified Modeling Language, UML). Хотя диаграмма и полезна, но важнее понимать код и тесты, так как диаграмма может устареть в процессе разработки; а тесты не могут лгать, если вы постоянно их выполняете.


Рис. 12.1. Простейшая UML-диаграмма, представляющая библиотеку (LoanTracker — Трекер выдачи книг; BookEdition — Книжное издание; Loan — Выдача; BookItem — Единица хранения; LibraryUser — Пользователь библиотеки; Language — Язык)

Вот упрощенный исполняемый код из диаграммы, моделирующий часть предметной области Library (Библиотека):

final class BookItem {
  function numberOfPages() { }
  function language(): Language { }
  function book(): Book { }
  function edition(): BookEdition { }
  // Выдача книг и просрочка не являются ответственностью единицы хранения
  // BookItem
}

final class LoanTracker {
  function loan(
    BookItem $bookCopy,
    LibraryUser $reader,
    DatePeriod $loanDates) {
    // DatePeriod лучше, чем анемичные $fromDate и $toDate
  }
}

final class LoanTrackerTests extends TestCase {
  // <i>Множество поддерживаемых тестов, показывающих, как на самом деле
  // <i>работает система.
}

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

UML-диаграммы
UML-диаграммы (Unified Modeling Language, унифицированный язык моделирования) — стандартные визуальные представления, описывающие структуру и поведение программной системы или приложения с помощью общего набора символов и обозначений. Они были популярны в 80-х и 90-х годах и тесно связаны с каскадной моделью разработки, при которой проектирование завершается до фактического написания кода, в отличие от Agile-методологий. Многие организации и сегодня используют UML.

С книгой «Рецепты чистого кода» можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Рецепты