Что такое DRY

DRY расшифровывается как Don't Repeat Yourself. На интервью важно не остановиться на фразе "не повторяй код". Точнее сказать так: не дублируйте знание о системе.

Знанием во frontend-проекте может быть правило валидации, формат денег, путь к API, список статусов заказа, способ нормализовать ответ сервера, логика доступа к кнопке или правила аналитики. Если такое знание скопировано в несколько мест, при изменении одно место легко забыть. В итоге пользователь видит разные ошибки, разные ограничения формы или неактуальный UI.

Хорошая короткая формулировка для интервью:

DRY для меня не про механическое удаление похожих строк. Это про один источник правды для правила или логики. Я выношу повторение, когда оно имеет один смысл и должно меняться одинаково.

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

Плохой вариант:

// Плохо: одно правило размазано по разным компонентам
function SignupForm({ email }: { email: string }) {
  const isValid = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  return isValid ? null : <p>Введите email</p>;
}

function ProfileForm({ email }: { email: string }) {
  const isValid = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  return isValid ? null : <p>Email указан неверно</p>;
}

Более безопасно вынести правило и переиспользовать его:

export function isValidEmail(email: string) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

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

Повторяющиеся запросы тоже часто хочется вынести. Это нормально, если вы не выкидываете состояния, которые нужны экрану.

Плохой вариант:

function UsersPage() {
  const [users, setUsers] = useState<User[]>([]);

  useEffect(() => {
    fetch("/api/users")
      .then((response) => response.json())
      .then(setUsers);
  }, []);

  return <UserList users={users} />;
}

Что сломается: при медленной сети пользователь видит пустой список без объяснения. Ошибка запроса пропадает. При смене параметров старый ответ может перезаписать новый. Если компонент размонтировался, запрос все равно завершится и попробует обновить состояние.

Безопаснее выносить не просто fetch, а понятный контракт для UI: data, loading, error, пустое состояние и отмену через AbortController. Тогда DRY убирает копипасту, но не прячет поведение, от которого зависит экран.

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

Но похожий код не всегда надо объединять. Две карточки товара и профиля могут иметь похожую верстку, но разные причины изменения. У товара появится цена, скидка и состояние корзины. У профиля появится приватность, роль и статус подписки. Общая карточка с десятком пропсов может стать хуже, чем два понятных компонента.

Хорошая формулировка на ревью звучит спокойно и проверяемо:

Здесь повторяется не просто JSX, а правило расчета доступности кнопки. Если оно изменится, придется править три места. Я бы вынес это в функцию или хук и добавил тест на основные состояния.

И другая ситуация:

Эти компоненты похожи визуально, но отвечают за разные сценарии. Я бы пока не объединял их в общий компонент. Если после еще пары задач паттерн станет стабильным, можно вынести общую часть.

Такой ответ показывает зрелость. Вы не применяете принцип автоматически. Вы оцениваете последствия для изменений, тестов и читабельности.

Если вас спрашивают "Что такое DRY", отвечайте в три шага. Сначала дайте определение: один источник правды для одного знания. Потом приведите frontend-пример: валидация, хук, компонент, константы API, обработка запроса или форматирование данных. Затем добавьте ограничение: случайное сходство кода не всегда надо абстрагировать.

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