Záchrana, refaktoring, alebo prepis? Ako sa rozhodnúť, čo s kódom postaveným s AI

Máte aplikáciu postavenú s AI zachrániť, refaktorovať, alebo prepísať?#

Vo väčšine prípadov najprv zachrániť. Ak používatelia dokážu prejsť hlavným scenárom a dátový model zhruba zodpovedá biznisu, najrýchlejšia a najmenej riskantná cesta je opraviť bezpečnosť, konfiguráciu a spoľahlivosť na mieste a potom refaktorovať časti, ktoré meníte najčastejšie. Prepis je opodstatnený iba vtedy, keď sú chybné samotné základy, a takmer vždy by mal prebiehať postupne.

Táto odpoveď frustruje obe strany. Zakladatelia, ktorí majú dosť kódu vygenerovaného AI, chcú čistý štart. Inžinieri, ktorí ho zdedia, často chcú to isté, pretože prepisovanie pôsobí produktívnejšie než čítanie. Kód, ktorý vidíte, však len zriedka predstavuje drahú časť. Drahé je správanie, ktoré nikto nezapísal — okrajové prípady, na ktoré sa používatelia už spoliehajú, dáta, ktoré už sú v produkcii, integrácie, ktoré fungujú z dôvodov, ktoré si nikto nepamätá.

„Skoro správne“ je bežný stav aplikácie postavenej s AI pri spustení. Skoro správne sa zvyčajne dá opraviť. Otázka je, koľko zo základov spadá do toho „skoro“.

Čo vlastne znamená záchrana, refaktoring a prepis?#

Líšia sa tým, čo sa mení a čo zostáva. Záchrana mení minimum potrebné na bezpečnú prevádzku v produkcii. Refaktoring mení vnútornú štruktúru bez zmeny správania. Prepis nahrádza implementáciu a zvyčajne aj dátový model, pričom sa snaží správanie zachovať.

• Záchrana — zaplátať bezpečnostné diery (autorizácia, uniknuté tajné kľúče, neoverené webhooky), opraviť konfiguráciu, pridať monitoring chýb, zálohy a testy okolo kritických scenárov. Architektúra zostáva.
• Refaktoring — preštruktúrovať kód, ktorý spomaľuje každú zmenu: duplicitná logika, komponenty, ktoré robia päť vecí naraz, biznisové pravidlá roztrúsené medzi UI a databázou. Správanie zostáva; testy to dokazujú.
• Prepis — postaviť novú implementáciu, často na inom dátovom modeli alebo platforme, a presunúť na ňu používateľov aj dáta.

Aké signály ukazujú na jednotlivé možnosti?#

Skôr než sa pozriete na štýl kódu, pozrite sa na dátový model a históriu zmien. Škaredé komponenty sa opravia lacno. Schéma, ktorá nedokáže zachytiť váš biznis, nie.

Signály pre záchranu

• [ ]Používatelia dokážu prejsť hlavným scenárom od začiatku do konca.
• [ ]Tabuľky zhruba zodpovedajú skutočným veciam, ktoré predávate alebo spravujete.
• [ ]Problémy, o ktorých viete, sa týkajú bezpečnosti, nasadenia, platieb, spracovania chýb alebo výkonnostných úzkych miest.
• [ ]Viete vymenovať päť scenárov, na ktorých záleží, a väčšinou fungujú.

Signály pre refaktoring

• [ ]Malé funkcie trvajú dni, pretože tá istá logika existuje na viacerých miestach.
• [ ]Oprava jednej chyby spoľahlivo vytvorí ďalšiu neďaleko.
• [ ]Väčšina zmien sa sústreďuje do niekoľkých súborov alebo modulov (pozrite git log --stat).
• [ ]Nikto, človek ani AI, nedokáže zmeniť časť aplikácie bez toho, aby prečítal celú.

Signály pre prepis

• [ ]Dátový model je chybný v jadre — napríklad tabuľky pre jedného používateľa pri produkte, ktorý musí byť multi-tenant, alebo peniaze uložené ako float naprieč celou schémou.
• [ ]Platforma nedokáže to, čo produkt potrebuje (no-code backend, ktorý nezvládne úlohy, compliance ani integrácie, ku ktorým ste sa zaviazali).
• [ ]Integrite dát sa nedá dôverovať a nedá sa opraviť na mieste.
• [ ]Reálneho používania je zatiaľ málo, takže je málo správania, ktoré treba zachovať.

Koľko jednotlivé možnosti naozaj stoja?#

Priamou cenou je čas inžinierov. Väčšou cenou je to, čo tento čas vytlačí. Dlh, ktorý necháte tak, zdaňuje každú budúcu funkciu; prepis zastaví roadmapu a míňa peniaze na znovupostavenie toho, čo už existuje.

To je argument proti ignorovaniu problému, nie argument za prepis. Prepis má vlastné náklady, ktoré sa ľahko podcenia:

• Zmrazenie funkcií. Kým sa stavia nový systém, starý dostáva iba urgentné opravy — a konkurencia ďalej dodáva.
• Znovuobjavené požiadavky. Každý tichý okrajový prípad, ktorý stará aplikácia zvládala, treba nájsť znova, často až prostredníctvom používateľov.
• Migrácia dát. Presun produkčných dát do novej schémy si vyžaduje skripty, generálky, validáciu a plán návratu.
• Dva systémy. Až do prepnutia platíte za prevádzku, monitoring a zabezpečenie oboch.

