基本的な基準はおそらく時間(=お金)でしょう。
何かが大きい場合、見積もりは常に困難です。それを最小のチャンクに分割します。
視点に注意してください。あなたの好みのスタイルによってバイアスがかかるため、あなたの見積もりはおそらく以前のプログラマーの見積もりとは異なるでしょう。おそらく、以前のプログラマーを雇ってコードを「修正」する方がよいでしょう。
いずれにせよ、適切に記述され、維持しやすいアプリを呼び出すための最小要件を述べ、これについて上司やチームと話し合い、可能な限り最小のスプリントに分割し、それらすべてに必要な時間を見積もる必要があります。
書き直した方が ROI が全体的に向上することを上司に納得させることができた場合は、書き直してください。そうでなければ、「新しいスタイル」を学びましょう。書き換えの時間、またはそれを行うための空き時間のためにビジネスを停止する快適さがある場合は、幸運です. コードがテスト可能である場合、または少なくともいくつかの単体テストがある場合は、さらに幸運です。これが不可能な場合は、機能テストを実装して、少なくとも両方のケース (リファクタリングまたは書き直し) を支援する必要があります。
私たちの誰もがおそらく、リファクタリングよりもゼロから書き直すことを好むことに注意してください。次に、この書き直したものを書き直します...
したがって、すでにテストがあるか、テストを簡単に実装できると仮定すると、リファクタリングは常に良い選択です。