Комментарии 10
При рефакторинге... производительность растет
Правильно ли я понимаю, что речь здесь о производительности команды разработчиков? Ведь рост производительности кода в моем скромном понимании - задача не рефакторинга, но оптимизации.
Нет, речь шла про производительность работы сервиса.
Как вы верно заметили, следует различать термины "рефакторинг" и "оптимизация". Оптимизация часто приводит к усложнению кода, что в свою очередь противоречит целям рефакторинга. Тут речь как раз шла про кейсы, когда целью задачи в первую очередь ставится рефакторинг, но во время этого процесса также улучшается производительность. Вот несколько подобных кейсов:
1) Если в процессе рефакторинга упростилась схема БД. Например, убрались лишние связи и в запросе стало меньше джойнов/подзапросов.
2) Если в процессе рефакторинга был затронут код, отвечающий за работу с БД. И оказалось, что выполняются ненужные подзаросы/джойны или тянутся лишние данные. Поэтому вместе с упрощением кода получилось ускорить его работу.
3) Если в процессе рефакторинга убрали функциональность, которая по факту уже давно не использовалась. Либо сильно упростили логику работу какой-то функциональности.
4) В статье упоминалось, что скилл команды со временем растет, поэтому в процессе рефакторинга какой-то функциональности разработчики могут в том числе применить оптимизацию, которая не усложнит код (а возможно даже упростит его). В C# большое кол-во различных коллекций. Бывает, что стоит заюзать более подходящую коллекцию и производительность возрастет в несколько раз
5) Для того, чтобы правильно отрефакторить, нужно внимательно просканировать текущий код, понять его работу. Во время этого процесса можно найти проблемы с производительностью и исправить их вместе с рефакторингом
Но конечно, если в проекте есть проблемы с производительностью, то правильнее создать отдельные задачи на оптимизацию (и не называть это рефакторингом).
Подобные статьи про рефакторинг чуть ли не еженедельно вижу-читаю года, этак, с 2000. Но ни разу не видел, чтобы кто-либо где-либо и когда-либо его хоть как-то делал. Для меня он так и остается чем-то из народного фольклора разработчиков. Вместо сотни статей с правильными мыслями лучше бы было написать статью о том как бы эти мысли вставить в череп тому кому надо :))
Соглашусь, что осмысленно занимется рефакторингом мало кто. Но не то чтобы совсем не делают.
Когда припрет - ну, например, когда код настолько макаронный, что новую фичу в него не вставить никак, - матерятся, но рефакторят.
С другой стороны, знаю людей, которые и вполне сознательно рефакторят. В том числе в рамках подхода "Red - Green - Refactor".
Я, например, периодически делаю рефакторинг. Но, в отличие от общего посыла статьи, которая рекомендует готовиться к рефакторингу аки к Новому Году, я просто периодически рутинно правлю куски, которые кажутся мне плохочитаемыми. Такие правки, разумеется, оформляю отдельным коммитами.
И под такие правки заводится отдельная задача в трекере, под неё выделяется время, она после этих правок проходит ревью и тестирование? Или речь идет о каких-то собственных пет-проектах?
Речь идёт о рабочих проектах.
Отдельная задача - нет, не заводится. Да, время выделяется, ревью и тестирование тоже в общем порядке.
А почему это вас это так удивляет? Это же Boy Scout Rule (упоминаемый, в частности, в "Чистой архитектуре") - всегда оставляй код немного чище, чем он был до твоего прихода. Если я вижу кусок кода, не удовлятворяющий, скажем, PEP8 - то да, я его чищу, и делаю это в рабочее время, за деньги :)
Это все, конечно, правильно, но, таким образом можно разве только переменные переименовывать, да отступы выравнивать. Потому что если мне на ревью приходит задача из жыры: "Поменять там-то 42 на 24", то, честно говоря, мне не особо хочется обнаружить, что эта 42 при этом теперь еще и переехала в конфиги и передается оттуда через какой-то новый интерфейс, вставляемый через DI - даже будь это с моей точки зрения сто раз правильно. В свою очередь я тоже так делать не буду - я не то что рефакторинг, а даже кривое форматирование поправлять не стану, если это выходит за рамки конкретной задачи.
Это все, конечно, правильно, но, таким образом можно разве только переменные переименовывать, да отступы выравнивать.
Таким образом можно рефакторить практически любые адекватно "закапсулированные" куски кода. То есть скажем пока вы не меняете интерфейс/сигнатуру у функции и если она нормально покрыта автоматизированными тестами, то внутри функции можно рефакторить практически что угодно. Ну если совсем грубо и упрощённо.
На проекте, на котором я сейчас работаю, кстати, под рефакторинг даже задачи заводятся. Более того, если при работе над другой задачей выясняется, что для ее завершения необходим рефакторинг, под этот рефакторинг создается новая задача, менее приоритетные задачи переносятся на следующий спринт и т. д.
Конечно, это касается только серьезного рефакторинга. Если речь о переименовании переменных, то это, конечно, на отдельную задачу не тянет.
Как рефакторинг помогает не потратить кучу денег на продукт