> Как планируется время на рефакторинг (Go)

Короткий ответ

Рефакторинг планируется как отдельный вид работы, а не как побочная задача. На senior-уровне его привязывают к конкретному риску, метрике или замедлению разработки. Время выделяется заранее: либо фиксированный процент capacity в каждом спринте, либо отдельный эпик с оценкой. Приоритет определяется через trade-off между скоростью фич и стоимостью поддержки.

Пример по STAR

Ситуация: В Go-сервисе обработки платежей накопилась высокая связанность: бизнес-логика смешана с HTTP-хендлерами и SQL-запросами. Из-за этого каждая новая фича занимала в два раза больше времени, а тесты были медленными и флаки.

Задача: Нужно было снизить стоимость изменений без остановки поставки фич. Требовалось обосновать выделение времени на рефакторинг перед продуктом.

Действие: Я предложил стратегию strangler fig. Мы выделили 20% capacity каждого спринта на рефакторинг, а крупные изменения оформляли отдельным эпиком. Сначала вынесли работу с БД в repository-слой, затем выделили usecase-слой и покрыли его unit-тестами. Для каждого шага определили метрику: время добавления новой фичи, покрытие тестами, p95 latency. Прогресс показывали на общем стендапе раз в две недели.

Результат: Через три месяца время на добавление типовой фичи сократилось с пяти до двух дней. Покрытие тестами выросло с 35% до 70%, количество инцидентов на релиз уменьшилось вдвое. Продукт согласился сохранить 20% capacity на рефакторинг как постоянную практику.

Как отвечать на собеседовании

Покажите, что вы не просто "любите чистый код", а управляете техническим долгом как риском для бизнеса. Назовите конкретный механизм: процент capacity, отдельный эпик, правило бойскаута или бюджет на техническое здоровье. Объясните, как вы измеряете эффект: cycle time, количество инцидентов, сложность изменений, latency. Расскажите, как договариваетесь с продуктом и какие trade-off принимаете. Упомяните, что рефакторинг без тестов и метрик - это риск, а не улучшение.

Что проверяет интервьюер

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

Типичные ошибки

Говорить "мы просто рефакторим, когда есть время" - это показывает отсутствие системы. Обещать большой рефакторинг целиком без промежуточных результатов. Не связывать рефакторинг с метриками и бизнес-эффектом. Делать изменения без тестов и возможности отката. Игнорировать переговоры с продуктом и ставить его перед фактом. Путать рефакторинг с переписыванием с нуля. Не учитывать, что в Go плохо выделенные интерфейсы и большие пакеты усложняют поддержку.