Тематические статьи →

Принцип программирования DRY — don’t repeat yourself (не повторяйте себя)

Сле­до­ва­ние прин­ципу про­грам­ми­ро­ва­ния «DRY» поз­во­ляет добиться высо­кой сопро­вож­да­е­мо­сти про­ек­та: про­стоты вне­се­ния изме­не­ний и каче­ствен­ного тестирования.

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

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

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

В пректировании DRY тоже имеет место — доступ к кон­крет­ному функ­ци­о­налу дол­жен быть досту­пен в одном месте, уни­фи­ци­ро­ван и сгруп­пи­ро­ван по какому-либо прин­ципу, а не «раз­бро­сан» по системе в про­из­воль­ных вариациях.

Поделитесь с друзьями:


Информация о публикации:

Материал опубликован в 2014 году. Эта статья о веб-разработке, про фронтенд-разработку и про бэкенд-разработку. При пере­пуб­ли­ка­ции обя­за­тельно ука­за­ние пер­во­ис­точ­ника в виде гипер­тек­сто­вой ссылки на сайт web-creator.ru

Воспользуйтесь нашими
знаниями и опытом

Отправьте нам сообщение при помощи формы. Или напишите на e-mail s@web-creator.ru

Мы максимально оперативно ответим Вам по электронной почте или перезвоним.

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

Либо просто позвоните нам по номеру: +7 495 215-1501

Мы работаем по будним дням с 10 до 19 часов.

Комплексные услуги

Реализация «под ключ» проектов по созданию различных видов сайтов, разработка веб-приложений для автоматизации бизнес-процессов, ведение контекстных и медийных рекламных кампаний, поисковое продвижение, комплексная поддержка веб-проектов, консалтинговые услуги.