Эта история о том, как писать лучший (более чистый/более удобный) код на Ruby.
Это вдохновлено Правилами Санди Мец для разработчиков — Thoughtbot и Практическим объектно-ориентированным дизайном в Ruby. Я рекомендую вам прочитать их. :)
Оглавление
- Одна из самых важных вещей при написании кода
- Конкретный простой пример для написания лучшего кода на Ruby
- Другие советы по написанию более чистого кода
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 дает вам большую силу. Пожалуйста, используйте его :)