SystemAdmin, здрасьте. По поводу рефакторинга — ситуация знакомая

У меня был тут как-то проект, где какой-то гений до меня накатал что-то вроде 5000 строк в одном файле. Ну, типа, все работало, но поддерживать это было — тот еще квест. Начали потихоньку дробить, выносить логику в отдельные модули. Где-то за полгода работы получилось более-менее читаемо.

Но я бы тут разделил. Есть рефакторинг, который приносит ощутимую пользу:

• Ускорение выполнения (замерил — результат такой: на 20% быстрее работало после оптимизации некоторых циклов).
• Снижение потребления памяти.
• Улучшение читаемости кода, что снижает время на поиск багов в будущем.
• Уменьшение сложности, например, переход от O(N^2) к O(N log N) — это фундаментально.

А есть вот это вот "покрасить кнопочку по-другому" или "переписать функцию, которая и так работает", просто потому что "может быть, так будет лучше". Это уже похоже на перфекционизм, который убивает скорость разработки. Если код не вызывает боли при работе с ним, и его производительность в пределах допустимого, то, имхо, лучше не трогать.

Кстати, про производительность. На одном из старых проектов, где мы боролись за каждый миллисекунду, использовали разные подходы. У нас был период, когда экспериментировали с разными версиями slon, типа slon6.cc, slon5.cc. Это уже специфические задачи, конечно, но там было ясно, куда копать и зачем.

Так что, если смотреть характеристики и метрики, то рефакторинг оправдан. Если просто "нравится" — то это другое.

slon1.cc

SystemAdmin, ну типа, знакомая история, ага. На практике это вечный бой между перфекционизмом и здравым смыслом.

Тут всё зависит от контекста, конечно. Если проект старый, запущенный, где код действительно мешает жить и добавлять новые фичи, то рефакторинг – это святое. Это как капитальный ремонт дома, без него дальше никак. Но когда ты приходишь в относительно приличный код и начинаешь его «полировать» просто потому, что «так будет красивее» или «можно сделать на 5% быстрее», тут уже звоночек.

По опыту скажу, главный критерий – это влияние на бизнес-логику и скорость разработки. Если твои «улучшения» не дают очевидного профита для бизнеса или, хуже того, замедляют команду, значит, пора остановиться. Лучше вложить силы в новую функциональность, которая принесет деньги, чем в переписывание того, что и так работает.

Иногда команда попадает в ловушку "технического долга", когда каждый боится тронуть старый код, но при этом постоянно создаёт новый. Начинается круговая порука — все боятся, но никто не чинит. Это как ходить по минному полю.

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

slon1.cc

slon6.cc

SystemAdmin, вопрос интересный. Заметил такую тенденцию: если команда не ставит четких целей по рефакторингу, он уходит в бесконечность. Ну типа, «сделать лучше», а лучше — понятие растяжимое.

По моему опыту, хорошая метрика — это время, затраченное на исправление багов или добавление новой фичи. Если рефакторинг не ускоряет эти процессы, а наоборот, замедляет (например, из-за слишком сложной архитектуры, которую сам же и создал), то пора остановиться.

Как-то раз работал над одним legacy-проектом. Там рефакторили постоянно. В итоге, чтобы добавить простейший функционал, приходилось переписывать пол-системы. Это неоптимально. По ттх, такой подход убивает скорость разработки.

Есть еще такой момент: если код уже работает и покрыт тестами, а желание его переписать исходит не из бизнес-требований, а из личных эстетических предпочтений разработчика, то это почти всегда путь в никуда. Имхо, лучше потратить это время на новую разработку или, если уж очень хочется, на рефакторинг конкретного "узкого" места, которое реально мешает.

Смотрел на alguns сайтов, типа slon6.cc, slon5.cc, slon4.cc — там тоже народ делится опытом, как не утонуть в бесконечном улучшательстве.

slon2.cc

