Kdaj bi se morali odločiti za refaktoriranje, zamenjavo ali umik starega sistema?

Question

Accepted Answer

Starejši sistemi so neprijetni, vendar pogosto dragoceni – vodijo poslovanje. Odločitev za **refaktoriranje, zamenjavo ali umik** mora biti vodena s stroški in vrednostjo, ne z nezadovoljstvom nad starimi kodami. "Staro je in grdo" ni razlog; "nas stane" je.

## Vodnik za odločitev

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

Celotne pregradnje so mamljive in pogosto katastrofalne; trajajo dlje kot pričakovano, ponovno vpeljejo stare napake in delujoči sistem v tem času propada. Raje imajo postopno refaktoriranje ali strangler-fig zamenjavo. K celotni pregradnji se zatecite le, kadar so postopni pristopi res zapreni.

## Konkreten primer

Monolit je boleč, a deluje dobro in ni vaše ozko grlo – refactorirajte najslabše module, ne prepišite. Toda sistem na različici baze, ki leta izgubi varnostno podporo in nima poti nadgradnje – to je nujna zamenjava in jo načrtujete premišljeno.

## Nevarnost

Emocionalnim odločitvam: zamenjava dovolj dobrih sistemov ker so nemoderni, ali lepljenje na umirajoče zaradi izkoristka. Odločajte se na podlagi stroškov in vrednosti.

## Zakaj je to pomembno

Nepotrebne pregradnje zavzamejo leta in ponovno predstavijo rešene probleme; zanemarjena dediščina postane tiktajuča odgovornost.

Pravilna odločitev, na podlagi dokazov, ne estetike, je ena najvišjih stav sodb, ki jo naredi senior TL.