Кратко — определения, конфликты и практический пример.
Определения
- DRY (Don't Repeat Yourself): избегать дублирования логики — одна важная идея/правило должна быть выражена в коде в одном месте. Цель — снизить вероятность рассинхронизации, упростить изменения и тестирование.
- KISS (Keep It Simple, Stupid): делать решения максимально простыми и понятными. Цель — уменьшить сложность и вероятность ошибок, улучшить читаемость и сопровождение.
- YAGNI (You Aren’t Gonna Need It): не реализовывать функционал или обобщения «на будущее», пока они реально не понадобятся. Цель — избегать лишней работы и ненужной сложности.
Плюсы/минусы (суть)
- DRY повышает повторное использование и уменьшает ошибки при изменениях, но может привести к преждевременным абстракциям и сложной структуре.
- KISS уменьшает когнитивную нагрузку и баги, но простые решения иногда приводят к дублированию.
- YAGNI предотвращает избыточную работу и сложность, но при резкой смене требований может вызвать многократный рефакторинг.
Как они конфликтуют
- DRY vs YAGNI: DRY поощряет вынести общую логику в абстракцию. YAGNI говорит: не выносить, если нет явной необходимости. Следствие: преждевременная абстракция (выполнение DRY «на будущее») нарушит YAGNI.
- DRY vs KISS: попытка устранить дублирование может создать сложные обобщения/фабрики/интерфейсы, ухудшающие простоту. То есть соблюдение DRY может нарушить KISS.
- KISS vs YAGNI: обычно сочетаются — оба склоняются к простым решениям сейчас, но KISS иногда допустит небольшое дублирование ради простоты, что нарушает DRY.
Практический пример
Ситуация: в веб-приложении нужно вывести два простых отчёта — продажи по дням и по товарам. Сегодня код для обоих отчётов похож, но немного отличается.
Вариант «следуем DRY»: сразу пишем абстрактный движок отчётов с обобщёнными шагами (фильтрация, агрегация, форматирование), конфигурируемые стратегии, набор интерфейсов и модуль тестов. Результат: меньше дублирования, но сложная архитектура, множество классов, повышенная стоимость понимания и сопровождения.
Вариант «следуем YAGNI и KISS»: реализуем два простых независимых обработчика с минимальным кодом, даже с небольшим дублированием. Если через месяц появится третий отчет, мы рефакторим: извлекаем общую часть тогда, когда появится реальное повторение и требования станут стабильными.
Последствия
- Если заранее сделали DRY-абстракцию, возможно потрачено время на проектирование, тесты и документацию, которые никогда не понадобятся — нарушение YAGNI; архитектура может быть сложной — нарушение KISS.
- Если оставили дублирование ради простоты (KISS+YAGNI), то при появлении множества похожих отчётов придётся рефакторить — временные затраты на перенос и миграцию, но рефакторинг будет целенаправленным и лучше отражающим реальные требования.
Практическое правило баланса
- Предпочитайте KISS + YAGNI на ранних этапах: пишите простой, понятный код даже с небольшим дублированием.
- Вводите DRY через рефакторинг, когда дублирование реально мешает (повторилось >1 раза, изменение в одном месте требует правок в нескольких, есть тесты).
- Оценивайте стоимость абстракции: сложность + риск vs выгода от уменьшения повторений. Делайте небольшие, обратимые рефакторинги и покрывайте тестами.
Конкретное краткое руководство
- Не выносите абстракции «на будущее» — следуйте YAGNI.
- Если абстракция уменьшит реальные затраты на поддержку и поймана тестами — примените DRY.
- Всегда проверяйте, не ухудшает ли абстракция читаемость и простоту (KISS).