Эта история о том, как писать лучший (более чистый/более удобный) код на Ruby.

Это вдохновлено Правилами Санди Мец для разработчиков — Thoughtbot и Практическим объектно-ориентированным дизайном в Ruby. Я рекомендую вам прочитать их. :)

Оглавление

  1. Одна из самых важных вещей при написании кода
  2. Конкретный простой пример для написания лучшего кода на Ruby
  3. Другие советы по написанию более чистого кода

1. Одна из самых важных вещей при написании кода

Хотя существует множество теорий, СУХИХ / ТВЕРДЫХ / шаблонов проектирования и т. д., в мире одна из самых важных вещей — это Separation by interest принцип единой ответственности, на мой взгляд.

Есть несколько причин.

  • Нам нужно реализовать функцию, учитывая изменения спецификации.
  • Если мы реализуем функцию в одном методе, и происходят изменения спецификации…
  • Простой код поможет вам легко понять, что он на самом деле делает.
  • легко читать, понимать и модифицировать.

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

Чтобы реализовать функции с гибким кодом, ключом является Separation by interest.

2. Конкретный простой пример для написания лучшего кода на Ruby

Позвольте мне объяснить детали Separation by interest на простом примере ниже.

Класс PaymentReport хочет рассчитать комиссию за платеж в течение определенного периода.

Этот код, на мой взгляд, плохой, потому что total_payment_within_period обрабатывает много вещей, несмотря на имя метода.

Давайте разделим логику, следуя Separation by interest. Нам не нужно делать все в одном методе.

Вау!

Мы просто перенесли логику в новые методы, но теперь в методе total_payment_within_period всего 2 строки! Теперь код внутри метода стал более понятным.

Но у нас все еще есть проблема.

Логика IF в методе filter_payed_customers сложна для понимания. И, похоже, здесь не определяется эта конкретная логика, потому что условия if зависят от объекта payment_statement, а не объекта payment_report.

Так что давайте перенесем логику туда, где она должна быть.

Итак, теперь мы просто вызываем метод экземпляра countable? в методе filter_payed_customers, вместо того, чтобы определять логику деталей.

Я хотел бы еще немного улучшить, используя удобные методы Ruby.

Теперь код стал чище и понятнее! Каждый метод концентрируется на чем-то одном, поэтому легче обрабатывать изменения спецификации с меньшим негативным воздействием на существующую логику.

SRP дает вам большую силу. Пожалуйста, используйте его :)