Комментарии 5
Добавили бы примеры кода разных кейсов. Статья бы читалась намного бодрее. Мы же на ИТ ресурсе.
на словах оно всегда красиво, а на деле никакое tdd не спасет от рандомных или совсем неочевидных регрессий.
да и целесообразность чаще всего очень туманна. Менять не сильно качественный код, прошедший кучу багфиксов и испытаний времени, на новый классный, стильный и молодежный может быть очень опрометчиво.
Рефакторинг через TDD помогает обезопасить себя от неочевидных ошибок, здесь также очень сильно зависит от того, насколько правильно разработчик понимает текущую бизнес-логику. Если тесты хорошо провалидированы, то промахов не возникает. Отмечу, что регрессионное тестирование всё равно проводится после написания тестов.
Касательно целесообразности, то конечно, проводить рефакторинг ради рефакторинга - сомнительная идея. Если код работает и он потенциально не расширяется, а самое важное, что это не является часто изменяемой функцией приложения и не приносит сильных неудобств, то можно оставить такой код до лучших времен.
вот тут то я и вижу основную проблему. очевидность это антоним TDD, так как если вы кейс тестами покрыли - то он для вас очевиден и предсказуем.
а те проблемы, которые я имел ввиду, могут возникнуть уже в проде, когда какой-то рэйс кондишн или флаки поведение при взаимодействии компонентов или неожиданный мемори лик, который будет влиять на перформанс ранее стабильно работающего функционала нивелирует(или вероятнее сделает хуже) текущий функционал.
я не хочу, чтобы вы меня поняли неправильно, вы по книжке описали теорию того, как следует проводить рефакторинг функционала, это полезно и кому-то определенно пригодится, но в то же время я считаю, что чаще всего код рефакторить очень опасно, особенно ключевого функционала, и намного полезнее для бизнеса будет запечатать такой код в каком-то модуле и рефакторить его только в случае самой крайней необходимости.
Публикации
Рефакторинг кода, и как его не бояться