Mikor kellene egy legacy rendszert refaktorálni, cserélni vagy kivonni?

Question

Accepted Answer

Az örökölt rendszerek kényelmetlenek, de gyakran értékesek, működtetik az üzletet. A **refaktorálás, csere vagy kivonás** döntéseit költség és érték, nem pedig az öreg kód utálatára kell alapozni. "Régi és csúnya" nem ok; "költségeket okoz nekünk" az.

## Miért fontos ez

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

## Óvakodjon az átírási csapdától

A teljes átírások csábítóak és gyakran katasztrofálisak, több időbe telnek, mint várható, újra bevezetik a régi hibákat, és a működő rendszer közben elromlott. Inkább az inkrementális refaktorálást vagy a strangler-fig cserét választják. Teljes átíráshoz csak akkor nyúljanak, ha az inkrementális útvonalak valóban lezáródnak.

## Egy konkrét példa

Egy monolith fájdalmas, de jól működik és nem az Ön szűk keresztmetszete, refaktorálja a legrosszabb modulokat, ne írja át. De egy olyan rendszer az adatbázis verziójában, amely jövőre elveszíti a biztonsági támogatást, nincs frissítési útvonala, ez egy kényszerű csere, és szándékosan megtervezi.

## Egy csapda

Emotionális döntések: megfelelő rendszerek cseréje, mert divattalanok, vagy haldokló rendszerekhez ragaszkodás az elsüllyedt költségek miatt. Költség és érték alapján döntsenek.

A szükségtelen átírások éveket pazarolnak és újra bevezetik a megoldott problémákat; az elhanyagolt örökség egy működő kötelezettség lesz.

Ez a hívás helyes meghozatala, bizonyítékokon alapulva, nem esztétikán, az egyik legmagasabb tétet jelentő ítélet, amelyet egy senior TL meghozz.