Surgical Edits vs Full Rewrite: Zašto ne bacamo vaš kod u smeće

Svaki developer voli pisati od nule. Problem je što tvoj business ne može čekati 6 mjeseci dok gradimo novu verziju tvog već funkcionalnog sustava.

Prošli tjedan nas je nazvao founder e-commerce platforme. Checkout im se učitava 8 sekundi. Developer koji je gradio sustav prije 2 godine više nije tu. Novi tim predlaže full rewrite u Next.js. Cijena: 40.000€. Timeline: 4 mjeseca.

Naš odgovor: ne treba vam rewrite. Treba vam surgical edit na payment processing logici i database query optimizacija. Trošak: 6.000€. Timeline: 2 tjedna.

Zašto je rewrite privlačan (i zašto je to zamka)

Clean slate je seksi. Nova arhitektura. Najnoviji framework. Bez legacy cruft-a. Svaki developer to voli jer možemo raditi stvari "kako treba".

Problem je što "kako treba" ne postoji. Postoji samo "kako radi za ovaj business u ovom trenutku". I tvoj existing kod vjerojatno radi — samo ne dovoljno brzo ili ne na način koji ti sad treba.

Full rewrite znači:

• 6-12 mjeseci razvoja dok stari sistem mora i dalje raditi

• Održavanje dva sustava paralelno

• Migracija podataka koja uvijek krene po zlu

• Testing edge case-eva koje si zaboravio da postoje

• Zero novih feature-a dok traje rewrite

Opportunity cost je ogroman. Dok ti prepisuješ isti feature set u novom frameworku, konkurencija šiba nove feature-e.

Što je surgical edit i kako ga radimo

Surgical edit = identificirati bottleneck, riješiti ga kirurški, ostaviti sve ostalo što već radi.

Naš proces:

1. Audit — provjerimo što stvarno ne radi. Ne što izgleda ružno u kodu, nego što usporava business.

2. Prioritizacija — rankiramo probleme po impact/effort ratio. Najprije rješavamo ono što donosi najviše za najmanje truda.

3. Targeted refactor — mijenjamo samo komponente koje moraju. Ostatak sustava ne diramo.

4. Deploy — push to production, monitoring, gotovo.

Tvoj kod nije trash zato što ima 3 godine. Možda je spor na jednom mjestu. Možda ima security issue u jednoj ruti. To se fixxa, ne rewrite-a.

Primjeri iz prakse

Spor checkout (spomenut gore): Problem bio N+1 query u cart logici i sinkroni payment API call. Riješeno s eager loading-om i async job queue-om. 8 sekundi → 1.2 sekunde. Cijeli ostatak e-commerce aplikacije ostao nepromijenjen.

Outdated payment provider: Klijent koristio Stripe API v2 iz 2018. Nove payment metode nisu podržane. Surgical edit: swappali Stripe SDK, ažurirali webhook handler, testirali s production datom. 3 dana posla, zero downtime.

Loš admin dashboard: Founder radio svaki report ručno kroz MySQL klijent. Izgradili admin panel s 6 najčešćih query-ja. Laravel backend ostao netaknut, samo dodali novi endpoint i React dashboard. 2 tjedna, ogromna ušteda vremena.

Kada ipak treba rewrite (budimo pošteni)

Nismo dogmatični. Ponekad rewrite jest pravi potez:

• Arhitektura blokira sve buduće feature-e (npr. monolith koji mora biti multi-tenant SaaS)

• Framework više nije maintainan i ima security issue-e koje ne možeš patchati

• Kod je toliko confusing da onboarding novog developera traje 2 mjeseca

• Business pivot — product se toliko mijenja da stari kod ne odgovara uopće

Ali i tada, radimo fazno. Ne bacamo sve odjednom. Gradimo novi sustav dok stari radi, migriramo dio po dio, testiramo s pravim korisnicima.

Kod je alat, ne umjetničko djelo

Developer ego voli čist kod. Founder ego voli profitabilan business. Naš posao je balansirati to.

Surgical edits nisu sexy. Ali su brzi, jeftini, i rješavaju stvarni problem bez da unište momentum tvog businessa.

Ako imaš legacy sustav koji "treba rewrite", prije nego što potrošiš 6 mjeseci i 50.000€ — pitaj se: što točno ne radi? Može li se to riješiti bez bacanja cijelog sustava?

Najčešće može. I trebalo bi.

Javi se ako te zanima kako bi surgical pristup izgledao za tvoj projekt — razgovor ne košta ništa, a možda ti uštedi mjesece posla.