Бывают ли конфликты при использовании DRY и KISS принципов

Что проверяют

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

Как отвечать

Да, конфликтуют, и это нормально. DRY в исходной формулировке из «Программиста-прагматика» говорит о знании: у каждого правила должно быть одно авторитетное место. KISS требует, чтобы код читался без усилий. Конфликт возникает, когда DRY применяют к похожему тексту кода, а не к общему знанию.

Типичный пример: две карточки, в каталоге и в корзине, сливают в одну <ProductCard>. Через полгода у неё пропсы variant, compact, showPrice, hideActions и десяток условий в разметке. Код не повторяется, но любая правка ломает соседний экран.

Каркас решения:

• правило трёх: абстракция появляется на третьем повторе, когда уже видно, что именно общее;
• случайное сходство: если два куска кода меняются по разным причинам, это не дублирование, объединять их не нужно;
• композиция вместо флагов: общий каркас плюс children, слоты или составные компоненты вместо булевых пропсов;
• что выносить обязательно: бизнес-правила (валидация, формат цены, права доступа), дизайн-токены, работу с API. Их расхождение даёт баги;
• что можно повторять: разметку разных экранов и тесты. В тестах читаемость важнее, там работает принцип DAMP.

Хорошо сослаться на Сэнди Метц: дублирование обходится дешевле неправильной абстракции. Подход AHA (Avoid Hasty Abstractions) у Кента Доддса про то же.

Где спотыкаются

Отвечают, что конфликта нет, «надо просто писать хорошо». Интервьюер ждёт, что вы назовёте цену каждого принципа и условие, при котором один важнее другого.

Считают любое совпадение строк нарушением DRY и строят универсальный компонент с конфигом на все случаи. Это и есть неправильная абстракция.

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