Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта, простоты внесения изменений и качественного тестирования.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте и проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. Следование принципу DRY всегда приводит к декомпозиции сложных алгоритмов на простые функции. А декомпозиция сложных операций на более простые (и повторно используемые) значительно упрощает понимание программного кода. Повторное использование функций, вынесенных из сложных алгоритмов, позволяет сократить время разработки и тестирования новой функциональности.
Следование принципу DRY приводит к модульной архитектуре приложения и к чёткому разделению ответственности за бизнес-логику между программными классами. А это — залог сопровождаемой архитектуры. Хотя чаще не DRY приводит к модульности, а уже модульность, в свою очередь, обеспечивает принципиальную возможность соблюдения этого принципа в больших проектах.
В рамках одного программного класса (или модуля) следовать DRY и не повторяться обычно достаточно просто. Также не требует титанических усилий делать это в рамках небольших проектов, где все разработчики «владеют» всем кодом системы. А вот в больших проектах ситуация с DRY несколько сложнее — повторы чаще всего появляются из-за отсутствия у разработчиков целостной картины или несогласованности действий в рамках команды. Следовать принципу «don’t repeat yourself» в рамках больших проектов не так просто, как это может показаться на первый взгляд. От разработчиков требуется тщательное планирование архитектуры, а от архитектора или тимлида требуется наличие видения системы в целом и чёткая постановка задач разработчикам.
В пректировании DRY тоже имеет место — доступ к конкретному функционалу должен быть доступен в одном месте, унифицирован и сгруппирован по какому-либо принципу, а не «разбросан» по системе в произвольных вариациях. Этот подход пересекается с принципом единственной ответственности из пяти принципов SOLID, сформулированных Робертом Мартином.
DRY — это один из ключевых принципов создания хороших приложений, унификация и повторное использование повышает качество кодовой базы и улучшает сопровождаемость.
Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама
Хорошему программисту необходимо уметь совмещать свои навыки со здравым смыслом. Все дело в прагматизме и навыке выбора лучшего решения для вашей проблемы. Когда вы сталкиваетесь с проблемой при разработке ПО, вы можете воспользоваться базовыми принципами, которые помогут в выборе самого правильного подхода.
Последовательное применение этих принципов упростит ваш переход от миддла к сеньору. Вы можете обнаружить, что некоторые (вероятно) вы применяете интуитивно.
Принципов много. Мы остановимся на семи самых важных. Их использование поможет вам в развитии и позволит стать лучшим программистом.
1. YAGNI
You Aren’t Gonna Need It / Вам это не понадобится
Этот принцип прост и очевиден, но ему далеко не все следуют. Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже.
Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.
Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.
2. DRY
Don’t Repeat Yourself / Не повторяйтесь
Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру».
Идея вращается вокруг единого источника правды (single source of truth — SSOT). Что это вообще такое?
В проектировании и теории информационных систем единый источник истины (SSOT) – это практика структурирования информационных моделей и схемы данных, которая подразумевает, что все фрагменты данных обрабатываются (или редактируются) только в одном месте… SSOT предоставляют достоверные, актуальные и пригодные к использованию данные.
Использование SSOT позволит создать более прочную и понятную кодовую базу.
Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом.
В большинстве случаев дублирование кода происходит из-за незнания системы. Прежде чем что-либо писать, проявите прагматизм: осмотритесь. Возможно, эта функция где-то реализована. Возможно, эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.
3. KISS
Keep It Simple, Stupid / Будь проще
Этот принцип был разработан ВМС США в 1960 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.
У этого принципа много общего с переизобретением колеса, которым занимались в 1970-х. Тогда он звучал как деловая и рекламная метафора.
Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.
Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.
Одна из самых распространенных ошибок нашего времени – использование новых инструментов исключительно из-за того, что они блестят. Разработчиков следует мотивировать использовать новейшие технологии не потому, что они новые, а потому что они подходят для работы.
4. Big Design Up Front
Глобальное проектирование прежде всего
Этот подход к разработке программного обеспечения очень важен, и его часто игнорируют. Прежде чем переходить к реализации, убедитесь, что все хорошо продумано.
Зачастую продумывание решений избавляло нас от проблем при разработке… Внесение изменений в спецификации занимало час или два. Если бы мы вносили эти изменения в код, на это уходили бы недели. Я даже не могу выразить, насколько сильно я верю в важность проектирования перед реализацией, хотя адепты экстремального программирования предали эту практику анафеме. Я экономил время и делал свои продукты лучше, используя BDUF, и я горжусь этим фактом, чтобы там ни говорили фанатики экстремального программирования. Они просто ошибаются, иначе сказать не могу.
Многие разработчики считают, что если они не пишут код, то они не добиваются прогресса. Это неверный подход. Составив план, вы избавите себя от необходимости раз за разом начинать с нуля.
Иногда в недостатках и процессах разработки архитектуры должны быть замешаны и другие люди. Чем раньше вы все это обсудите, тем лучше будет для всех.
Очень распространенный контраргумент заключается в том, что стоимость решения проблем зачастую ниже стоимости времени планирования. Чем с меньшим количеством ошибок столкнется пользователь, тем лучше будет его опыт. У вас может не быть другого шанса справиться с этими ошибками.
5. SOLID
Это наиболее известный принцип разработки ПО. Solid — это аббревиатура от:
S) Single-responsibility principle /Принцип единственной ответственности
Его важность невозможно переоценить. Каждый объект, класс и метод должны отвечать только за что-то одно. Если ваш объект/класс/метод делает слишком много, вы получите спагетти-код. Вот пример:
Этот метод кажется безобидным, но на самом деле он делает слишком много:
O) Open–closed principle / Принцип открытости-закрытости
Программные объекты должны быть открыты для расширения, но закрыты для модификации. Речь о том, что нельзя переопределять методы или классы, просто добавляя дополнительные функции по мере необходимости.
Хороший способ решения этой проблемы – использование наследования. В JavaScript эта проблема решается с помощью композиции.
Простое правило: если вы изменяете сущность, чтобы сделать ее расширяемой, вы впервые нарушили этот принцип.
L) Liskov substitution principle / Принцип подстановки Лисков
Этот принцип гласит, что объекты старших классов должны быть заменимы объектами подклассов, и приложение при такой замене должно работать так, как ожидается.
I) Interface segregation principle / Принцип разделения интерфейсов
Этот принцип был сформулирован Робертом Мартином, когда он консультировал Xerox, и он очевиден.
Объекты не должны зависеть от интерфейсов, которые они не используют
ПО должно разделяться на независимые части. Побочные эффекты необходимо сводить к минимуму, чтобы обеспечивать независимость.
Убедитесь, что вы не заставляете объекты реализовывать методы, которые им никогда не понадобятся. Вот пример:
Не все животные могут fly, walk или swim, поэтому эти методы не должны быть частью интерфейса или должны быть необязательными.
D) Dependency inversion principle / Принцип инверсии зависимостей
Этот принцип невозможно переоценить. Мы должны полагаться на абстракции, а не на конкретные реализации. Компоненты ПО должны иметь низкую связность и высокую согласованность.
Заботиться нужно не о том, как что-то устроено, а о том, как оно работает. Простой пример – использование дат в JavaScript. Вы можете написать для них свой слой абстракции. Тогда если у вас сменится источник получения дат, вам нужно будет внести изменения в одном месте, а не в тысяче.
Иногда добавление этого уровня абстракции требует усилий, но в конечном итоге они окупаются.
В качестве примера взгляните на date-io, в этой библиотеке создан тот уровень абстракции, который позволяет вам использовать её с разными источниками дат.
6. Avoid Premature Optimization
Избегайте преждевременной оптимизации
Эта практика побуждает разработчиков оптимизировать код до того, как необходимость этой оптимизации будет доказана. Думаю, что если вы следуете KISS или YAGNI, вы не попадетесь на этот крючок.
Поймите правильно, предвидеть, что произойдет что-то плохое – это хорошо. Но прежде чем вы погрузитесь в детали реализации, убедитесь, что эти оптимизации действительно полезны.
Очень простой пример – масштабирование. Вы не станете покупать 40 серверов из предположения, что ваше новое приложение станет очень популярным. Вы будете добавлять серверы по мере необходимости.
Преждевременная оптимизация может привести к задержкам в коде и, следовательно, увеличит затраты времени на вывод функций на рынок.
Многие считают преждевременную оптимизацию корнем всех зол.
7. Бритва Оккама
Бри́тва О́ккама (иногда ле́звие О́ккама) — методологический принцип, в кратком виде гласящий: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без крайней на то необходимости»).
Что это значит в мире программирования? Не создавайте ненужных сущностей без необходимости. Будьте прагматичны — подумайте, нужны ли они, поскольку они могут в конечном итоге усложнить вашу кодовую базу.
Заключение
Эти принципы не очень сложны. На самом деле, именно простота делает их красивыми. Если вы сбиты с толку, не пытайтесь применять все их сразу. Просто постарайтесь работать осознанно и пробуйте постепенно включать эти принципы в свой рабочий процесс.
Использование базовых, но действенных принципов позволит вам стать лучшим программистом и иметь более четкое представление о том, почему вы что-то делаете.
Если вы применяете большую часть принципов интуитивно, стоит задумываться и осознавать почему вы делаете что-то определенным образом.
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.
У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.
В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.
Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
Ошибочное понимание принципа DRY
Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».
Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.
Если кто не знает: принцип DRY — это «Don’t Repeat Yourself» (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.
Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!
Не повторяйте свои знания
Хотя фраза «не повторяйся» звучит очень просто, в то же время она слишком общая.
В книге The Pragmatic Programmer принцип DRY определяется как «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».
Всё замечательно, но… что такое «часть знания»?
Я бы определил это как любую часть предметной области бизнеса или алгоритма.
Если взять популярные аналогии из электронной коммерции, то класс shipment и его поведение будут частью предметной области бизнеса вашего приложения. Отгрузка — это реальный процесс, используемый вашей компанией для отправки товара своим клиентам. Это часть бизнес-модели компании.
Следовательно, логика работы класса shipment должна появляться в приложении однократно.
Причина очевидна: допустим, вам нужно отправить груз на склад. Для этого придётся активировать логику отгрузки в 76 разных местах приложения. Без проблем: вставляем логику 76 раз. Через некоторое время приходит начальник и просит кое-что изменить в логике: вместо одного склада компания теперь распределяет товары по трём складам. В результате вы потратите кучу времени на изменение логики, поскольку вам придётся сделать это в 76 местах! Совершенно впустую потраченное время, хороший источник багов и прекрасный способ выбесить начальство.
Ещё один пример: допустим, вы пишете хитрый класс для парсинга В-деревьев. Его тоже можно считать знанием: это алгоритм, который должен быть определён однократно. А уже представление знания можно использовать где вашей душе угодно без повторения самого знания.
DRY и дублирование кода
Так значит DRY относится к knowledge? К бизнес-логике?
Начнём с очевидного:
Этот код выглядит недурно, правда?
Однако Лёха, твой коллега-разработчик, с вами не согласится. Когда Лёха увидит этот код, подойдёт к вашему столу и возмутится:
Лёха — начинающий эксперт в вашей компании, и не имеет понятия об ООП.
Я прямо вижу, как вы, замечательный разработчик, смотрите на Лёху, словно опытный садовник на личинку, и отвечаете:
Здесь никак не нарушается принцип DRY. Лёха затыкается, подавленный вашей аурой величия, заполняющей комнату. Но вы поставили под сомнение его знания, и он злится. Лёха гуглит приницп DRY, находит другой пример вашего кода, возвращается и тычет вам в лицо:
Лёха торжествующе восклицает: «Ты олень! Этот код не соответствует DRY!». А вы, прочитав эту статью, отвечаете: «Но бизнес-логика и знание всё ещё не повторяются!»
Вы снова правы. Метод проверяет результат парсинга CSV только в одном месте ( validateProduct() ). Это знание, и оно не повторяется.
Вы молниеносно набираете код:
Выглядит лучше, верно?
Но Лёха ещё не убеждён. Со спокойствием высшего духовного наставника, вы ставите точку в споре: «Многие думают, что DRY запрещает дублировать код. Но это не так. Суть DRY гораздо глубже».
Кто это сказал? Дэйв Томас, один из авторов The Pragmatic Programmer, книги, в которой дано определение самого принципа DRY!
Применяем DRY везде: рецепт катастрофы
Бесполезные абстракции
Возьмём более жизненный, интересный пример. Сейчас я работаю над приложением для компании, занимающейся производством фильмов. В него можно легко загружать сами фильмы и метаданные (заголовки, описания, титры…). Всё эта информация затем отображается в VoD-платформе. Приложение построено на основе паттерна MVC, и выглядит оно так:
Но создавать с помощью этого приложения контент могут не только съёмочные группы. К примеру, им может воспользоваться и команда по управлению контентом в моей компании. Почему? Некоторые съёмочные группы не хотят этим заниматься. У съёмочной команды и команда по управлению контентом совершенно разные потребности. Вторые работают с CMS, а первые — нет.
Поэтому мы решили создать два интерфейса. Один для команды управления контентом, без подсказок и объяснений, но позволяющий очень быстро добавлять контент. Второй интерфейс для съёмочной группы, объясняет всё, что нужно сделать, очень дружелюбный. Вот результат:
Выглядит как очевидное и уродливенькое нарушение принципа DRY: повторяются представления (view) и контроллер.
Более того, контроллеры не должны содержать в себе бизнес-логику. Если вспомните определение DRY, то это как раз знание, которое не стоит дублировать.
Иными словами, если пытаться везде применять DRY, то можно прийти к одному из двух:
Очевидно, что ни то, ни другое вам не улыбается.
Преждевременная оптимизация
Не стоит применять DRY, если ваша бизнес-логика ещё не содержит никаких дублирований. Конечно, всё зависит от ситуации, но, как показывает практика, если применять DRY к чему-то, что используется только один раз, то можно оказаться в ситуации преждевременной оптимизации.
Если вы начинаете что-то абстрагировать, потому что «позже это может понадобиться», то не делайте этого. Почему?
Многократное использование кода и дублирование кода — разные вещи. DRY гласит, что не нужно дублировать знания, а не что нужно всегда делать код многократно используемым.
Сначала напишите код, отладьте его, а затем уже держите в уме все эти принципы (DRY, SOLID и прочие), чтобы эффективно рефакторить код. Работать с нарушением принципа DRY нужно тогда, когда знание уже дублировано.
Дублирование знания?
Помните, выше я говорил, что повторение бизнес-логики всегда является нарушением DRY? Очевидно, что это справедливо для ситуаций, когда повторяется одна и та же бизнес-логика.
Вы уже слышите, как ваш коллега Лёха нежно вопит вам в ухо: «Это очевидное нарушение всего, во что я верю! А как же принцип DRY? У меня сердце сжимается!».
Но Лёха снова ошибается. С точки зрения электронной коммерции, время доставки товара покупателю ( Shipment::calculateDeliveryDay() ) не имеет отношения к сроку возврата товара покупателем ( Return::calculateLastReturnDay ).
Это две разные функциональности. То, что выглядит дублированием кода, на самом деле чистое совпадение. Что произойдёт, если вы объедините два метода в один? Если ваша компания решит, что покупатель теперь может вернуть товар в течение месяца, то вам снова придётся разделить метод. Ведь если этого не сделать, то срок доставки товара тоже будет составлять один месяц!
А это не лучший способ завоевать лояльность клиентов.
DRY — не просто принцип для педантов
Сегодня даже джин может быть DRY!
DRY — это не то, что вам стоит уважать только в своём коде. Не нужно повторять знания в каждом аспекте вашего проекта. Снова процитирую Дэйва Томаса: «Понятие «знания» в системе охватывает далеко не только код. Оно относится и к схемам баз данных, планам тестирования, системе сборки и даже документации».
Суть DRY проста: не нужно обновлять параллельно несколько вещей, если вносится какое-то изменение.
Если ваше знание дважды повторяется в коде, и вы забыли обновить одно представление, то возникнут баги. Это приведёт к заблуждениям и недоразумениям в документации, и к совершенно ошибочной реализации. И так далее, и тому подобное.
DRY — это принцип
В начале своей карьеры я часто страдал от аналитического паралича. Все эти принципы не давали мне быть продуктивным и эффективным. Было слишком сложно, и я не хотел всё испортить.
Я хотел следовать каждой букве этих принципов, чтобы быть хорошим разработчиком.
Однако принципы — не правила. Они лишь инструменты, помогающие идти в правильном направлении.
В разработке у всего есть цена. И DRY не исключение. Очевидно, что не стоит везде повторять бизнес-логику, но также не нужно и тесно объединять всё подряд, экономя на абстракциях. Необходимо искать баланс, который зависит от текущей ситуации.
Новый взгляд на старые истины: принцип “Не повторяйся!” (DRY)
Sep 9, 2020 · 6 min read
Первый принцип, с которым вы знакомитесь, начиная свой путь в мир разработок ПО и записывая первые с т роки кода, — это постулат DRY (“Не повторяйся”). А как он серьезно и убедительно звучит! Более того, этот принцип как нельзя лучше объясняет, почему многие из нас так любят программирование: он дарит свободу от скучной и однообразной работы. Зерно этой идеи легко понять и объяснить (в отличие от принципа подстановки Барбары Лисков, который мне приходится каждый раз гуглить, как только речь заходит о SOLID (объектно-ориентированное программирование). Воплощение DRY в жизнь обычно сопровождается особым чувством удовольствия, когда всё сходится. Что же тут может не нравиться?
Предотвращение повторов в коде — мысль, бесспорно, хорошая. Но иногда, на мой взгляд, это непродуктивно. И вот подобные случаи мне бы хотелось с вами обсудить в данной статье.
Код без повторов может привести к сильному зацеплению
Совместное использование одного фрагмента кода двумя инициаторами вызова зачастую является прекрасным решением. Если у вас есть два сервиса, которые должны отправить транзакционное e-mail, заполнив его полученными данными о пользователе и отобразив шаблон, то код будет выглядеть так:
Вы только посмотрите, сколько здесь повторов! Так и хочется скорректировать код по принципу DRY:
Чудесно! Мы извлекли повторяющийся в сервисах код во вспомогательную функцию, и теперь наши сервисы выглядят так:
Гораздо чище, согласитесь?
Одно из обещаний принципа заключается в том, что он позволяет развивать наше ПО. Бизнес-требования и технические условия постоянно меняются, и если нам нужно изменить поведение фрагмента кода, то мы сделаем это только один раз, и он будет отображен везде.
В примере выше мы довольно легко можем изменить не только способ получения информации о пользователе, но и e-mail провайдера.
Как учил меня один мой хороший друг:
“Когда вам встречается класс с именем Helper (помощник), то вряд ли от него стоит ждать помощи”.
Принцип DRY может усложнить читаемость кода
Приведем еще один пример. Допустим, мы пишем модульные тесты для разрабатываемого веб-сервера, и на данный момент у нас их два:
Можно это выразить, используя вспомогательную функцию:
Здесь я редактирую точные определения Requester и Validator для экономии места, но вы можете ознакомиться с полной реализацией на Github Gist.
Теперь при помощи рефакторинга наши тесты станут аккуратными и без повторов:
Отметим несколько интересных моментов в связи с этим процессом изменения:
1.Быстрее будет написать новые похожие тесты. Если у нас есть 15 конечных точек, которые схожи в своем поведении и требуют аналогичных утверждений, то мы можем выразить их лаконичным и эффективным способом.
2.Наш код стало гораздо сложнее читать и расширять. Если тест провалится из-за какого-либо изменения в будущем, то не позавидуешь тому разработчику, который возьмет на себя его отладку, так как ему придется поломать голову, прежде чем он разберется в происходящем. А мы заменили обычный и простой код на умные абстракции и косвенную адресацию.
Но когда же использовать принцип DRY в коде?
Практика размещения общего кода в библиотеках для последующего совместного использования приложениями стала уже проверенной и эффективной традицией, давно закрепившейся в нашей индустрии, и, конечно, мы не призываем ее прекращать!
Чтобы определиться, в каких ситуациях лучше использовать неповторяющийся код, мне бы хотелось представить вам одну идею из потрясающей книги Энди Ханта и Дейва Томаса “Программист-прагматик. Ваш путь к мастеру” ( The Pragmatic Programmer: Your Journey to Mastery), недавно опубликованной в обновленном 2-ом издании (в первом издании книга вышла в 1999 году под названием “Программист-прагматик. Путь от подмастерья к мастеру”):
“Программа считается хорошо спроектированной, если она адаптируется под людей, использующим ее. В отношении кода это значит, что он должен адаптироваться к изменениям. Поэтому мы полагаемся на принцип: “Чем легче изменить, тем лучше”. Вот так!
Исходя из нашего опыта, каждый принцип проектирования—это отдельный случай подтверждения данной мысли. Почему следует снижать зацепление? Потому что изолируя задачи, мы облегчаем изменения каждой из них. Вывод — чем легче изменить, тем лучше.
Почему так полезен принцип единственной ответственности? Потому что изменение в требованиях влечет за собой изменение только в одном модуле. И снова наш принцип в действии”.
В этом гениальном фрагменте главы Хант и Томас развивают идею о том, что существует мета-принцип оценки проектировочных решений, которые часто сталкиваются друг с другом: насколько легко будет развивать кодовую базу, если мы выберем конкретно этот путь? В наших рассуждениях выше были показаны два случая, при которых написание кода без повторов может осложнить его дальнейшее изменение по причине либо сильного зацепления, либо затруднения читаемости, что не соответствует идее: “Чем легче изменить, тем лучше”.
Имея в виду эти возможные последствия написания кода по принципу DRY, можно определить ситуации, когда нам не следует, а когда следует соблюдать этот тезис. Давайте вернемся к нашему оригинальному “Евангелию” от Ханта и Томаса и еще раз рассмотрим данный постулат.
Принцип DRY был впервые представлен миру этими авторами в книге, изданной в 1999 году. Они пишут:
“Каждый фрагмент знания должен иметь единственное, однозначное и надежное представление в системе. Альтернативой является представление одного и того же предмета в двух или более местах.
Если вы меняете одно, то не забудьте поменять и другое, [..]. Вопрос не в том, вспомните ли вы об этом, а в том, когда вы об этом забудете”.
Обратите внимание, что принцип DRY изначально не имеет никакого отношения к повторению или дублированию. Он указывает на опасность отсутствия у фрагмента знания единственного и истинного представления в системе.
В завершении нашей темы, должен признать, что в целом принцип DRY является довольно важным советом. Однако следует помнить, что использовать его надо с умом.