История изменений

А куда ж от этого деться-то?

На рефакторинг времени всегда меньше, чем на новую функциональность.

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

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

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

В топку такое переписывание, в общем. Иногда лучше костыли.

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

А куда ж от этого деться-то?

На рефакторинг времени всегда меньше, чем на новую функциональность.

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

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

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

В топку такое переписывание, в общем. Иногда лучше костыли.

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