В индустрии термин рефакторинг давно мутировал. Часто под ним подразумевают всё что угодно, кроме самого рефакторинга: оптимизации, перепроектирование, добавление фич и т. д.

Разработчики пытаются согласовать с менеджерами выделение времени на рефакторинг — тем самым перекладывая ответственность за качество системы на бизнес. А бизнесу, в общем-то, сложно понять, зачем тратить время на «улучшение того, что уже работает». Это порождает конфликты, которые ни к чему хорошему не приводят.

Мартин Фаулер даёт хорошее определение:     Рефакторинг — это изменение внутренней структуры кода без изменения его внешнего поведения.

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

Не нужно “продавать” рефакторинг, тесты и другие технические практики бизнесу. Это естественная часть работы разработчика. Если вы продаёте рефакторинг, вы даёте возможность его не купить и перекладываете ответственность за качество на других.

Вместо этого — включите рефакторинг в повседневную рутину. Это даст:

• Постоянное улучшение архитектуры кода
• Упрощение понимания кода
• Снижение количества багов
• Повышение скорости разработки

Мне близко правило бойскаута:     Оставь место стоянки чище, чем оно было до твоего прихода.

Поэтому, если вы затрагиваете какой-то участок кода в рамках своей задачи — улучшайте его.