Рефакторинг — это когда ты улучшаешь код, но не меняешь его поведение. Это как навести порядок в комнате: ты убираешь вещи на свои места, но комната остаётся такой же.
Иногда рефакторинг может пойти не так. Вот несколько ситуаций, когда рефакторинг может навредить:

1. Рефакторинг старого кода. Если не планируем развивать старый код, то менять его не стоит.
2. Рефакторинг непосредственно перед релизом. Мелкие правки могут обернуться большими проблемами. Лучше не рисковать.
3. Рефакторинг ради рефакторинга. Пытаемся усложнить свою жизнь на ровном месте. Потратим время для получения сомнительного эффекта
4. Рефакторинг без тестирования. Поправили небольшую опечатку в имени переменной и полностью сломали расчет себестоимости.
5. Рефакторинг "про запас". Прикрутили к запросу на получение данных кэширование. Сейчас оно не используется. Непонятно, понадобится ли оно в будущем.
6. Выделение похожей функциональности в универсальный мегаметод. Такие методы в перспективе превращаются в монстров Франкенштейнов с костылями в виде бесконечных Если Тогда ИначеЕсли КонецЕсли.

Когда рефакторинг действительно нужен?
  
Из доклада можно узнать, когда рефакторинг нужен, а когда нет. Это поможет избежать ошибок и сделать код лучше.