Do Not Repeat Your Self: Как Правильно Использовать Принцип Dry В Разработке По Хабр

Может оказаться так, что для этого нужно будет чуть поправить исходную функцию, зато мы не будем дублировать код и сохраним единую логику работы. DRY — сокращение от Don’t repeat your self, что переводится с английского как «Не повторяйся». Этот принцип означает, что программист должен избегать повторов в реализации кода и в логике работы, а вместо этого использовать то, что есть. Принцип DRY не рекомендует просто слепо объединять одинаковые блоки кода. Он призывает к тому, чтобы каждый фрагмент знания имел только одно, четкое и авторитетное представление в системе.

Начнём с элементарного сокращения, которое наверняка попадалось вам много раз. Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. Это аббревиатура от фразы You aren’t gonna need it — «тебе это не понадобится». Простой принцип, который означает, что не нужно писать код из серии «в будущем нам это пригодится». Интерфейс в программировании — это то, что умеет делать функция, класс или объект.

Код, написанный по принципу DRY, создаётся с помощью конвертации данных и генераторов кода, которые позволяют разработчику ПО избежать операций вырезания, копирования и вставки. Обычно код, написанный по этому принципу, позволяет легче управлять большими информационными системами. Такие инструменты, как XDoclet (англ.) и XSLT являются примерами техник программирования DRY. Примерами систем, которые требуют дублирования информации, являются Enterprise Java Beans версии 2, которая требует не только дублирования в коде Java, но и в файлах конфигурации. DRY – это принцип разработки программного обеспечения, призванный минимизировать дублирование информации в коде.

Stable — Принципы Объектно‑ориентированного Программирования

Классы находятся в отдельных файлах в репозитории (я просто поместил их в один блок кода для удобства просмотра). Оба класса публикуют событие в Kafka в совершенно разных частях приложения и в разных случаях использования. Думаю, лучше всего объяснить правильный и неправильный подходы на конкретном примере.

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

Я ввел контексты для обоих событий, и инструмент анализа кода выделил это дублирование как проблему (так же поступил и мой коллега в запросе о включении изменений). Каждое событие имеет основной раздел (например, order_placed) и опционально список контекстов для предоставления дополнительной https://deveducation.com/ информации, которая часто относится к нескольким событиям. Данные о местоположении пользователя, не хранятся в проекте вместе с данными о товарах и заказах, но здесь это не имеет значения. Однако в последние годы этот принцип используется слишком своевольно, причем в ущерб коду.

• Я ввел контексты для обоих событий, и инструмент анализа кода выделил это дублирование как проблему (так же поступил и мой коллега в запросе о включении изменений).
• А если в нескольких местах определена одна и та же функция, то её можно вынести в общий модуль.
• DRY – это принцип разработки программного обеспечения, призванный минимизировать дублирование информации в коде.
• Смотрите, как сразу все стало аккуратно, файл выглядит более простым и занимает визуально меньше места.
• Это аббревиатура от фразы You aren’t gonna want it — «тебе это не понадобится».
• Если отойти от программирования, можно вспомнить и другие аббревиатуры, которые часто используются в нашей отрасли.

Любое изменение в логике работы повторяющегося кода придется дублировать в остальных местах. Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё дважды)[5] или «We enjoy typing» (рус. Нам нравится печатать). В проектировании DRY тоже имеет место — доступ к конкретному функционалу должен быть доступен в одном месте, унифицирован и сгруппирован по какому‑либо принципу, а не «разбросан» по системе в произвольных вариациях. Этот подход пересекается с принципом единственной ответственности из пяти принципов SOLID, сформулированных Робертом Мартином. Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта, простоты внесения изменений и качественного тестирования.

На практике это значит, что повторяющиеся части кода должны объединяться в общие функции или модули. Код, написанный по принципу DRY, создаётся с помощью конвертации данных и генераторов кода, которые позволяют разработчику ПО избежать операций вырезания, копирования и вставки[источник не указан 510 дней]. Такие инструменты, как XDoclet[англ.] и XSLT являются примерами техник программирования DRY. DRY – это аббревиатура английской фразы don’t repeat yourself, которая переводится как “не повторяйся”. Аббревиатура DRY (или “не повторяйся”) в мире программистов означает целый принцип (подход) к написанию программного кода, который считается базовым для всех начинающих программистов. Это неоптимально, поскольку обновление бизнес-правила  —  по истечении срока действия заказа через 7 дней  —  потребует изменений в нескольких местах.

