Как планируется время на рефакторинг
Что проверяют
Умеете ли вы договориться о рефакторинге с командой и продактом, а не просто любите чистый код. Слушают, как вы обосновываете время и как не ломаете прод по дороге. Следом обычно просят пример: что именно переделали, сколько это заняло и что дало.
Как отвечать
Покажите несколько уровней планирования и привяжите их к своему опыту:
- по ходу задачи: мелкая чистка кода, который вы всё равно трогаете, входит в оценку фичи. Сначала подготовительный рефакторинг, чтобы изменение легло просто, потом сама фича;
- технический долг в бэклоге: крупная переделка оформляется задачей с понятной выгодой. «Этот пакет меняют в каждом втором релизе, и каждое изменение ломает соседний сервис» продаётся лучше, чем «код некрасивый»;
- выделенная доля: часть команд закладывает постоянную долю спринта на долг. Цифру называйте свою, а не из статьи;
- приоритет: смотрите на пересечение частоты изменений и числа багов. Код, который никто не трогает, может подождать.
Для Go стоит назвать опору, без которой рефакторинг рискован: тесты с go test -race, покрытие через -cover, golangci-lint с линтерами сложности вроде gocognit, бенчмарки и benchstat, если меняется горячий путь. Крупные переделки режьте на маленькие пулл-реквесты, а смену реализации прячьте за интерфейсом, чтобы старая и новая версии какое-то время жили рядом.
Пример из практики со своими цифрами сильнее любого перечня. Если своего крупного рефакторинга не было, расскажите про небольшой и честно скажите, как действовали бы с большим.
Где спотыкаются
Предлагают «отдельный спринт на рефакторинг». Бизнес редко на это соглашается, а долг за это время успевает нарасти в других местах.
Не умеют перевести пользу в понятные продакту величины: время на изменение, число инцидентов, скорость онбординга новых людей.
Начинают рефакторинг без тестов на текущее поведение и узнают о поломке уже на проде.