Когда стоит продолжать дублировать код?

Когда стоит продолжать дублировать код? (Rule of Three)

Отличный вопрос, потому что стремление к DRY (Don't Repeat Yourself) может привести к над-инжинирингу. Есть хороший принцип: Rule of Three.

Rule of Three (Правило трёх)

1-й раз: просто скопируй и используй 2-й раз: дублируй спокойно, это нормально 3-й раз: рефакторь и избегай дублирования

Идея: Не торопись рефакторить после первого дублирования. Дождись третьего повтора, чтобы понять общую закономерность.

Пример: Валидация email

После 1-го использования: Копируешь валидацию в users.service.ts

После 2-го использования: Копируешь в posts.service.ts — это OK

После 3-го использования: Создаёшь хелпер validators/email.ts с функцией isValidEmail

Когда НЕ стоит рефакторить сразу

1. Неизвестные требования (Speculative Design)

• Не рефакторим "про запас"
• Код должен решать текущую задачу
• Не нужно абстракция для будущих случаев, которых может не быть

2. Разные контексты

• Даже если код выглядит одинаково, контекст может быть разным
• auth требования к паролю — одни
• payment требования к паролю — могут быть другие
• Не объединяй в одну функцию

3. Слабые связи (Loose coupling)

• Лучше иметь независимые валидаторы (validateUser, validatePost)
• Чем одну функцию validate для всех

Когда СТОИТ рефакторить сразу

1. Один и тот же паттерн в одном месте

• Если копируешь одну логику 3 раза в одной функции
• Используй map/loop, не копипасте

2. Явные ошибки при копировании

• Если забыл в одном месте обновить логику при изменении
• Рефакторь сразу в одну функцию

3. Высокий риск рассинхронизации

• Если изменение требует обновления в 5+ местах
• Это признак того, что нужна абстракция

YAGNI vs DRY

YAGNI (You Aren't Gonna Need It): Не добавляй функционал на будущее DRY (Don't Repeat Yourself): Не повторяй код

Часто конфликтуют:

• DRY + YAGNI = над-инжиниринг (абстрактная функция для всех сценариев)
• Компромисс = простой код сейчас, рефакторинг после 3-го повтора

Когда дублирование ПОЛЕЗНО

1. Микросервисы / разные проекты

• Разные git repo
• Разные версии могут быть нужны
• Снижает dependency между сервисами

2. Performance-critical code

• Inline код для оптимизации (если нужна скорость)
• Дублирование логики — компромисс за performance

3. Обучение и примеры

• Документация может содержать повторение кода
• Примеры должны быть самостоятельными

Мой подход

После 1-го раза: скопирую без раздумий После 2-го раза: ещё скопирую, но с пометкой в комментарии После 3-го раза:

• Смотрю, действительно ли закономерность
• Если да — рефакторю в общую функцию
• Если контексты разные — оставляю дублирование

Если ошибка в дублировании: рефакторю сразу!

Итог

Дублирование кода — не всегда плохо. Важно:

• Баланс между DRY и простотой
• Rule of Three для правильного момента рефакторинга
• Контекст — один ли это проект или разные микросервисы
• Риск ошибок — если высокий, рефакторь сразу
• Production опыт — код, который менялась много раз, нужна абстракция