Введение:
В повседневной практике Java-разработчика легко утонуть в избыточной архитектуре, дублирующем коде или преждевременной оптимизации. Чтобы избежать этих ловушек, профессионалы опираются на три простых, но мощных принципа:
- DRY — Don’t Repeat Yourself (не повторяйся),
- KISS — Keep It Simple, Stupid (делай проще),
- YAGNI — You Aren’t Gonna Need It (вам это не понадобится).
Эти принципы не являются строгими правилами — это философия разумного проектирования. В этой статье мы подробно разберём каждый из них, покажем, как они работают в связке, и объясним, когда не стоит следовать им слепо.
DRY: Don’t Repeat Yourself
Суть
DRY призывает избегать дублирования логики. Если одна и та же семантическая идея (например, валидация пользователя) реализована в нескольких местах — это риск: изменение требований заставит вас править код везде, а не в одном месте.
DRY касается знаний, а не текста. Одинаковые строки кода — это не всегда нарушение DRY. Главное — одно место ответственности за логику.
Пример нарушения
Рефакторинг
Теперь изменение политики валидации — одна точка правки.
KISS: Keep It Simple, Stupid
Суть
KISS напоминает: чем проще решение, тем оно надёжнее. Не усложняйте архитектуру, если задача может быть решена тривиально.
Простота — это не примитивность, а отсутствие ненужной сложности.
Пример нарушения
Хотя сейчас в системе нужен только email.
Простое решение
Если позже понадобится SMS — тогда и вводите абстракцию. Не раньше.
KISS — это про читаемость, поддерживаемость и скорость разработки.
YAGNI: You Aren’t Gonna Need It
Суть
YAGNI — самый провокационный из трёх. Он гласит: «Не реализуйте функциональность, пока она вам реально не нужна».
Этот принцип направлен против предварительной оптимизации и предварительного проектирования под гипотетические будущие сценарии.
Пример нарушения
Вы разрабатываете микросервис для обработки заказов. Ещё до первого релиза вы:
- добавляете поддержку нескольких валют,
- внедряете кэширование через Redis (хотя нагрузка — 10 запросов/день),
- реализуете паттерн CQRS и Event Sourcing,
- пишете адаптеры под PostgreSQL, MySQL и MongoDB.
А на деле: вам нужен только один endpoint, одна валюта и одна БД.
Применение YAGNI
Реализуйте только то, что требуется сейчас. Документируйте ограничения:
«Сервис поддерживает только рубли. Мультивалютность будет добавлена по запросу».
Так вы экономите:
- время разработки,
- риски багов,
- сложность тестирования и развёртывания.
YAGNI ≠ «никогда не думать о будущем». Это «не платить сейчас за то, что может никогда не понадобиться».
Когда эти принципы можно (и нужно) нарушать?
- DRY: если похожие участки кода решают разные бизнес-задачи и могут развиваться независимо (это coincidental duplication, а не true duplication).
- KISS: если требования явно требуют расширяемости (например, фреймворк или библиотека для внешнего использования).
- YAGNI: если вы точно знаете, что функция понадобится через 2 недели (и это подтверждено бэклогом или контрактом).
Но в 95% случаев — следуйте трём принципам.