Перед тем, как я начну записывать серию заметок по базам данных, чтобы для себя закрепить материал, пришла хорошая мысль, которую я решил сохранить.
Да, наверно, многие меня поймут, когда в рамках задачи хочется сразу написать код по-нормальному, как нужно и заодно исправить старый код.
Но, как оказалось, не нужно : )
Для себя я понял, что все-таки, когда тебе нужно точечно что-то исправить и, если без рефакторинга ты можешь выполнить задачу - значит так и нужно сделать.
Правильно сказал мой тимлид и прошлый опыт, любой рефакторинг - это дополнительная точка отказа, дополнительное время на code review, на этапе тестирования. Если вам хочется какого-нибудь старого мамонта положить на лопатки в рамках задачи и без этого можно обойтись - лучше завести задачу на технический долг.
Мне лично было морально комфортно, когда я создал задачу на рефакторинг, а изменения в рамках текущей задачи заняли три строчки и тестироващикам нужно было проверить сохранение только одного поля. Если бы я сделал рефакторинг, пришлось бы сделать регресс тестирование двух методов api :)
Если у вас нет задач на рефакторинг, то советую внедрить эту практику. В одной из компаний, благодаря понимающим менеджерам, мы смогли отводить для технических задач в рамках спринта 10% времени. Мы всё же плотники и должны улучшать свои инструменты для работы ;)