Kada biste trebali refaktorirati, zamijeniti ili umiroviti legacy sistem?

Question

Accepted Answer

Legacy sistemi su neugodni ali često vrijedni, oni pokrivaju posao. Odluka za **refaktoriranje, zamjenu ili umirovljenje** mora biti vođena troškom i vrijednosti, ne odbojom prema staroj kodu. "Staro je i ružno" nije razlog; "skupo nas stoji" jest.

## Zašto je to važno

```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
```

## Pazite na zamku prepisivanja

Potpuni preporodi su prijenosni i često katastrofalni, traju duže nego što se očekuje, ponovno uvode stare greške, i radni sistem propadne u međuvremenu. Preferirajte inkrementalno refaktoriranje ili zamjenu strangler-fig. Sežite na potpuni preporod samo kada su inkrementalni putovi stvarno zatvoreni.

## Konkretan primjer

Monolith je bolan ali radi dobro i nije vaše grlo, refaktorirajte najgore module, ne prepišite. Ali sistem na verziji baze podataka koja će izgubiti sigurnosnu podršku sljedeće godine, bez putanje nadogradnje, to je prisilna zamjena, i vi je planirate namjerno.

## Zamka

Emocijske odluke: zamjena dovoljno dobrih sistema jer su nemoderni, ili držanje mrljavih sustava zbog uloženih sredstava. Odlučite na osnovu trošaka i vrijednosti.

Nepotralne prepise trošuju godine i ponovno uvode riješene probleme; zanemareni legacy postaje crni rizik.

Donošenje tačne odluke, na osnovu dokaza, ne na estetici, jedan je od najvećih rizika koje pravi senior TL donosi.