Kako odlučujete kada refaktorirati, a kada prepisati sustav od nule?

Question

Accepted Answer

Zadano je **refaktoriranje**. Prepisivanje je opravdano samo kada se postojeći sustav više ne može razvijati da bi zadovoljio zahtjeve uz prihvatljiv trošak, i kada možete nastaviti isporučivati vrijednost dok to radite. Većina instinkta "trebamo prepisivanje" zapravo je neupravljani problem tech debta koji inkrementalno refaktoriranje rješava uz daleko manji rizik.

## Kako o tome razmišljam

- **Je li osnovna arhitektura još uvijek održiva?** Ako se podatkovni model, granice i runtime mogu rastegnuti na nove zahtjeve, refaktoriraj. Ako su temeljne pretpostavke pogrešne (kriva paradigma pohrane, nema načina za skaliranje, kraj životnog vijeka jezika/platforme), prepisivanje postaje stvaran kandidat.
- **Kolika je učestalost promjena?** Kôd koji se rijetko mijenja ne mora biti lijep. Koncentriraj napor tamo gdje tim radi svakodnevno.
- **Razumijemo li trenutno ponašanje?** Prepisivanje odbacuje godine kodiranog znanja o rubnim slučajevima. Ako nema testova i nema specifikacije, prepisivanje će ponovno uvesti stare bugove.

## Okvir odlučivanja

| Signal | Naginji refaktoriranju | Naginji prepisivanju |
| --- | --- | --- |
| Arhitektura odgovara zahtjevima | Da | Ne |
| Pokrivenost testovima/specifikacijom | Niska ili visoka | Dovoljno visoka za provjeru pariteta |
| Može se isporučivati inkrementalno | Da | Teško, big-bang |
| Tim razumije kôd | Da | Ne, i originalni autori otišli |

## Kompromisi

- **Refaktoriranje:** niži rizik, kontinuirana isporuka, ali sporo na uistinu trulom temelju.
- **Prepisivanje:** čista ploča, ali plaćate **porez na feature-freeze**, nosite **trošak dvostrukog održavanja** i riskirate klasičnu zamku pretjeranog inženjeringa drugog sustava.
- Preferiraj srednji put **strangler-fig**: podigni novi sustav uz stari, usmjeravaj promet inkrementalno, briši stari dio po dio. Daje koristi prepisivanja uz rizik na razini refaktoriranja.

## Zamke

- Prepisivanje iz **estetskih ili resume-driven** razloga, a ne zbog poslovnog troška.
- Podcjenjivanje skrivenog ponašanja; uvijek prvo karakteriziraj trenutno ponašanje testovima.
- Višekvartalno big-bang prepisivanje koje ne isporučuje ništa — zamah i povjerenje obojе propadaju.

## Zašto je to važno

Odluka refaktoriranje naspram prepisivanja jedna je od najvrjednijih odluka koje Tech Lead donosi. Pogriješite li prema prepisivanju, možete zamrznuti isporuku na godinu dana i svejedno propasti; pogriješite li prema refaktoriranju, polako gubite velocity. Uokviravanje kao odluke o trošku i riziku, a ne o ukusu, je ono što odvaja senior procjenu od preferencije.

Signal	Naginji refaktoriranju	Naginji prepisivanju
Arhitektura odgovara zahtjevima	Da	Ne
Pokrivenost testovima/specifikacijom	Niska ili visoka	Dovoljno visoka za provjeru pariteta
Može se isporučivati inkrementalno	Da	Teško, big-bang
Tim razumije kôd	Da	Ne, i originalni autori otišli