Принцип программирования DRY — don’t repeat yourself / не повторяйтесь
Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта, простоты внесения изменений и качественного тестирования.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных.
Следование принципу DRY всегда приводит к декомпозиции сложных алгоритмов на простые функции. Декомпозиция же сложных операций на более простые значительно упрощает понимание программного кода. Такой код удобнее для тестирования и масштабирования. Также становится возможным повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Следование принципу DRY приводит к модульности приложения и к чёткому разделению ответственности за бизнес‑логику между программными классами, то есть к сопровождаемой архитектуре. Однако в больших проектах чаще не следование DRY приводит к модульности, а модульность обеспечивает принципиальную возможность соблюдения этого принципа.
В рамках одного программного класса или модуля следовать DRY и не повторяться достаточно просто. Также не требует титанических усилий делать это в рамках небольших проектов, где все разработчики «владеют» всем кодом системы.
Следовать принципу «don’t repeat yourself» в рамках больших проектов не так просто, как это может показаться. Повторы чаще всего появляются из‑за отсутствия у разработчиков целостной картины или несогласованности действий в рамках команды. От разработчиков крупных проектов требуется тщательное планирование архитектуры, а от архитектора или тимлида — наличие видения системы в целом и чёткая постановка задач разработчикам.
В проектировании DRY тоже имеет место — к конкретным функциям должен быть доступ в одном месте, унифицированный и сгруппированный по какому‑либо принципу, а не «разбросанный» по системе в произвольных вариациях.
DRY пересекается с принципом единственной ответственности из пяти принципов SOLID, описанных Робертом Мартином, а также с принципами YAGNI и KISS.
Как и любой другой принцип, DRY не должен становиться догмой — иногда дублирование бывает вполне оправдано. Например, две изначально идентичные функции в разных классах или модулях в перспективе могут эволюционировать по‑разному, а их объединение только усложнит код и его последующую модификацию.
Тематические статьи
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. Большая часть программных систем необоснованно перегружена практически ненужными функциями, что ухудшает удобство их использования конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
SOLID — это аббревиатура, введённая Майклом Физерсом для пяти основных принципов проектирования в объектно-ориентированном программировании:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов. При следовании этой методологии тесты пишутся до написания кода. TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем. В парадигме MVC контроллер отвечает за взаимодействие пользователя с приложением, модель — за слой хранения данных и бизнес‑логику, а представление — за пользовательский интерфейс / формат выходных данных. Модификация каждого из этих компонентов либо оказывает минимальное воздействие на остальные, либо не оказывает его вовсе. Это облегчает понимание логики работы системы и упрощает внесение изменений в кодовую базу.
Наши услуги
Давайте обсудим ваш проект
Заполните короткий бриф или свяжитесь с нами удобным вам способом
