Når bør du refaktorere, erstatte eller pensjonere et legacy-system?

Question

Accepted Answer

Legacy-systemer er ubehagelige men ofte verdifulle, de driver virksomheten. Beslutningen om å **refaktorere, erstatte eller pensjonere** må være drevet av kostnad og verdi, ikke av avsky for gammel kode. "Det er gammelt og stygt" er ikke en grunn; "det koster oss" er.

## En beslutningsveiledning

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

## Vær på vakt for omskrivingsfellen

Fullstendige omskrivinger er fristende og ofte katastrofale, de tar lengre tid enn forventet, gjeninnfører gamle bugs, og det fungerende systemet råtner i mellomtiden. Foretrekk inkrementell refaktorering eller strangler-fig-erstatning. Grep etter en fullstendig omskriving bare når inkrementelle veier er genuint stengt.

## Et konkret eksempel

En monolitt er smertefull men fungerer fint og er ikke flaskehalsen din, refaktorer de verste modulene, ikke omskriving. Men et system på en databaseversjon som mister sikkerhetsstøtte neste år, uten oppgraderingsbane, det er en tvungen erstatning, og du planlegger det bevisst.

## En fallgruve

Emosjonelle beslutninger: erstatning av tilstrekkelige systemer fordi de er umoderne, eller klamring til døende systemer på grunn av ugjorte investeringer. Bestem på grunnlag av kostnad og verdi.

## Hvorfor det er viktig

Unnødvendige omskrivinger sløser bort år og gjeninnfører løste problemer; neglisert legacy blir en tikkende ansvar.

Å få denne avgjørelsen riktig, basert på bevis, ikke estetikk, er en av de høyeste innsatsene en senior TL gjør.