Ищите лучший способ объединить глубокий рефакторинг архитектуры с разработкой на основе функций

Постановка задачи:

Данный:

• TFS как источник контроля
• Тяжелое настольное клиентское приложение с тоннами устаревшего кода с плохой или почти отсутствующей архитектурой.
• Клиенты постоянно нуждаются в новых функциях с качеством звука, быстрой
  доставкой и постоянно жалуются на недружественный пользовательский интерфейс.

Проблема:

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

Мы попробовали:

Рефакторинг в мастере с периодическим слиянием от мастера (МБ) к ветке объектов (FB). (моя ошибка) Результат: много нестабильных веток.

Что нам посоветуют:

Ссылка на статью (pdf)
Создайте дополнительную ветку для рефакторинга (РБ), периодически синхронизируя ее с МБ путем слияния из МБ в РБ. После стабилизации RB мы заменяем master на RB и создаем новую ветку для дальнейшего рефакторинга. Это план. Но здесь я ожидаю настоящего слияния MB с RB после слияния любого FB с MB.

Основное преимущество: стабильный мастер большую часть времени.

Есть ли лучшие альтернативы процедурам?

У меня была похожая ситуация в прошлом. Что я сделал:

• оценить текущее состояние проекта; в большинстве случаев архитектура (или ее отсутствие) является основной проблемой => переосмыслить ее
• обычно есть рабочие особенности, проблема заключается в высокой связи между различными частями проекта; Я оценил, какие есть рабочие функции, и я использовал их повторно, но в моей собственной архитектуре.

• поговорить с клиентом; Я не знаю, что говорит ваш менеджер, но я думаю, что важно поговорить с клиентом и быть откровенным; он должен знать, что вы работаете над качеством его продукта. Я заключил соглашение о плане выпуска:

• на этапе слияния двух решений (создание архитектуры + повторное использование функций из старого проекта) были выпущены только те вещи, которые были выпущены (новые функции) на старом продукте; однако, новые выпуски содержали только важные исправления ошибок. Поэтому очень мало релизов было сделано для старого продукта. Следовательно, измененные вещи были легко объединены в новое решение.

• первый новый выпуск (выпуск нового продукта) содержал только то, что содержал старый продукт (без новых функций); после стабилизации (стабилизация не заняла много времени) я работал с одним проектом

Я думаю, что вы не можете избежать (достаточно короткого) периода спорадических выпусков. Важно, что вы можете договориться об этом с вашим клиентом.