Шукаєте кращого способу поєднати глибокий архітектурний рефакторинг із розробкою на основі функцій

Постановка проблеми:

Подано:

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

Проблема:

Застосування, безперечно, вимагає глибокого рефакторингу. Цей процес неминуче робить застосування нестабільним і потрібна спеціальна стабілізаційна фаза.

Ми спробували:

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

Що нам радять:

Посилання на статтю (pdf)
Створіть додаткову гілку для рефакторингу (RB), періодично синхронізуючи її з MB через злиття від MB до RB. Після стабілізації RB ми замінюємо Master на RB і створюємо нову гілку для подальшого рефакторингу. Це план. Але тут я очікую справжнього пекла злиття МБ в RB після об'єднання будь-якого FB в MB.

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

Чи є кращі альтернативи виручці?

У мене була аналогічна ситуація в минулому. Що я зробив:

• оцінити поточний стан проекту; в більшості ситуацій головна проблема - це архітектура (або її відсутність) => переосмислити її
• зазвичай є робочі особливості, проблема полягає у високій зв’язці між різними частинами проекту; Я оцінив, які є робочі особливості, і повторно їх використав, але в власній архітектурі

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

• у фазі злиття двох рішень (зробити архітектуру + повторно використовувати функції зі старого проекту) єдині речі, які були випущені (нові функції), були зроблені на старому продукті; однак нові випуски містили лише важливі виправлення помилок. Так що на старий продукт було зроблено дуже мало релізів. Отже, змінені речі легко були об'єднані в нове рішення.

• перший новий реліз (випуск нового продукту) містив лише те, що містив старий продукт (відсутні нові функції); після його стабілізації (стабілізація не зайняла багато часу) я працював з одним проектом

Я думаю, вам не вдається вирватися із (досить короткого) періоду спорадичних випусків. Важливо, щоб ви могли домовитись про це зі своїм замовником.