Stable

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

Где 0– скорость объекта в инерциальной системе отсчета, а с – скорость света.

Зачем Вообще Нужны Эти Принципы?

Сразу же бросается в глаза, что мы здесь явно имеем дело с принципом ООП, который помогает правильно применять наследование, когда это необходимо, и использовать альтернативные варианты, когда наследование не нужно. Потому что, если понадобится добавить ещё один город, придётся открывать сам файл и вносить изменения в массив knownCities. Разрабатываем и сопровождаем комплексные системы, устойчивые к отказу оборудования, отдельных сервисов и целых подсистем. MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем. Но в случае наноробота, эта формула бесполезна, так как его скорость подчиняется принципам квантовой механики, определяется вероятностно и расчитывается используя принципиально другие формулы.

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

Принцип Единственного Источника Истины (single Source Of Truth)

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

Так что, как бы странно он для вас ни звучал, помнить о нём при создании классов всё-таки стоит. Если же нужно более сложное поведение, придётся объединять вводы и выводы нескольких функций и делать композицию. Он говорит о том, что каждая ваша функция должна выполнять только одну задачу. Получается, что это пять разных принципов в одном (англ. stable — твёрдый, плотный, прочный). Слишком простой код или простая архитектура могут оказаться неэффективными, и тогда в логику придётся добавлять чуть больше сложности. Но всё равно надо каждый раз себя спрашивать, соблюдается ли принцип KISS.

Применение Принципа Dry

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

Dry

А если в нескольких местах определена одна и та же функция, то её можно вынести в общий модуль. Ну и, наконец, если вы часто используете один и тот же модуль, вероятно, из него можно сделать библиотеку. Принцип “Не повторяйся” (Don’t Repeat Yourself, или DRY), то есть избегай дублирования кода, принципы разработки по часто относят к обязательным практикам в программировании. Однако в реальности часто можно увидеть, как в общем коде оказываются концептуально разные блоки, которые похожи только по внешним параметрам. Это неминуемо приводит к ухудшению кода и появлению “костылей”, без которых он не работает.

Учитывая, что наш стартап находится на ранней стадии развития и высокая точность расчетов нам не требуется, формула для расчета скорости космического корабля и наноробота совпадает. Поэтому кажется логичным выделить функцию расчета скорости в общий модуль. Чтобы облегчить себе и другим разработчикам жизнь, а также сделать файлы более опрятными (что тоже приятно), программисты придумали принцип DRY. Простыми словами, если Вы видите, что похожий или вообще одинаковый код повторяется в разных местах, то вынесите его в отдельную функцию и потом используйте ее в любом удобном месте. Просто представьте, у Вас есть две функции, которые используют один и тот же огромный кусок кода. Согласитесь, такое будет очень трудно обслуживать и читать, тем более, если не Вы автор программы.

Следование принципу DRY приводит к модульности приложения и к чёткому разделению ответственности за бизнес‑логику между программными классами, то есть к сопровождаемой архитектуре. Хотя в больших проектах чаще не следование DRY приводит к модульности, а скорее модульность обеспечивает принципиальную возможность соблюдения этого принципа. Мы моделируем сущности “космический корабль” и “наноробот размером с атом”.

Коротко Об Использовании Dry

Если вы работаете, например, в архитектуре микросервисов, то дублирование некоторых бизнес-правил в нескольких сервисах может быть более оправданным и целесообразным. При этом считается, что нужно применять DRY по отношению к любому дублированию, а не только к дублированию бизнес-правил и информации. Это часто усугубляется автоматизированными инструментами анализа кода, которые обычно выделяют любое дублирование как признак кода “с душком”. Этот второй фрагмент кода должен подвергнуться рефакторингу, чтобы использовать метод expired? Как видите, логика для определения того, истек ли срок действия заказа, находится в классе Order.