Do Not Repeat Yourself Dry, Рус Не Повторяйся

Просматривая вопросы по sqlc, я нашел разработчиков, которые просят еще больше гибкости, например, переименовывать сгенерированные поля или пропускать некоторые поля JSON принципы разработки по полностью. Кто-то даже упоминает, что им нужно скрыть чувствительные поля в REST API. Сгенерированный код предоставляет вам строгие типы и проверку на этапе компиляции.

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

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

  • Вы получите аналогичные результаты сначала, но каждая новая функция потребует больше обходных решений.
  • Вы знаете, что именно меняете, и что не будет побочных эффектов.
  • А вот в больших проектах ситуация с DRY несколько сложнее — повторы чаще всего появляются из‑за отсутствия у разработчиков целостной картины или несогласованности действий в рамках команды.
  • Мы моделируем сущности “космический корабль” и “наноробот размером с атом”.
  • Первоначально обоснование соблюдения принципа DRY было вполне разумным.
  • Если теги отсутствуют, это может нарушить ваш API-контракт или даже повредить ваше хранилище.

Любое изменение в логике работы повторяющегося кода придется дублировать в остальных местах. Когда программист создает настоящую программу, очень часто возникает необходимость использовать один и тот же код, но в разных местах. Иногда доходит до такого, что необходимо переиспользовать огромные участки программы, которые могут занимать больше двухсот или даже трехсот строчек кода. Таким образом, мы выяснили, что слепое использование DRY может навредить проекту. Именно поэтому рефакторинг или объединение кода должны опираться на глубокое понимание причин и природы дублирования – без них оптимизировать программное обеспечение невозможно.

Принцип Программирования Dry

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

Объединив два разных случая вычисления площади в одну универсальную функцию, можно упростить процесс поддержания кода. В обоих блоках кода выполняется похожая операция — умножение длин сторон. В случае квадрата — это умножение длины стороны саму на себя, а для прямоугольника — умножение длины на ширину. Этот второй фрагмент кода должен подвергнуться рефакторингу, https://deveducation.com/ чтобы использовать метод expired? Однако если бы в другом месте была вторая часть кода, использующая ту же логику, это считалось бы нарушением принципа DRY, так как бизнес-правило было бы продублировано в двух местах. В системе должен существовать только один основной источник данных или информации, который является авторитетным и актуальным.

dry принципы

Самый простой способ уменьшить зависимость – использовать отдельные модели. Главный вызов стоящий перед веб приложениями заключается в том, чтобы не дать им превратиться в огромную кучу сами знаете чего (“Big Ball of Mud”). Это не только замедляет разработку, но и может уничтожить проект. Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза).

Принцип Dry

В этой статьей я расскажу про типичные ошибки при использовании этого правила и способы их избежать. Цена устранения такого дублирования, на мой взгляд, слишком высока. В методе add_location_context нет бизнес-логики  —  это простой код, который необходим в совершенно несвязанных частях кодовой базы. Это неоптимально, поскольку обновление бизнес-правила  —  по истечении срока действия заказа через 7 дней  —  потребует изменений в нескольких местах. Стоит не внести изменение в одном месте (что вполне вероятно), и в разных частях приложения будет применяться разная логика. DRY — это просто подход или, можно сказать, другой взгляд на программистов.

Их основная цель — правильно смоделировать продукт и позволить улучшать его быстрее, чем это делают конкуренты. Больше всего мне нравилось работать с низкоуровневыми деталями и сложными алгоритмами. Но после перехода на пользовательские приложения эта часть работы почти исчезла. Теперь программирование казалось мне просто перемещением данных из одного места в другое с помощью уже готовых библиотек и инструментов.

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

Генерация Шаблонного Кода

В Java это означает, что нельзя писать один и тот же код повторно. Предположим, вы используете один и тот же код во многих местах вашей программы, тогда это означает, что вы не следуете СУХОМУ подходу; Вы повторяете один и тот же код в разных местах. Следовательно, решение получается с использованием концепции DRY путем размещения методов вместо всех повторяющихся кодов и определения кода в одном методе. Концепция DRY очень важна для улучшения кода за счет уменьшения избыточности кода и поощрения его повторного использования. Принцип DRY не рекомендует просто слепо объединять одинаковые блоки кода.

dry принципы

Если информация хранится только в одном месте, то изменения и обновления могут быть произведены в одном месте, и они автоматически будут отражены во всех остальных местах, где эта информация используется. На стадии MVP заманчиво начать с CRUD, чтобы быстро создать рабочую версию. Но это как использовать таблицу вместо специализированного программного обеспечения. Вы получите аналогичные результаты сначала, но каждая новая функция потребует больше обходных решений.

Ваше Веб-приложение Не Crud

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

Don’t Repeat Yourself Или Dry: Что Такое, Для Чего Нужно, Примеры Применения

Здесь легко применить DRY, создав общую функцию для расчета площади и квадрата, и для прямоугольника сразу. Для этого достаточно создать функцию, которая считает площадь квадрата, если  указан только один параметр, и прямоугольника, если указаны два параметра (длина и ширина). Думаю, лучше всего объяснить правильный и неправильный подходы на конкретном примере.

Но большинство из них касаются простых основных идей, таких как “Нужно” из этой статьи. Они применимы и в веб-приложениях, которые часто имеют дело со сложным бизнес-поведением. Не моделируйте сложное поведение с помощью тривиального кода. Если вы создаете новый UserID и не получаете ошибку, вы уверены, что он действителен. В противном случае вы можете легко сопоставить ошибку с соответствующим ответом, специфичным для вашего API. Однако вы не можете сказать, корректна ли структура в любой момент.

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

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

Вы можете найти множество репозиториев “пример микросервиса” или “шаблон REST”, которые предлагают, как разделить пакеты. Некоторые даже упоминают, что они следуют “Чистой архитектуре” или “Гексагональной архитектуре”. Приведенные выше примеры кода взяты из одного и того же репозитория и реализуют классический домен “пользователи”. Все примеры предоставляют один и тот же API и проходят один и тот же набор тестов. Поскольку модели приложения содержат все валидации и другие бизнес-правила, не имеет значения, используем ли мы их из HTTP или gRPC API. Вы делаете это разделение не потому, что ожидаете сменить базу данных.

Даже GitHub Copilot не знает, как работает ваш продукт, кроме шаблонного кода. В примерах, которые я подготовил, я мог бы легко переместить код, связанный с HTTP и базой данных, в отдельные пакеты. Когда вы смотрите на примеры структур, помните, что они могут быть разработаны для другого типа приложения. Ни один подход не работает одинаково хорошо для открытого инфраструктурного инструмента, бэкенда веб-приложения и стандартной библиотеки. Например, проекты sqlc и sqlboiler генерируют код из SQL-запросов.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *