Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта, простоты внесения изменений и качественного тестирования.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных.
Следование принципу DRY всегда приводит к декомпозиции сложных алгоритмов на простые функции. Декомпозиция же сложных операций на более простые значительно упрощает понимание программного кода. Также становится возможным повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Следование принципу DRY приводит к модульности приложения и к чёткому разделению ответственности за бизнес‑логику между программными классами, то есть к сопровождаемой архитектуре. Хотя в больших проектах чаще не следование DRY приводит к модульности, а скорее модульность обеспечивает принципиальную возможность соблюдения этого принципа.
В рамках одного программного класса или модуля следовать DRY и не повторяться обычно достаточно просто. Также не требует титанических усилий делать это в рамках небольших проектов, где все разработчики «владеют» всем кодом системы. А вот в больших проектах ситуация с DRY несколько сложнее — повторы чаще всего появляются из‑за отсутствия у разработчиков целостной картины или несогласованности действий в рамках команды.
Следовать принципу «don’t repeat yourself» в рамках больших проектов не так просто, как это может показаться на первый взгляд. От разработчиков требуется тщательное планирование архитектуры, а от архитектора или тимлида требуется наличие видения системы в целом и чёткая постановка задач разработчикам.
В проектировании DRY тоже имеет место — доступ к конкретному функционалу должен быть доступен в одном месте, унифицирован и сгруппирован по какому‑либо принципу, а не «разбросан» по системе в произвольных вариациях. Этот подход пересекается с принципом единственной ответственности из пяти принципов SOLID, сформулированных Робертом Мартином.
Статья опубликована в 2018 и была обновлена в 2023 году
Тематические статьи
Принцип программирования YAGNI — «Вам это не понадобится»
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться.
В результате разработка ненужных функций не сжигает бюджет проекта, а разработчики не тратят оплачиваемое время на реализацию и дальнейшее сопровождение в реальности ненужного функционала. Избыточный функционал сжигает больше всего ресурсов именно на сопровождении: больше написанного кода — труднее сопровождать и выше вероятность появления «багов». И тут очень уместна поговорка: «лучший код — это ненаписанный код».
методологии разработки
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году
Принцип программирования KISS — делайте вещи проще
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.
Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
методологии разработки
веб-разработка
Статья опубликована в 2019 и обновлена в 2023 году
SOLID — принципы объектно‑ориентированного программирования
SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
веб-разработка
методологии разработки
Статья опубликована в 2019 и обновлена в 2023 году
Стандарты кодирования — залог хорошей сопровождаемости проекта
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение.
Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
методологии разработки
веб-разработка
Статья опубликована в 2014 и обновлена в 2023 году
TDD — разработка через тестирование
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов.
TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
автоматизированное тестирование
тестирование
методологии разработки
Статья опубликована в 2014 и обновлена в 2023 году
MVC — модель‑представление-контроллер
MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем.
В парадигме MVC контроллер определяет способы взаимодействия пользователя с приложением, модель — за слой хранения данных и бизнес‑логику, а представление — за пользовательский интерфейс / формат выходных данных. Модификация каждого из этих компонентов либо оказывает минимальное воздействие на остальные, либо не оказывает его вовсе. Это облегчает понимание логики работы системы и упрощает внесение изменений в кодовую базу.
методологии разработки
веб-разработка
Статья опубликована в 2019 году
Наши услуги
Цифровизация
Формализуем и автоматизируем бизнес-процессы, осуществляем системную интеграцию, разрабатываем и внедряем цифровые решения, повышающие эффективность бизнеса
Разработка
Разрабатываем сложные веб-приложения и сайты. Создаем как отдельные инструменты для бизнеса, так и полноценные цифровые системы по индивидуальным требованиям.
Веб-сервисы и веб‑приложения
Разрабатываем веб-приложения различной направленности и технически сложные веб-сервисы
Разработка корпоративных информационных систем
Cоздаём как комплексные ERP-системы для бизнеса, так и более специализированные информационные системы — CRM, WMS, BPMS, экспертные и аналитические системы, системы поддержки принятия решений, коммуникативные сервисы и многое другое
Поддержка проектов и DevOps
Осуществляем комплексную поддержку ИТ-проектов для обеспечения высокой работоспособности и улучшения продуктовых метрик
Отказоустойчивость
Разрабатываем и сопровождаем комплексные системы, устойчивые к отказу оборудования, отдельных сервисов и целых подсистем.
Быстродействие
Разрабатываем веб-приложения, работающие по-настоящему быстро: генерация страниц осуществляется за доли секунды, а загрузка сайта даже на медленных каналах занимает не более пары секунд.
Высокие нагрузки
Мы создаём сайты и веб-приложения, которые выдерживают десятки тысяч обращений в минуту без сбоев и без снижения скорости работы.
Что значит принцип dry
Принцип DRY (Don’t Repeat Yourself) – означает лишь, НЕ ПОВТОРЯЙТЕСЬ.
Старайтесь избегать в коде повторения каких-то блоков кода.
Так как при дальнейшей разработке, когда нужно будет внести изменение – может оказаться сложным искать в разных частях программы то, что нужно поменять.
Выносите повторяющиеся блоки кода в отдельные методы.
Пример исходного кода
Scanner sc = new Scanner(System.in); int shoot; while (true) < if (sc.hasNextInt()) < shoot = sc.nextInt(); if (shoot < 0 || shoot >9) < System.out.println("Вы ввели неверное число для выстрела."); System.out.println("Введите число от 0 до 9 для выстрела"); continue; >break; > else < String temp = sc.nextLine(); System.out.println("Вы ввели неверное число для выстрела."); System.out.println("Введите число от 0 до 9 для выстрела"); >>
Его стоит улучшить так:
Scanner sc = new Scanner(System.in); int shoot; while (true) < System.out.println("Введите число от 0 до 9 для выстрела"); if (sc.hasNextInt()) < shoot = sc.nextInt(); if (shoot >= 0 && shoot > else < sc.nextLine(); >System.out.println("Вы ввели неверное число для выстрела."); >
Это не идеальный код, его цель продемонстрировать, как иногда принцип DRY может потребовать даже перестройки логики.
Что такое DRY, DIE, KISS, SOLID, YAGNI в программировании
Итак, что же такое термины DRY, DIE, KISS, SOLID, YAGNI и в чем заключаются эти подходы в программировании — рассмотрим их по порядку.
DRY — расшифровывается как Don’t Repeat Youself — не повторяйся, также известен как DIE — Duplication Is Evil — дублирование это зло. Этот принцип заключается в том, что нужно избегать повторений одного и того же кода. Лучше использовать универсальные свойства и функции.
KISS — Keep It Simple, Stupid — не усложняй! Смысл этого принципа программирования заключается в том, что стоит делать максимально простую и понятную архитектуру, применять шаблоны проектирования и не изобретать велосипед.
Принцип SOLID в упрощенном варианте означает, что когда при написании кода используется несколько принципов вместе, то это значительно облегчает дальнейшую поддержку и развитие программы. Полностью акроним расшифровывается так:
- Single responsibility principle — принцип единственной обязанности (на каждый класс должна быть возложена одна-единственная обязанность);
- Open/closed principle — принцип открытости/закрытости (программные сущности должны быть закрыты для изменения но открыты для расширения);
- Liskov substitution principle — принцип подстановки Барбары Лисков (функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. Подклассы не могут замещать поведения базовых классов. Подтипы должны дополнять базовые типы);
- Interface segregation principle — принцип разделения интерфейса (много специализированных интерфейсов лучше, чем один универсальный);
- Dependency inversion principle — принцип инверсии зависимостей (зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций);
Термин YAGNI значит You Ain’t Gonna Need It — вам это не понадобится! Его суть в том, чтобы реализовать только поставленные задачи и отказаться от избыточного функционала.
Top articles
How to display current git branch and colours in terminal.
CSS selectors for test automation — selector types and syntax.
Add jquery library to a website page.
Get in touch
© 2011-2022 Stijit | All rights reserved | Images: Unsplash
Принцип программирования DRY
Если долгое время говорить о программировании или начать разрабатывать приложение с нуля, то рано или поздно человек сталкивается с мыслью о том все ли он делает правильно. Решение многих проблем через IT подход становится все более мейнстримной темой, но не стоит забывать о том, что технологии не стоят на месте. Чтобы оставаться на волне недостаточно просто написать кусочек кода для решения проблемы и забросить его в дальний ящик, потому что с развитием технологий мы замечаем и то, как подход к разным ситуациям тоже частенько меняется. Так как же при этом оставаться конкурентоспособным при малейших или просто катастрофически больших изменениях в “тренде” IT решений?
Ответ довольно простой, потому что все зависит от базы, которую вы получили изучая программирование. Законов в кодинге нет, так же как и четких границ того, чего делать нельзя, а что можно, но есть одна мысль о том “как сделать правильно”. В данной статье мы рассмотрим самый распространенный принцип, но не закон (заметьте), который позволит разработчику урегулировать сложность и общую архитектуру разработки.
Не повторяй за собой!
Если у вас есть основные понятия о разработке и вы понимаете общую идею, то у вас так или иначе есть способность адаптироваться максимально быстро к новым подходам. Проще говоря, намного лучше иметь базу и подстраиваться под ситуацию, чем сделать продукт под определенную ситуацию, не зная базы, что повлечет за собой уйму проблем, когда нужно будет менять подход в корне.
DRY — don’t repeat yourself, что в переводе значит “не повторяй себя”, это принцип программирования, который позволяет добиться высокого уровня сопровождаемости проекта, понятности внедрения новых изменений в проект и облегчает жизни тестировщикам.
Принцип программирования DRY.
Когда вы начнете разрабатывать сайт или любой другой крупный проект, вы скорее всего встретитесь с проблемой реализации логики и его сложностью. Это довольно частое явление и как вы уже догадались, у которого есть решение. Ее идея состоит в том, чтобы разделить сложную задачу на независимые модули, иначе подзадачи, каждая из которых будет отвечать за определенный алгоритм или логику в проекте.
Как это работает?
К примеру, в любом простом проекте по WEB-разработке, мы как правило, соединяем бэкенд часть с фронтендом, а далее с базой данных. Абсолютно на любой странице, требующей связь с базой данных есть компонент, отвечающий за подключение к БД. Этот компонент делится еще на другие компоненты, каждый из которых отвечает за подключение, завершение сессии и т.п. Так вот, именно разделяя систему на такие самостоятельные и отличительные друг от друга компоненты вы начинаете понимать, что каждая из них может самостоятельно отвечать за определенную логику действий.
Важно помнить, что даже после разделения системы на подчасти, все отдельные части должны иметь одно представление.
Когда мы соединяем БД к бэкенд части, то мы получаем код, который по порядку: подключает бэкенд к базе данных, получает нужные данные, отключает соединение по окончанию сессии. Любая из этих действий, повторяемая на каждой странице, является информацией, которая описывает то, как мы делаем то или иное действие, в нашем случае, к примеру, подключение к БД. Перед тем как описывать действие, мы привязываем ее к определенной переменной. Теперь переменная, указывающая на информацию о соединении с БД будет являться представителем этой информации, а переменные, мы знаем, можно использовать в любой части кода, системы и логики при необходимости. И если вдруг возникнет необходимость переписать схему соединения с базой данных, нам достаточно будет изменить/переписать логику информации о подключении, но не их представление в коде.
В идеале это так и работает, часто повторяемую логику действий мы записываем в отдельную информацию, которой мы можем воспользоваться через создание переменной или метода в разных частях проекта, тем самым как бы “инкапсулирует” данные о подключении. Инкапсуляция, заметим, является одной из самых основных принципов Объектно Ориентированного Программирования (ООП). Вы используете метод подключения к базе данных в какой-то части кода, но не видите всей той картины, как именно этот процесс проворачивается внутри системы, потому что вы сейчас работаете с представлением, но не информацией о ней.
Как перестать повторяться?
Если подумать, то можно каждую часть кода разделить на логики и работать только с их представлениями, но не тут-то было. Ведь важнее всего не переборщить с упрощением вашего кода, потому что можно легко запутаться в будущем. Используя принцип DRY в логике проекта, вы должны четко построить архитектуру работы проекта: что с чем связано и как именно, какая логика следует за этой логикой, как именно можно реализовать эту информацию в отдельный метод и т.д.
Чтобы не ошибиться и не забыть важные моменты основной идеи проекта, можно придерживаться самых простых рекомендаций, следуя которым вы и не заметите как будет легко выстраивать логику таким образом, чтобы код не повторялся:
✔ Визуализируйте. Часто можно услышать то, что люди предпочитают рисовать схемы во время планирования или запоминания какой-либо информации. Никто бы не продолжил делать это, если бы это не было действительно эффективным. Рисуя графическую схему программной системы вы сможете легче понять то, на какие компоненты его можно будет разделить так, чтобы суть оставалась одной, а компоненты были связаны логически правильно.
✔ Что и для чего. Разделяя систему на компоненты нужно обязательно ответить себе на просто вопрос о том, почему вы вынесли этот кусочек кода как отдельный и независимый компонент. В запоминании этой логики вам помогут UML диаграммы.
✔ Доступ. Раз мы уже затронули тему об инкапсуляции данных, то нужно сразу отметить то, что перед тем как начать отделять кусочек кода в отдельный компонент так, чтобы им могли пользоваться и на других страницах системы, мы обязательно должны продумать то, какая информация о компоненте может быть доступна внутри другой страницы, а какая нет. В помощь вам слова, как : private и public аксессоры.
✔ Связи. Разделяя код на независимые части/компоненты, все же важно помнить о том, что они независимы друг от друга, но связаны между собой, причем связь между ними должна быть максимально слабой, иначе смысла в выводе этих компонентов как отдельную логику не будет.
Заключение о том,
как не нужно делать для того, чтобы не повторять свой код.
✔ Старайтесь успевать по дедлайнам. Это почти самая главная причина, по которой многие программисты склонны к тому, чтобы просто копировать и вставлять рабочий код где попало. Они просто не успевают по дедлайнам и у них недостаточно времени для того, чтобы вникнуть в логику рабочего процесса в системе.
✔ Будьте внимательны. Если вы повторяете одно и то же действие в разных частях кода/программы — это знак того, что этот кусочек кода заслуживает быть отдельным компонентом.