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

Собственно про неоптимальность писала выше

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

Даже в уборке убирают не только когда уже все засрали, что работать невозможно, но и регулярно просто поддерживают чистоту.

Странная аналогия. Кто-то срёт в код?)

Все срут, просто не все признаются.

ну и "чисто там где убирают, а не там где не мусорят".

Ох ребята)

Да кто у вас там в коде мусорит 😄
Есть код, он выполняет свою функцию. Зачем его переписывать?

Если он это делает хорошо

как понять, делает он это хорошо или можно лучше?

А зачем лучше?

Тимлидов нанимают чтобы они вели команду к бизнесовым результатам, а не возглавляли команду художников

Этот порядок в коде ценность только для разрабов, менджмент и юзеры это не понимают и им положить

Дело не в порядке кода, а в излишней оптимизации

А наркотическая страсть к оптимизации это ваще отдельная статья))

Есть задача - прикрутить новую фичу. На текущий код плохо ложится - рефакторим.
Просто рефакторим, подразумевая, что вдруг будет фича - преждевременно оптимизируем

Это не оптимизация даже, а борьба с ветряными мельницами

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

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

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

Звучит гуд, но многие теряют голову, даже опытные(

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