Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 22
Закреплённые комментарии
Хорошие тезисы.
рефакторинг — это преобразование кода из одной формы в другую с полным сохранением поведения
Ключевой вопрос, что делаем с обратной совместимостью?
Если сохраняем, то переименования нужно запрещать (и часть примеров из статьи надо переписывать). Новое можно только добавлять. А удаление старого-ненужного это тогда не рефакторинг, а энхансмент.
Если же обратная совместимость не интересует, тогда многие церемонии можно упростить (ломать так ломать).
Здесь я конечно имею ввиду вырожденные примеры, чисто в образовательном смысле. На практике все разумеется будет по ситуации.
Рефакторинг — это не уборка, это хирургия на живом коде.
Говной нейросетью воняет, типичный паттерн "это не Х, это Y". Автор, зачем вы кормите хабр нейрослопом?
Очень странное отношение. Llm это лишь инструмент, не больше чем когда то автокомплит например. Вопрос в том чьи идеи и опыт вы вкладываете свои или нет.
Как бы да, глаз режет уже такое, но даже если автор прогнал свои мысли через Клода или гпт для редактуры и структурирования - какая разница? В статье абсолютно правильный выстраданный на практике инженерный опыт, форма подачи для чтения удобная
Хорошие тезисы.
рефакторинг — это преобразование кода из одной формы в другую с полным сохранением поведения
Ключевой вопрос, что делаем с обратной совместимостью?
Если сохраняем, то переименования нужно запрещать (и часть примеров из статьи надо переписывать). Новое можно только добавлять. А удаление старого-ненужного это тогда не рефакторинг, а энхансмент.
Если же обратная совместимость не интересует, тогда многие церемонии можно упростить (ломать так ломать).
Здесь я конечно имею ввиду вырожденные примеры, чисто в образовательном смысле. На практике все разумеется будет по ситуации.
"ломать так ломать" именно в моей праактике часто выходило очень сильно боком. Особенно на проектах с запутанной и часто неполностью документированной логикой. Поэтому в плане рефакторинга приобрел "осторожные" привычки.
Тут можно попробовать назвать разные ситуации разными словами. Например рефакторинг оставить за чисто внутренними изменениями, ближе к гигиеническим, как зубы почистить. Поправить названия, чтобы соответствовали нейминг конвеншен - ок, но только не в шареных модулях и не публичных контрактах. А более глобальные переделки назвать например реконструкцией (буквально когда перестраивается каркас на котором могут сидеть ваши коллеги).
Публичные контракты это отдельная боль, а еще интереснее когда клиенты начинают пользовать апи не предназначенное для интеграции и вот вы внезапно имеете "публичный интерфейс", о котором даже можете долго не знать
Если в кодовой базе не разграничен оунершип - кто за что отвечает, - то она вся целиком становится одним большим публичным контрактом, со всеми вытекающими. Но это фиксится только на уровне процессов - научить уважать частную собственность и не лазить через временные ограждения, которые рабочие поставили на время ремонта.
Лучше составить таблицу в которой будет представлено количество работы с кодом, файловой системой и уровни ошибок - системное проектирование, синтаксис, доступ (не найдено) в ответ на количество действий разработчика.
Добавил бы главный критерий: рефакторинг нужен только там, где текущая реализация уже создаёт реальную проблему. Рефакторить ради рефакторинга → плохая инженерная практика.
Обычно больше пользы даёт точечная работа по самым нагруженным и болезненным местам системы, чем попытка “оздоровить всё сразу”.
Плюс рефакторинг → вещь ювелирная: более красивый вариант кода не всегда быстрее и надёжнее в реальном исполнении. Это проверяется не вкусом разработчика, а практикой, нагрузкой и фактическим поведением системы.
И да смешивать рефакторинг с изменениями поведения просто нельзя. А сами шаги должны быть максимально маленькими, изолированными и откатными.
Казалось бы, очевидно. Но на практике — «ну тут же явно дублирование, вынесем» — и через час выясняется, что это дублирование было намеренным: два похожих блока обрабатывают тонко разные случаи, разница — в одном условии, которое не сразу видно
А почему это нигде не помечено? Ни в комментариях там, ни в документации? Либо, наоборот, почему ты не посмотрел, если помечено? :)
У каждой такой ошибки своя цена, и если цена невысокая, то и париться с ними не нужно и можно делать "всё и сразу" без идеальных подходов и методик.
Мои скромные 2 копейки: рефакторить надо всё и всегда. Плевать на обратную совместимость. Мерджить сразу, а не мариновать. Тупо высший приоритет (да и на самом деле надо девелопить напрямую в мастер).
Если мариновать, то случится самое плохое - народ будет бояться рефакторить. Для себя я делаю так - потрогал файл - поправь всё что можно, порефактори, порефактори всё с чкс оно связано. Получилось 200 файлов? Закомить.
Главное правило рефакторинга: не трогай то, что не мешает жить
Если легаси-модуль работает стабильно, покрыт тестами и в него не нужно вносить изменения ближайшие полгода - забей на его "некрасивость". Рефакторить нужно только тот код, который активно меняется и тормозит поставку новых фичей
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
# 10 ошибок рефакторинга