97 этюдов для программистов. Опыт ведущих экспертов

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

Повторение в процессах указывает на необходимость автоматизации

Многие процессы в разработке программного обеспечения многократно повторяются и легко автоматизируются. Принцип DRY применим как к исходному коду приложения, так и в подобных контекстах. Ручное тестирование проходит медленно, подвержено ошибкам и повторять его трудно, поэтому по возможности следует применять автоматизированные наборы тестов (test suites). Интеграция приложения вручную занимает много времени и подвержена ошибкам, поэтому процесс сборки нужно выполнять как можно чаще — желательно после каждой записи кода в репозиторий. Там, где есть трудоемкие ручные процессы, которые можно автоматизировать, их нужно автоматизировать и стандартизировать. Цель — обеспечить наличие единственного способа решения задачи и сделать его как можно менее трудоемким.

Повторение в логике указывает на необходимость абстракции

Повторения в логике бывают разных видов. Очень легко обнаруживаются и исправляются случаи копирования и вставки конструкций if-then и switch-case. Многие шаблоны проектирования явным образом направлены на сокращение или удаление дублирования логики в приложении. Если объект требует выполнения некоторых действий, прежде чем его можно использовать, полезно применить шаблон Abstract Factory или Factory Method. Если у объекта много разных вариантов поведения, полезно организовать их с помощью шаблона Strategy, а не больших структур if-then. Фактически само создание шаблонов проектирования является попыткой сократить расходование сил, затрачиваемых на решение стандартных проблем и их обсуждение. Кроме того, применение принципа DRY к структурам, таким как схемы баз данных, приводит к нормализации.

Дело принципа

Другие принципы программного обеспечения также связаны с DRY. Принцип «один и только один раз» (Once and Only Once), который применим только к функциональному поведению кода, можно рассматривать как подмножество DRY. Принцип «открыт/закрыт» (Open/Closed), гласящий, что «элементы программного обеспечения должны быть открыты для расширения, но закрыты для модификации» на практике действует только тогда, когда выполняется принцип DRY. Аналогично на DRY основан известный «принцип единственной ответственности» (Single Responsibility Principle), который требует, чтобы у класса была только одна причина изменения.

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

Этот код не трогать! Кэл Эванс

С каждым из нас такое когда-нибудь да случалось. Ваш код загружен на промежуточный (staging) сервер для системного тестирования, и руководитель отдела тестирования сообщает вам, что есть проблема. Вы сразу готовы ответить: «Дайте-ка я быстро все исправлю: я знаю, в чем дело».

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

В большинстве случаев, если речь идет о веб-разработке, архитектуру можно разбить на следующие части:

• Локальная разработка и модульное тестирование на машине разработчика

• Сервер разработки, где проводится автоматическое или ручное интеграционное тестирование

• Промежуточный (staging) сервер, где команда контроля качества и пользователи осуществляют приемочное тестирование

• Боевой (production) сервер