Hvornår bør du refaktorere, erstatte eller pensionere et ældre system?

Question

Accepted Answer

Ældre systemer er ubehagelige, men ofte værdifulde – de driver virksomheden. Beslutningen om at **refaktorere, erstatte eller pensionere** skal være drevet af omkostninger og værdi, ikke af modvillighed mod gammel kode. "Det er gammelt og grimt" er ikke en grund; "det koster os" er.

## En beslutningsvejledning

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

## Pas på omskrivningsfælden

Fuldstændige omskrivninger er fristende og ofte katastrofale – de tager længere tid end forventet, geninddfører gamle fejl, og det fungerende system forringes i mellemtiden. Foretrække trinvis refaktorering eller strangler-fig-udskiftning. Grib til fuldstændig omskrivning kun når trinvise veje er virkelig lukket.

## Et konkret eksempel

En monolitisk arkitektur er ubelejlig, men virker fint og er ikke dit flaskehals – refaktorer de værste moduler, omskriv ikke. Men et system på en database-version, der mister sikkerhedssupport næste år uden upgrade-sti, det er en tvungen erstatning, og du planlægger det omhyggeligt.

## En fælde

Emotionelle beslutninger: at erstatte tilstrækkeligt gode systemer, fordi de er umoderne, eller at blive hængende i stødende systemer på grund af udbetalt omkostning. Beslut på basis af omkostninger og værdi.

## Hvorfor det betyder noget

Unødvendige omskrivninger koster år og geninddfører løste problemer; forsømt arv bliver et tikkende ansvar.

At få denne vurdering rigtig, baseret på evidens, ikke æstetik, er en af de højeste indsatser, som en senior TL træffer.