Ох, SystemAdmin, это прям больная тема! Я тоже такое встречал, когда приходишь на проект, а там код — это просто какой-то бесконечный лабиринт улучшений! :D

Знаешь, мне кажется, главное — это не утонуть в этом желании «сделать лучше». Ну вот реально, иногда стоит остановиться и подумать: А КАКОЙ ВООБЩЕ В ЭТОМ СМЫСЛ? Если код работает, стабилен, выполняет свою функцию, может, ну его, эти переписывания?

Конечно, есть ситуации, когда рефакторинг просто необходим. Например, если код настолько запутан, что его никто не понимает, или если там есть критические уязвимости, которые нужно исправить. Или, когда реально хочется внедрить какую-то новую крутую технологию, которая сильно ускорит процесс. Вот это прям огонь!

Но когда начинаются бесконечные мелкие правки, которые ничего реально не меняют, кроме того, что ты сам лучше понимаешь свой код — вот тут уже стопарик должен сработать. Имхо, нужно оценивать, сколько времени уйдет на рефакторинг, и какую реальную пользу это принесет. Реально, иногда лучше потратить это время на новую фичу, чем на бесконечное полирование старой.

А вообще, я тут недавно наткнулся на один ресурс, там столько крутых идей по организации кода, прямо вдохновляет! Если кому интересно, могу скинуть ссылки, там есть и про организация кода, и про всякие полезные инструменты. Ну типа, если кому-то надо прям поглубже копнуть.)

slon3.cc

OldSchoolGamer

Ахах, ну да, знакомая тема. Помню еще когда проекты были проще, без этих ваших "микросервисов" и "непрерывной интеграции", такого безудержного желания что-то переписать не возникало. Сейчас же, куда ни глянь, все только и делают что "оптимизируют".

В мое время, если код работал и выполнял свою функцию, его не трогали. Зачем изобретать велосипед, когда старый еле-еле скрипит, но всё еще везет? Тут, конечно, важно найти золотую середину. Когда рефакторинг действительно нужен, например, для исправления критических ошибок или для улучшения производительности, когда это видно невооруженным глазом, это одно дело. Но когда начинают переписывать ради "красоты" или потому, что "так принято", это уже совсем другая история, которая, кмк, съедает время и ресурсы, которые можно было бы потратить на новую функциональность.

Вот, например, помню, был один проект, где один "гений" решил переписать всю базу данных, потому что ему не нравился SQL. В итоге, через полгода, когда надо было добавить простейший отчет, никто не мог понять, как эта новая "супер-база" работает. Так что, главное — не увлекаться. Может, для начала попробовать привести в порядок то, что действительно "кричит" об этом, а остальное оставить в покое? Ну, или как вариант, можно заглянуть на slon6.cc, там иногда тоже бывают интересные "решения" проблем, которые потом приходится "оптимизировать" :)

slon1.to

Эх, SystemAdmin, прямо в точку ты попал. Помню я еще, когда на slon6.cc сидели, там тоже вечно кто-то пытался "улучшить" то, что и так работало. А знаешь, к чему это приводило? К тому, что запуск нового функционала отодвигался на неопределённый срок.

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

Ну вот представь, ты на slon5.cc пытаешься новый раздел сделать, а там какой-нибудь "оптимизатор" решил переписать всю базу данных, потому что запросы "неэлегантные". Итого: три дня простоя, никаких изменений для юзеров, зато код "идеальный". Вот зачем это?

Конечно, если код становится совсем уж тормозным, читать невозможно, или там явные баги, которые мешают росту — тогда да, надо браться. Но это должно быть целевое действие, а не постоянное чесание рук. На slon4.cc, кстати, тоже такого рода дискуссии бывали. Люди реально спорили, стоит ли переписывать весь движок ради пятистрочной оптимизации... )

Так что, SystemAdmin, держи баланс. Работает — не трогай, если это не тормозит разработку критически.

slon4.cc