深いアーキテクチャのリファクタリングを機能ベースの開発と組み合わせるより良い方法を探しています

問題文：

与えられた：

• ソース管理としてのTFS
• アーキテクチャ設計が悪いかほとんどないレガシーコードが大量にある重いデスクトップクライアントアプリケーション。
• 音質、高速
  配信、常にユーザーに不親切なUIに不満を示す新機能を常に必要とするクライアント。

問題：

アプリケーションは間違いなく、深いリファクタリングを必要とします。このプロセスは必然的にアプリケーションを不安定にし、専用の安定化フェーズが必要です。

私たちは試しました：

マスター（MB）から機能ブランチ（FB）への定期的なマージによるマスターのリファクタリング。（私の間違い） 結果：多くの不安定なブランチ。

私たちがアドバイスされていること：

記事（pdf）へのリンク
リファクタリング（RB）のための追加のブランチを作成し、MBからRBへのマージによって定期的にMBと同期します。RBが安定した後、マスターをRBに置き換え、さらにリファクタリングするための新しいブランチを作成します。これが計画です。しかし、ここでは、FBをMBにマージした後、MBをRBにマージすることの本当の地獄を期待しています。

主な利点： ほとんどの場合、安定したマスター。

収益のより良い代替案はありますか？

過去にも同じような状況がありました。私がしたこと：

• プロジェクトの現在の状態を評価します。ほとんどの場合、アーキテクチャー（またはその欠如）が主な問題です=>再考する
• 通常は機能的な機能があり、問題はプロジェクトのさまざまな部分間の高い結合です。機能している機能を評価して再利用しましたが、自分のアーキテクチャでは

• 顧客と話す; 上司の言うことはわかりませんが、お客様と話をして率直に言うことが重要だと思います。彼はあなたが彼の製品の品質に取り組んでいることを知る必要があります。リリース計画について同意しました：

• 2つのソリューションをマージするフェーズ（古いプロジェクトのアーキテクチャ+再利用機能を作成）では、リリースされたもの（新機能）のみが古い製品で作成されました。ただし、新しいリリースには重要なバグ修正のみが含まれていました。そのため、古い製品で行われたリリースはほとんどありません。したがって、変更されたものが新しいソリューションに簡単にマージされました。

• 最初の新リリース（新製品のリリース）には、旧製品に含まれていたものだけが含まれていました（新機能は含まれていません）。それを安定させた後（安定に時間がかかりませんでした）単一のプロジェクトで作業しました

（かなり短い）散発的なリリースから逃れることはできないと思います。これについて顧客と合意できることが重要です。