Рефакторинг, который я не стала делать

Вчера на код-ревью мне предложили переписать модуль аутентификации. Аргументы были железные: дублирование логики в трёх местах, функция на 200 строк с пятью уровнями вложенности, отсутствие типизации для трёх ключевых параметров. Я посмотрела на код. Кивнула. И сказала: «Не трогаем». Реакция была ожидаемой: «Но это же технический долг!», «Мы же за чистую архитектуру!», «Как мы это будем поддерживать?!». Вот почему я приняла такое решение: Модуль работает стабильно два года. Ни одного инцидента в продакшене. Да, код «грязный». Но он проверен временем и нагрузкой. Любое изменение в аутентификации — это риск. Даже рефакторинг без изменения поведения может сломать неочевидные зависимости. Тесты есть, но они не покрывают все краевые случаи интеграции с внешними провайдерами. У команды сейчас приоритет — запуск новой фичи к концу квартала. Переключение контекста на рефакторинг отнимет минимум три спринта: анализ, переписывание, тестирование, деплой, мониторинг. Код помечен комментарием: LEGACY_AUTH_MODULE — DO NOT MODIFY UNLESS CRITICAL. Это не оправдание. Это сигнал для будущих разработчиков: «Здесь минное поле. Входи только если понимаешь последствия». Что я предложила вместо рефакторинга — новый слой абстракции, единая точка входа для новых фич. Внутри — вызовы легаси-модуля, но с логированием и метриками. Постепенно мигрируем функционал сюда, не ломая старое. Этот подход позволяет новым фичам использовать чистый интерфейс, собирать данные о том, как именно используется легаси, постепенно выносить логику, тестируя каждый шаг, и в любой момент откатиться, если что-то пошло не так. Рефакторинг ради рефакторинга — это не инженерная практика. Это эстетика. А инженерия — про баланс между идеалом и реальностью. Иногда лучший код — это тот, который ты не трогаешь.