Как определить, какой код стоит рефакторить и почему

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

Умеете ли вы выбирать, где рефакторинг окупается, и объяснять это аргументами для бизнеса, а не вкусом. Следом обычно просят пример: что вы рефакторили, как убедились, что ничего не сломали, и сколько времени это заняло.

Как отвечать

Главный критерий это цена изменения. Рефакторить стоит код, который часто меняют и в котором при этом тяжело работать. Стабильный некрасивый пакет, который никто не трогает годами, может подождать.

Как находить такие места:

• горячие точки: пересечение частоты изменений и сложности. Частоту даёт git log по файлам, сложность дают линтеры;
• метрики через golangci-lint: gocyclo и gocognit для сложности функций, dupl для дублирования, funlen и nestif для длинных функций и глубокой вложенности;
• скопление багов: если половина инцидентов за квартал касается одного пакета, это сигнал сильнее любой метрики;
• трудность тестирования: функция тянет глобальное состояние, ходит в сеть и базу без интерфейсов, и её невозможно проверить без поднятия окружения.

Признаки, характерные именно для Go: пакеты utils и common, куда складывают всё подряд; огромные интерфейсы на стороне реализации вместо маленьких на стороне потребителя; функции без context.Context, которые нельзя отменить; горутины без понятного момента завершения.

Как делать безопасно: сначала тесты, фиксирующие текущее поведение, потом маленькие шаги и отдельные PR для рефакторинга и для новой функциональности. Если цель в производительности, замеряете go test -bench до и после и сравниваете через benchstat.

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

Называют устаревшие инструменты: golint давно заархивирован, а go vet ищет подозрительные конструкции, а не кандидатов на рефакторинг. Сегодня стандарт это golangci-lint и staticcheck.

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

Рефакторят без тестов и смешивают это с изменением логики в одном PR. Ревьюер не может понять, какое изменение поведения намеренное.