Когда Не Стоит Полагаться На Dry Хабр

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

• Рассмотрим фрагмент кода с двумя классами, в котором есть дублирование.
• Он используется на этапе до MVP и предназначен только для того, чтобы подтвердить или опровергнуть необходимость дополнительной функциональности.
• Если нам нужно будет поменять базу данных, с которой работает модуль, достаточно будет сделать это при вызове, а не править исходную функцию.
• Оба класса публикуют событие в Kafka в совершенно разных частях приложения и в разных случаях использования.
• Смысл принципа DRY — не писать новый код, если уже есть старый, который делает то, что нам нужно.

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

Программисты придумали всё это чтобы работать по единым стандартам в команде или компании. Например, если команда придерживается DRY-подхода, то на код-ревью тимлид будет ругаться на одинаковые по функционалу модули. А если в компании работают по принципам SOLID, то там наоборот, у модулей может быть похожий смысл, но каждый модуль будет решать свою отдельную задачу. Например, если разработчик не знает кодовую базу, он может  неосознанно повторить уже существующую в проекте модель данных. Дублирование также возникает как результат других процессов, например, когда разные команды независимо друг от друга создают похожие решения для разных частей одного проекта. В методе add_location_context нет бизнес-логики  —  это простой код, который необходим в совершенно несвязанных частях кодовой базы.

Проблема Со Слишком Ревностным Применением Dry

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

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

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

YAGNI призывает избегать внедрения функциональности, которая в настоящий момент не требуется, но может понадобиться в будущем. Принцип YAGNI призывает к созданию только той функциональности, которая необходима для решения текущих задач и требований, и отложению добавления неиспользуемой функциональности на будущее. Эта техника помогает участникам проекта выделить предметные области и достаточно точно определить, существует ли дублирование знаний между разными модулями, и решить, выделять ли их в общее место. Доменно-ориентированное проектирование (DDD) – это подход к разработке программного обеспечения, при котором упор делается на создание софта, который отражает реальные бизнес-процессы и проблемы. Объединив два разных случая вычисления площади в одну универсальную функцию, можно упростить процесс поддержания кода.

Dry

Стоит не внести изменение в одном месте (что вполне вероятно), и в разных частях приложения будет применяться разная логика. Следовать принципу «don’t repeat yourself» в рамках больших проектов не так просто, как это может показаться на первый взгляд. От разработчиков требуется тщательное планирование архитектуры, а от архитектора или тимлида требуется наличие видения системы в целом и чёткая постановка задач разработчикам. Смысл в том, чтобы зависимости, например от внешней базы данных, не встраивались жёстко в тело модуля, а были одним из аргументов, от которых зависит выполнение этого модуля. Если нам нужно будет поменять базу данных, с которой работает модуль, достаточно будет сделать это при вызове, а не править исходную функцию.

Смысл принципа DRY — не писать новый код, если уже есть старый, который делает то, что нам нужно. Если его возможностей немного не хватает, то программист думает, как их туда добавить, не сломав исходную функцию. Принцип DRY — это полезный инструмент разработки, который часто используют неправильно, что приводит к проблемам в процессе разработки. Поэтому для оптимизации кодовой базы крайне важно понимать причины дублирования и его разновидности. А сделать обоснованные решения о структуре и организации кода для его долгосрочной устойчивости и масштабируемости помогут практики моделирования, такие как DDD и Event Storming. Следование принципу DRY приводит к модульной архитектуре проекта, что положительно сказывается на возможности его обслуживать долгие годы.

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

Когда Принцип Dry Работает Как Надо

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

Однако если бы в другом месте была вторая часть кода, использующая ту же логику, это считалось бы нарушением принципа DRY, так как бизнес-правило было бы продублировано в двух местах. Теперь можно даже переключать зависимости — например, использовать другой модуль для подключения к базе данных — на коде это не отразится, он всё так же будет отрабатывать необходимую логику. Здесь мы видим, что подключение к базе данных объявлено и выполняется внутри одного модуля, а функцию saveUser вы экспортируете. Если теперь попытаться протестировать код, эта функция автоматически постарается выполнить свою первоначальную задачу — подключиться к базе данных и сохранить данные пользователя в ней. Он подразумевает, что каждый кусок информации (код, данные и т.д.) должен иметь только один, четко определенный “источник правды” в системе. Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза).

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

Пример Использования Подхода Dry

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

И раз уж мы заговорили о каскадной модели, то нельзя не вспомнить о принципе Big design up entrance («Масштабное проектирование прежде всего»), который идеально для неё подходит. Он утверждает, что большую часть времени, отведённого на проектирование приложения, вы тратите далеко не на написание кода. Возможно, при работе с MyModule кому-то и захочется реализовать методы close и open, но если не требуется обеспечить совместимость с IE8, то последний из трёх перечисленных в коде методов точно не понадобится. Другими словами, LSP гарантирует правильное использование наследования в вашем коде.

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

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

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

Например, у объекта «сетевое подключение» могут быть интерфейсы «подключиться», «отключиться», «проверить связь» и «передать данные». Принцип разделения означает, что если мы поменяем внутри что-то в одном интерфейсе, это не должно сломать работу остальных интерфейсов. У разработчиков есть свои термины, которыми они описывают разные принципы разработки — например DRY, SOLID и YAGNI. Рассказываем, что они означают и что имеют в виду программисты, когда говорят такое.

Этот принцип, также известный как LSP, максимально приближает нас собственно к теории программирования. Сильно углубляться в неё я не буду — просто опишу суть принципа подстановки. Мы создаём сайты и веб-приложения, которые выдерживают десятки тысяч обращений в минуту без сбоев и без снижения скорости работы. Принцип заключается в том, что возможности, которые https://deveducation.com/ не описаны в требованиях к системе, просто не должны реализовываться. Здесь легко применить DRY, создав общую функцию для расчета площади и квадрата, и для прямоугольника сразу. Для этого достаточно создать функцию, которая считает площадь квадрата, если  указан только один параметр, и прямоугольника, если указаны два параметра (длина и ширина).