Неправильно называть рефакторингом переход с синхрона на асинхрон, это уже как минимум другой контракт, скорее всего и Use Case поменяется, добавятся очереди и бог его знает что.. Это уже другая по сути фича. А рефакторинг это же когда поведение программы (класса) не меняется и даже интерфейсы не меняются. Как у метода sort на вход был массив, так и остаётся, только вместо пузырька стали merge-sort использовать

Такой коммент оставили к видео про тесты youtube.com/watch?v=DqgAqCpYsbs Тут у меня приподнялась бровь, потому что у человека (судя по другим комментариям и лайкам) восприятие рефакторинга прочно ассоциируется с внутренними модулями. А раз есть такое восприятие, то не грех это проговорить.

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

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

А что обычно вы имеете ввиду когда говорите что делаете рефакторинг или тут нужен рефакторинг?

Ссылки: Телеграм | Youtube | VK