Опишите опыт сложного рефакторинга на проекте
Что проверяют
Отличаете ли вы рефакторинг от переписывания и умеете ли менять живой код, ничего не сломав. Заодно смотрят, можете ли объяснить, зачем это было нужно продукту: без ответа на такой вопрос история звучит как работа ради удовольствия.
Как отвечать
Расскажите одну историю целиком, а не список принципов. Начните с боли, которая заметна снаружи: модуль, в который боятся заходить, бизнес-логика внутри обработчиков запросов, круговые импорты, разбор ответа внешнего сервиса, продублированный в пяти местах.
Дальше главное, ради чего вопрос и задают, это безопасность изменений:
- сначала тесты на текущее поведение, включая странное: они фиксируют то, что есть, а не то, что задумывалось;
- маленькие шаги с зелёным прогоном после каждого, а не ветка на три месяца;
- аннотации типов и статическая проверка как страховка в динамическом языке;
- параллельный прогон старой и новой реализации со сравнением результатов, если кусок критичный;
- флаг переключения, чтобы откат был мгновенным.
Про архитектурную часть достаточно честно: что разделили, почему именно так, что осталось несделанным и почему это терпимо. И если называете выигрыш, скажите, чем мерили: профилировщиком, временем ответа, числом инцидентов после.
Где спотыкаются
Называют рефакторингом переписывание с нуля. Долгоживущая ветка расходится с основной, сливается тяжело, а пользователи всё это время не получают ничего.
Начинают без тестов. Тогда фраза о том, что ничего не сломалось, это вера, а не факт, и на вопрос о покрытии до изменений ответа обычно нет.
Приписывают рефакторингу ускорение в процентах. Сам по себе он производительность не улучшает, и если цифра всё же прозвучала, спросят, какое конкретно узкое место убрали и чем измеряли.