Náklady na záchranu a refaktoring sa ohraničujú ľahšie, pretože každá zmena je malá a dá sa samostatne naceniť aj overiť. Preto ich štruktúrujeme ako šprinty s pevným rozsahom, nie ako otvorenú hodinovú prácu.

Ak musíte prepisovať, použite vzor strangler fig#

Vzor strangler fig („škrtiaci fikus“), ktorý opísal Martin Fowler, nahrádza systém po častiach namiesto naraz. Pred existujúcu aplikáciu postavíte smerovaciu vrstvu, v novom systéme postavíte jednu schopnosť, presmerujete na ňu príslušnú prevádzku a opakujete, kým starému systému nezostane nič na práci. Stará aplikácia pritom celý čas obsluhuje používateľov.

1. Vložte šev dopredu. Reverse proxy, edge middleware alebo API gateway, ktoré vedia smerovať podľa cesty alebo funkcie.
2. Vyberte prvý rez. Zvoľte niečo hodnotné a dobre ohraničené — často oblasť s najhoršími chybami alebo najväčším počtom zmien.
3. Postavte ho nanovo, s testami. Vrátane dát, ktoré vlastní, a rozhodnite, ako sa budú dáta počas prechodu synchronizovať so starým systémom.
4. Presmerúvajte prevádzku postupne. Za feature flagom, najprv pre interných používateľov, potom pre percento a nakoniec pre všetkých.
5. Zmažte starú cestu v kóde. Rez je hotový, keď stará implementácia zmizne, nie keď existuje nová.

// Next.js proxy (middleware) ako šev pre strangler fig:
// migrované cesty idú do novej služby, všetko ostatné zostáva v starej aplikácii.
import { NextResponse, type NextRequest } from "next/server";

const MIGRATED = ["/billing", "/api/invoices"];

export function proxy(req: NextRequest) {
  const path = req.nextUrl.pathname;
  if (MIGRATED.some((p) => path === p || path.startsWith(p + "/"))) {
    return NextResponse.rewrite(new URL(path + req.nextUrl.search, process.env.NEW_SERVICE_URL));
  }
  return NextResponse.next();
}

Smerovanie je tá ľahšia časť. Ťažšie sú dáta. Kým bežia oba systémy, každá časť dát potrebuje práve jedného vlastníka: buď ich číta a zapisuje nová služba a stará aplikácia ide cez ňu, alebo zostáva zdrojom pravdy stará databáza a nový kód z nej číta až do prepnutia. Zapisovanie tých istých záznamov z oboch systémov bez jasného vlastníka je presne to, čím sa strangler migrácie dostanú do rozchodu dát, ktorý už nikto nezosúladí. Vlastníctvo určte pre každý rez, zapíšte ho a pridajte kontrolu, ktorá obe strany porovnáva, až kým starú cestu nezmažete.

Tento vzor premení jednu veľkú stávku typu všetko alebo nič na mnoho malých, vratných stávok. Ak sa rez nevydarí, presmerujete prevádzku späť. Ak sa v polovici zmenia priority, stále máte funkčný produkt.

Ako sa rozhodnúť na základe dôkazov#

Rozhodujte po krátkom štruktúrovanom audite, nie podľa prvej reakcie na kód. Audit by mal písomne odpovedať na štyri otázky: čo je nebezpečné práve teraz, čo vás spomaľuje, či dátový model unesie ďalšiu fázu produktu a koľko šprintov by stála každá z možností.

Ak nedokážete ukázať na časť základov, ktorú nemožno opraviť na mieste, prepis zatiaľ nepotrebujete.

Presne tak funguje náš Rescue Audit. Má pevnú cenu 690 € a trvá 3 pracovné dni. Prejdeme repozitár, databázu a jej politiky, prihlasovanie, platby, nasadenie a monitoring a potom vám odovzdáme mapu rizík zoradenú podľa priority a odporúčanie — záchrana, refaktoring, alebo prepis — s písomným zdôvodnením. Ak s nami pokračujete, cena auditu sa vám v plnej výške započíta do záchrany. Záchrana a refaktoring potom prebiehajú v 2-týždňových šprintoch s pevným rozsahom od 4 900 €.

Prepis neodporučíme, pokiaľ ho audit písomne nepreukáže. Nie preto, že by prepis bol vždy zlý, ale preto, že dôkazné bremeno by mala niesť najdrahšia možnosť.

Ako vám môže pomôcť Backloo#

Začnite bezplatným 60-sekundovým auditom pripravenosti a zistite, ktoré oblasti sú najslabšie. Ak chcete úplný písomný verdikt, stránka záchrany AI aplikácií opisuje audit aj šprinty, ktoré naň nadväzujú, a backendové systémy pokrývajú prípady, keď základy naozaj treba nahradiť. Kód, repozitár aj cloudové účty po celý čas zostávajú vaše. Ak ide hlavne o pripravenosť na produkciu, možno vám bude stačiť náš checklist pred spustením a checklist Supabase RLS — alebo sa nám ozvite a opíšte, čo máte.