Как поступать, если для улучшения задачи нужно менять архитектуру и тратить больше времени

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

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

Как отвечать

Покажите порядок действий, а не позицию «архитектура важнее всего»:

• понять цену текущего устройства: чем оно мешает. Каждая фича в модуле требует правок в пяти местах, растёт число багов, страница медленная по Web Vitals (LCP, INP) или раздулся бандл;
• оценить варианты: сделать задачу в текущей архитектуре и завести техдолг отдельной задачей с оценкой, отрефакторить только затронутую часть или провести полную переделку. У каждого варианта свой срок и риск;
• вынести на обсуждение: тимлиду и продакту с цифрами, а не с аргументом «так чище». Решение о сроках не принимает разработчик в одиночку;
• менять поэтапно: паттерн strangler fig, новый код рядом со старым, переключение фича-флагом, небольшие PR. Например, переводить стейт-менеджмент экран за экраном, а не всё приложение разом;
• страховать тестами: перед рефакторингом закрыть поведение тестами на Vitest или Jest с Testing Library и сквозными сценариями на Playwright;
• зафиксировать решение: короткий ADR о том, почему выбрали этот путь.

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

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

Молча начинают переделывать архитектуру в рамках фичи. Срок сорван, а PR на три тысячи строк никто не может нормально отревьюить.

Аргументируют вкусом: «Redux устарел», «нужен FSD». Без измеримой пользы для продукта такие доводы не работают.

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