デフォルトはリファクタリングです。書き直しが正当化されるのは、既存システムが許容可能なコストでは要件を満たすように進化できなくなり、かつ書き直しの間も価値を届け続けられる場合のみです。「書き直しが必要だ」という直感のほとんどは、実のところ管理されていないtech debtの問題であり、はるかに小さいリスクで段階的なリファクタリングが解決します。
どう推論するか
- コアのアーキテクチャはまだ有効か? データモデル、境界、ランタイムが新しい要件まで伸ばせるなら、リファクタリングです。基礎的な前提が間違っているなら(間違ったストレージのパラダイム、スケールする手段がない、言語/プラットフォームのEOL)、書き直しが本当の候補になります。
- 変更頻度はどうか? めったに変わらないコードは綺麗である必要はありません。チームが日々作業する場所に労力を集中させます。
- 現在の振る舞いを理解しているか? 書き直しは、何年もかけてエンコードされたエッジケースの知識を捨て去ります。テストも仕様もなければ、書き直しは古いバグを再導入します。