Я никогда не слышал о термине «Приложение душителя» - мне это нравится. Там, где это возможно, это всегда хороший подход, он, безусловно, сводит к минимуму риск и довольно прагматичен, отсекая большое здание по частям.
Где, по моему опыту, это не работает, там, где сразу требуются достаточно значительные изменения - изменения, которые потребуют небольшого количества рефакторинга (или большого количества взлома). В этой ситуации я часто находил, что изменения, которые мне нужно было сделать, были в самом сердце большого шара грязи, и не было другого выбора, кроме как испачкаться - даже то, что должно было быть стандартным обслуживанием или незначительные изменения в улучшении, были просто ужасными и Главный рефактор был лучшим вариантом.
В этих случаях я бы пошел по принципу «разделяй и властвуй» - первая цель, к которой я всегда стремлюсь, - это тестируемость, если у вас есть все, что намного проще. На самом деле, это часто один из основных драйверов, которые я использую для рефакторинга подальше от большого шарика грязи - такого рода код часто почти не поддается тестированию, надеюсь, есть примеры входов и выходов пользовательского интерфейса, но иногда даже этого не хватает .
Поэтому, когда я сталкиваюсь с кодом, в котором все смешано с пользовательским интерфейсом, я обычно начинаю с разделения отдельных функциональных блоков на классы и методы, а затем помещаю эти части кода на уровень домена или службы. Делая это постепенно, значительно снижается вероятность взлома чего-либо и становится проще точно определить, где был взломанный код, когда что-то идет не так.
Запустите все тестовые наборы, которые у вас есть, в конце каждого изменения и убедитесь, что вы все еще соответствуете некоторому базовому уровню.
Если вы будете писать хорошие модульные тесты по ходу дела, вы можете начать уменьшать масштаб проблемы, и я обнаружил, что вскоре становится практичным использовать подход удушения - с достойными модульными тестами или, по крайней мере, с правильной структурой, позволяющей при написании достойных модульных тестов становится гораздо практичнее постепенно заменять части функциональности.