Принципы разработки

DRY, YAGNI, KISS, SOLID, Occam’s Razor

DALL·E

Принцип DRY (Don’t Repeat Yourself)

DRY призывает избегать дублирования кода в системе. Он подразумевает, что каждый кусок информации (код, данные и т.д.) должен иметь только один, четко определенный “источник правды” в системе.

Некоторые паттерны Принципа DRY:

1. Вынесение общей функциональности в функции или методы: Если определенный блок кода используется в нескольких местах, его следует вынести в отдельную функцию или метод. Таким образом, если необходимо внести изменения, это придется сделать только в одном месте.
2. Использование наследования и полиморфизма: Если у вас есть классы, которые имеют общую функциональность, вы можете использовать наследование и полиморфизм для избежания дублирования кода.
3. Использование шаблонов и абстракций: Создание абстракций и шаблонов позволяет избежать дублирования путем выделения общих паттернов и методов.
4. Использование библиотек и фреймворков: Часто существующие библиотеки и фреймворки уже содержат реализацию общей функциональности, которую вы можете использовать, вместо того чтобы писать свой собственный код.

Принцип YAGNI (You Ain’t Gonna Need It)

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

Применение YAGNI не означает, что разработчики не должны думать про будущие потребности или не строить гибкие архитектуры. Он призывает к разумности и балансу: добавлять функциональность только тогда, когда она действительно требуется, основываясь на реальных данных и обратной связи пользователей.

Принцип KISS (Keep It Simple, Stupid)

Более корректный вариант — «keep it short and simple»

Идея KISS заключается в том, чтобы делать вещи так просто, как это только возможно. Принцип KISS подразумевает, что простота является ключевой ценностью при проектировании, написании кода и создании систем в целом.
Простой дизайн: Системы и интерфейсы следует проектировать с минимальной сложностью и ненавязчивостью.

1. Минимизация сложности: Избегайте лишних деталей и избыточных фрагментов кода, чтобы упростить поддержку и понимание.
2. Избегание избыточности: Добавляйте только необходимую функциональность, чтобы избежать ненужной сложности.
3. Читаемость и понимаемость: Пишите код так, чтобы он был понятным и читаемым для других разработчиков.
4. Эффективное использование ресурсов: Используйте только те инструменты и ресурсы, которые действительно нужны для достижения целей.

Принцип KISS и Принцип “бритвы Оккама”(Occam’s Razor) несколько похожи.

Принцип “бритвы Оккама” —э то философский и научный принцип, котрый гласит: “Не следует умножать сущности без необходимости”, лат. “Entia non sunt multiplicanda praeter necessitatem”.
Но KISS чаще ассоциируется с разработкой программного обеспечения и проектированием интерфейсов, а Принцип “бритвы Оккама” используется в философии, науке и логике для выбора объяснений явлений.

Принцип единственного источника истины (Single Source of Truth)

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

Примеры:

1. Управление состоянием в веб-приложениях: В фреймворках для разработки веб-приложений, таких как React или Redux, используется принцип единого источника истины для хранения всего состояния приложения в одном глобальном хранилище.
2. Управление данными в базах данных, особенно реляционных
3. Управление конфигурациями
4. Управление данными в распределенных системах.

Это принцип сильно перекликается с DRY.

SOLID

S.O.L.I.D. — это аббревиатура, представляющая собой пять дополнительных принципов объектно-ориентированного программирования (ООП) и проектирования, которые помогают создавать более гибкие, расширяемые и легко поддерживаемые системы.

Основные принципы ООП:

• Инкапсуляция
• Наследование
• Полиморфизм

Каждая буква в аббревиатуре SOLID представляет собой отдельный принцип:

1. Принцип единой ответственности (Single Responsibility Principle, SRP): Каждый класс или модуль должен быть ответственен только за одну четко определенную задачу. Перекликается с Single Source of Truth.
   Пример: Если в нам нужно отправлять уведомления пользователям, неплохо организовать отдельный модуль\сервис который займется этим, реализовывать функционал в каждом классе — затруднит поддержку и развитие модуля.
2. Принцип открытости/закрытости (Open/Closed Principle, OCP): Программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для изменения. Это означает, что функциональность можно добавлять, не изменяя уже существующий код.
   Неочевидный пример: Если нужно добавить ломающий функционал в API, это стоит делать в отдельной версии API, оставив старый API тоже в рабочем состоянии.
3. Принцип подстановки Барбары Лисков (Liskov Substitution Principle, LSP): Объекты базовых классов (родителей) должны быть заменяемы объектами их производных классов (потомков) без нарушения корректности программы.
   Неочевидный пример: API должен быть обратно совместим в рамках данной линейки версий.
4. Принцип разделения интерфейсов (Interface Segregation Principle, ISP): Клиенты не должны зависеть от интерфейсов, которые они не используют. Интерфейсы должны быть компактными и содержать только те методы, которые действительно нужны клиентам.
   Неочевидный пример: Если у метода больше 2–3 параметров и большинство их — не обязательные, это тоже не соответствие ISP.
5. Принцип инверсии зависимостей (Dependency Inversion Principle, DIP): Зависимости в коде должны строиться на абстракциях, а не на конкретных реализациях. Высокоуровневые модули не должны зависеть от низкоуровневых модулей. Оба типа модулей должны зависеть от абстракций.