Как часто происходит рефакторинг кода

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

Встроен ли рефакторинг в вашу ежедневную работу или вы ждёте отдельного «спринта на техдолг». Интервьюер хочет услышать, как вы меняете код безопасно и как объясняете бизнесу, зачем на это тратить время. Следом часто просят пример крупного рефакторинга в Go и спрашивают, как вы убедились, что ничего не сломалось.

Как отвечать

Правильный ответ на «как часто»: постоянно и маленькими шагами. Рефакторинг это изменение структуры без изменения поведения, и удобнее всего делать его перед задачей, которую текущий код мешает решить: сначала упростить место, потом внести изменение. Каркас:

• страховка тестами: табличные тесты на поведение до правки, прогон с go test -race, для функций разбора входных данных фаззинг через go test -fuzz;
• отдельные коммиты: рефакторинг и изменение логики не смешиваются в одном PR, иначе ревьюер не отличит перенос кода от новой ошибки;
• инструменты: переименование и перенос через gopls в IDE, gofmt -r для механических замен, go vet, staticcheck и golangci-lint в CI;
• типичные для Go правки: разбить пакет-свалку utils, убрать интерфейс с единственной реализацией, объявленный у поставщика, а не у потребителя, заменить interface{} и копии функций дженериками, спрятать внутренности в internal/;
• крупные изменения: оформляются задачей с обоснованием, например новая фича требует правки в десяти местах, и идут итерациями за фасадом или флагом, а не одним большим слиянием.

Опирайтесь на свой пример: что мешало, как разбили на шаги, чем проверяли.

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

Отвечают «раз в квартал выделяем неделю на рефакторинг». Редкие крупные чистки говорят о том, что в обычной работе код не улучшают и долг копится.

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

Переписывают ради вкуса: вводят слои и интерфейсы по образцу Java, хотя в Go принято держать абстракции маленькими и объявлять интерфейс там, где он используется.