Kada turėtumėte refaktorinti, pakeisti ar nutraukti senąją sistemą?

Question

Accepted Answer

Senoji sistemos yra nepatogumos, bet dažnai vertingos ir veikia verslą. Sprendimas **refaktorinti, pakeisti ar nutraukti** turi būti vediamas sąnaudų ir vertės, o ne nuo pasenusio kodo neapykantos. "Tai senas ir bjaurus" nėra priežastis; "tai mums kainuoja" yra.

## Kodėl tai svarbu

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

## Būkite atsargūs perrašymo spąstų atžvilgiu

Visiškas perrašymas yra patrauklus ir dažnai katastrofinis, jis trunka ilgiau nei tikėtasi, iš naujo įveda senus klaidas ir veikianti sistema supūsta tuo tarpu. Pageidaukite žingsninio refaktorinimo arba strangler-fig pakeitimo. Siekite visiško perrašymo tik tada, kai žingsniai keliai tikrai yra užblokuoti.

## Konkretus pavyzdys

Monolitas yra skausmingas, bet veikia gerai ir nėra jūsų smaugtis, refaktorinkite blogiausias modulius, negrąžinkite. Tačiau sistema duomenų bazės versijoje, kuri praims saugumo palaikymą kitais metais, be jokios atnaujinimo kelio, tai yra priverstinas pakeitimas, ir jį planuojate artimu.

## Spąstai

Emocionalūs sprendimai: keičiant geru pakankamai sistemo, nes jos nėra madingos, arba tvirtinantis mirusias iš sumokėtų sąnaudų. Sprendimas dėl sąnaudų ir vertės.

## Kodėl tai svarbu

Nereikalingi perrašymai švaistą metus ir iš naujo įveda išspręstas problemas; apleista senoji tampa laikiniu atsakomybės.

Teisingai atlikti šį skambutį, pagrindžiant į įrodymus, o ne estetiką, yra vienas iš aukščiausio pavojaus sprendimų, kurie priima vyriausiasis TL.