Рефакторинг - это чаще прокрастинация

Открываешь код, чтобы добавить простую фичу. Видишь функцию на 200 строк. "Просто быстренько подправлю". Три дня спустя переписал половину проекта, а фича так и не готова, задача не выполнена. Рефакторинг как побег Новая задача - это неопределенность, надо думать и принимать решения, рисковать и ошибаться. А рефакторинг? Это понятно и безопасно. Убрать дублирование, выделить метод, переименовать переменные. Когда точно знаешь, что делать. Чистая иллюзия продуктивности. Неудобная математика Большинство кода живёт меньше года. Его или удалят, или перепишут, или продукт закроют. И часто получается так, что оптимизируешь то, что никто больше не увидит. Пользователю всё равно, как выглядит код. Ему нужна работающая кнопка, а не красивая архитектура. А вот когда рефакторинг оправдан: - Код реально мешает добавлять фичи - В этом месте постоянно баги - Производительность проседает (и это видно в метриках) Все остальное - способ почувствовать себя умным, не решая реальных задач. Правило, которое работает Рефактори только то что трогаешь по задаче. Добавляешь метод в класс - можно привести в порядок этот класс. Но не трогать соседние файлы. Даже если там АД.

Лучший код - тот, который работает и делает деньги. Даже если он неидеальный.

PS: Этот пост можно было сделать короче и структурнее. Но я решил просто составить его из своих заметок и не стал рефакторить 🙂 33/100 Telegram