Kdy byste měli refaktorovat, nahradit nebo vyřadit starší systém?

Question

Accepted Answer

Starší systémy jsou nepříjemné, ale často cenné, řídí byznys. Rozhodnutí o **refaktorování, nahrazení nebo vyřazení** musí být řízeno náklady a hodnotou, ne odporem k starému kódu. "Je to staré a ošklivé" není důvod; "nás to stojí" je.

## Průvodce rozhodováním

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## Pozor na past přepsání

Plné přepsání je lákavé a často katastrofální, trvá déle, než se očekávalo, znovu zavádí staré chyby a systém v provozu se mezitím rozpadá. Preferujte postupné refaktorování nebo nahrazení strangler-fig. Sáhněte po plném přepsání pouze v případě, že postupné cesty jsou skutečně uzavřeny.

## Konkrétní příklad

Monolit je bolestivý, ale funguje dobře a není vaším kritickým místem, refaktorujte nejhorší moduly, nepřepisujte. Ale systém na verzi databáze, která ztrácí bezpečnostní podporu příští rok, bez cesty upgradu, to je vynucené nahrazení, a vy to plánujete záměrně.

## Úskalí

Emoční rozhodnutí: nahrazování dostatečně dobrých systémů, protože jsou nepopulární, nebo setrvávání na umírajících kvůli utopené investici. Rozhodujte na základě nákladů a hodnoty.

## Proč je to důležité

Nepotřebná přepsání zbytečně ztrácí roky a znovu zavádějí vyřešené problémy; zanedbávaný starší systém se stává hrozícím závazkem.

Správu tohoto rozhodnutí na základě důkazů, ne estetiky, je jedním z nejvyšších rizik, které senior TL dělá.