Комментарии 19
Опаснее рефакторинга может быть только преждевременный рефакторинг. А есть по этой теме что нибудь ?
Работает? Не трожь!
как же надоели эти громкие высказывания (или утверждения) "Работает? Не трожь!"
Трожь! Трожь как никогда. Без этого не будет прогресса, без этого не будет современного стека и проект утонет в легаси.
Просто все это нужно делать с головой а не просто потому что захотелось
Вот с такой формулировкой точно не трогай.
Если все ради "современного стека" то трогать не нужно.
Рефакторинг необходим если лаги/проблемы, отсутсвие тестов/коментариев или переусложненная реализация. И то это должно быть к месту, а не так что "часовой рефактринг" положил прод на неделю, хотя "у меня все работало"
Хороший рефакторинг это тот, который сделан своевременно. Есть как минимум 3 процесса улучшения кода: для исправления техдолга, созданного руками разработчиков, для исправления накопительных ошибок и для исправление запланированного устаревания.
На первый выделяется время в рамках ежедневной работы. Если ты можешь исправить кусок кода в рамках своей задачи - выдели на это время. Если не можешь - выдели задачу. Обычно 10% спринта можно выделить на техдолг.
Второй - очень тяжелый, на него надо выделять время дважды - для обнаружения и для рефакторинга. Нет рецепта.
Исправление запланированного устаревания происходит в рамках обновления библиотек, в рамках обновления фреймворков и экосистемы. Просто обновилось что-то глобальное, выделили время, обновились.
Обычно нужно старатся писать так что бы техдолг не возникал.
Техдолг появляется там где "срочно-срочно" или разрабам вообще похуй кто это потом будет поддерживать.
То что вы написали вторым пунком и есть рефактрринг, а первое это подтирание соплей. Или за разрабами или за менеджером.
Запланированное устаревание очень неоднозначная штука. Бездумно обновлять лишь бы обновлять черевато. А если в проекте много зависимостей обновление зачастую уходит как отлельная большая таска так как нужно сначала свести в единую таблицу что обновляем и что в них изменилось, что бы еше на старте понимать самые острые углы. И делать это должен тот кто хорошо знает проект.
Понятное дело я не имею в виду всякие говнопроекты с 100500 либ где буквально все на либах, даже то что и без либ написалось бы заняв такой же обьем кода. Такие проекты обычно пишутся "один раз" и их поддержка не планировалась на старте. Их и не обновляют обычно потому как "живут" они год-два максимум
Вы не правы. Невозможно писать так, чтобы технический долг не возникал, так как:
Мы все люди
В любом живом проекте меняются требования
Мы работаем не одни
Кодовая база крайне редко бывает маленькой. Да, мы все пишем код так, чтобы техдолг не возникал, но меняются подходы, наши знания, да и просто мы растем как специалисты и то, что мы 10 лет назад считали идеальным кодом сейчас не пройдет ревью.
Обновлять зависимости надо всегда, но пусть не в момент выхода, а через пару-тройку патчей.
Все что вы описали как раз второй случай, который нужно сначала накопить, затем исследовать и только потом зная как минимум края можно заниматся рефакторингом.
Если выпускаемый код ПОСТОЯННО требует фиксов и доработок на те самые 10% (не правки, а именно хотфиксы критикалов) то вы явно занимаетесь чем то не тем. Проблема или в разрабах или в самой постановке техпроцесса.
А обновлятся нужно думаючи. Срочно-срочно актуально только если либы получили патчи на zero-уязвимости. В останом случае нужно опять таки подходить к этому думаючи. Пару раз встречал ситуацию когда обновление либы или компилятора затрагивало методы, которые в старой версии более оптимальные по ресурсам/скорости - потому как в новой версии для этих методов сделали "безопасные" аналоги с кучей параметров и плясок, а старые методы так же сделали "безопасными" но ценой всего. И вот тут как раз проще остатся на старой пока не появится окно нормально обновится, переписав критичные места на новые методы, чем бездумно обновится а потом "удивлятся" а чего это все упало.
преждевременный рефакторинг
Это как? Это когда мы рефакторим то чего еще нет? Типа одна команда ведет разработку, а другая сразу разрабатывает переделанную версию, наверно :) .
Или есть еще вариант: у вас же завтра все колом встанет, вот тут посмотрите уже затык!
Ответ: вот когда ВСЕ колом встанет тогда будем рефакторить, нам не нужен преждевременный рефакторинг.
Если рефакторинг в самом начале рпазработки это всегда плохо по определению.
В рефакторинге главное достичь максимально эффективной работы кода, и читаемость уходит на второй план.
Как правило до рефакторинга можно потратить на задачу 1 час. После рефакторинга, эту же задачу можно сделать за 4 часа.
Прогресса в рефакторинге тоже нет. Это процесс улучшенеия технических харрактеристик продукта, а не для удобства разработчика(если только как побочный эффект)
Если качественная архитектура там колом никогда ничего не встает
У реакт разработчиков часто эффект сантехника есть.
Все плохо я сейчас все местами поменяю, и типо все у меня идеал но работает.
Приходит другой и все повторяется..
Я на прошлой неделе работал с реакт проектом с ужасной архитектурой и все супер. Даже не думал о рефакторинге, потому что там рефакторинг это практически смена архитектуры.
Если рефакторинг в самом начале рпазработки это всегда плохо по определению.
Ерунда полная. Я всегда сначала пишу "черновик", который просто работает. А потом делаю рефакторинг в контексте производительности, тестируемости, читаемости и так далее и тому подобное.
А вы серьёзно код сразу "начисто" пишите?
потому что там рефакторинг это практически смена архитектуры
иногда бывает что рефакторинг это приведение проекта БЕЗ архитектуры (или с зоопарком обрывков разных архитектур, что, в прочем, то же самое) к какой-то определенной архитектуре.
Скорее всего именно это надо называть рефакторингом, потому что замена одной архитектуры другой тянет на вполне положительную "смену концепции" например.
Если качественная архитектура там колом никогда ничего не встает
если качественная архитектура, рефакторинг не нужен, если я правильно понимаю что такое рефакторинг.
не полагайтесь на то, что специалисты QA выявят все баги
Более того, QA не резиновые, если их пытаться заставить на каждый чих перепроверять всю систему - очень быстро произойдёт bottleneck в части тестирования, и виноват в нем будет не qa, а разработчик
Более того, QA не резиновые
Вроде как основная задача QA следить за соблюдением процедуры. Если разработчик не знает как проверить то, что он разработал, и не в состоянии хотя бы один раз проверить то, что он разработал по завершению разработки, тогда ничто не поможет проекту с такими разработчиками. QA должны проверять что критерии проверки сформулированы и проверка проведена-реализуема, конечно желательно чтобы QA понимали адекватность проверки.
Если разработчик говорит вам что не знает как проверить то, что он делает/должен сделать, вряд ли можно надеяться, что разработчик понимает предмет под разработкой.
QA должны проверять что критерии проверки сформулированы и проверка проведена-реализуема
Кмк это зависит от того как построен процесс. По моему опыту, гораздо лучше когда QA сам придумывает сценарии и обсуждает их с разработкой (что можно автоматизировать, что нельзя, что опасно и т.д.). По большей части это связано с тем что во время работы над задачей мыслительный процесс разработчика, опять же по моим наблюдениям, сильно отличается от QA: разработчик больше думает со стороны создания, а QA - со стороны возможных косяков. Понятно что разработчик должен и про косяки думать, но в общем случае у QA это получается лучше чисто ввиду разделения труда. Это особенно заметно если бэк и фронт разделены (не full stack), некоторые кейсы могут казаться ппц важными разработчику но для QA это будет откровенно corner case и наоборот.
Вы слегка упрощаете. Я очень часто говорю своим QA, что не знаю, как проверить. И они меня прекрасно понимают - потому что у нас интеграционный проект, и проблемы чаще всего возникают на стыке с другими проектами, причем иногда в результате эксплуатации скажем в течение пары недель.
То есть, чтобы проверить, мне иногда всего-то нужен работающий процесс как в проме, смежный проект с его процессами, люди, которые всем этим пользуются, и все это должно поработать с определенными настройками дней 20. А времени у меня на это не заложено, потому что про влияние времени мы только что в процессе починки бага выяснили. Вот так реально выглядит вариант "не знаю как проверить" - не знаю, как проверить, за разумное время, и не угрохав на это кучу нужных для других задач ресурсов. И при этом само исправление может выглядеть как однострочник.
Я очень часто говорю своим QA, что не знаю, как проверить. И они меня прекрасно понимают - потому что
Вот интересно и что же вы по результату делаете? Не проверяете? Я примерно это и имел ввиду "не знаю как проверить"="проверять не будем", обычно да -- потому что процес разработки противоречит процесу управления ресурсами, который (процес) контролирует более высокое начальство и который поэтому (а не для пользы дела) имеет более высокий приоритет.
Ну как вам сказать... например высокое начальство мне говорит - вы теперь обязаны проводить еще и нагрузочное тестирование. И еще добавляет - закажите себе стенд для этого тестирования, не экономьте, берите как 100% пром стенда. Мы смотрим на свои пром стенды, выбираем из них самый маленький, и заказываем примерно конфигурацию в 20% от него. И уже от конкретных людей, которые занимаются планированием ресурсов типа процессоров или там дисков получаем замечание: "А вы в курсе, что это будет стоить XX миллионов в год?". Так что процессы на верхних уровнях очень часто слабо стыкуются с реальностью,
Не проверяете?
Если у вас есть код, который точно не работает в определенных условиях (скажем в одном случае из 100). Вы над ним подумали, и поняли, что если изменить одну строчку - то он будет работать правильно и в этом случае, а остальные не заденет (по сути, вы выполнили тест этого куска в голове). И вы можете выдать исправленную версию только тому пользователю, которого затронул этот баг. И процесс, где работает ваш код, не управляет АС, и даже автомобилем. И что вы выберете? Я лично в такой ситуации выберу отдать версию в пром, озвучив риски всем кому надо, и проверить там.
А универсального ответа очевидно тут нет.
Этот опасный рефакторинг