Záchrana, refaktoring, nebo přepis? Jak se rozhodnout, co s kódem postaveným s AI

Máte aplikaci postavenou s AI zachránit, refaktorovat, nebo přepsat?#

Ve většině případů nejdřív zachraňte. Pokud uživatelé dokážou projít hlavním procesem a datový model zhruba odpovídá byznysu, nejrychlejší a nejméně riskantní cestou je opravit zabezpečení, konfiguraci a spolehlivost na místě a potom refaktorovat části, které měníte nejčastěji. Přepis je oprávněný jen tehdy, když jsou špatně samotné základy, a téměř vždy by měl probíhat postupně.

Tahle odpověď frustruje obě strany. Zakladatelé, které kód od AI už unavuje, chtějí začít načisto. Inženýři, kteří ho zdědí, často chtějí totéž, protože přepisování působí produktivněji než čtení. Jenže kód, který vidíte, je málokdy ta drahá část. Drahé je chování, které nikdo nesepsal — okrajové případy, na které už uživatelé spoléhají, data, která už jsou v produkci, integrace, které fungují z důvodů, na které si nikdo nevzpomene.

„Skoro správně“ je normální stav aplikace postavené s AI při spuštění. A „skoro správně“ se obvykle opravit dá. Otázkou je, kolik ze základů spadá do toho „skoro“.

Co vlastně znamená záchrana, refaktoring a přepis?#

Liší se v tom, co se mění a co zůstává. Záchrana mění jen minimum potřebné k bezpečnému provozu v produkci. Refaktoring mění vnitřní strukturu, aniž by měnil chování. Přepis nahrazuje implementaci a obvykle i datový model, přičemž se snaží chování zachovat.

• Záchrana — zalepit bezpečnostní díry (autorizace, uniklé tajné klíče, neověřené webhooky), opravit konfiguraci, přidat monitoring chyb, zálohy a testy kolem kritických procesů. Architektura zůstává.
• Refaktoring — přestavět kód, který zpomaluje každou změnu: duplicitní logiku, komponenty, které dělají pět věcí najednou, byznysová pravidla rozházená mezi UI a databází. Chování zůstává; testy to dokazují.
• Přepis — postavit novou implementaci, často na jiném datovém modelu nebo platformě, a převést na ni uživatele i data.

Které signály ukazují na kterou možnost?#

Než se podíváte na styl kódu, podívejte se na datový model a historii změn. Ošklivé komponenty se opravují levně. Schéma, které neumí popsat váš byznys, ne.

Signály pro záchranu

• [ ]Uživatelé dokážou projít hlavním procesem od začátku do konce.
• [ ]Tabulky zhruba odpovídají skutečným věcem, které prodáváte nebo spravujete.
• [ ]Problémy, o kterých víte, se týkají zabezpečení, nasazení, plateb, ošetření chyb nebo výkonnostních úzkých míst.
• [ ]Dokážete vyjmenovat pět procesů, na kterých záleží, a ty většinou fungují.

Signály pro refaktoring

• [ ]Malé funkce trvají dny, protože stejná logika existuje na několika místech.
• [ ]Oprava jedné chyby spolehlivě vytvoří jinou kousek vedle.
• [ ]Většina změn se soustředí do několika souborů nebo modulů (zkontrolujte git log --stat).
• [ ]Nikdo, člověk ani AI, nedokáže změnit část aplikace, aniž by přečetl celou.

Signály pro přepis

• [ ]Datový model je špatně v jádru — například tabulky pro jednoho uživatele tam, kde musí být multi-tenant produkt, nebo peníze uložené napříč schématem jako float.
• [ ]Platforma neumí, co produkt potřebuje (no-code backend, který nezvládne úlohy, regulatorní požadavky nebo integrace, ke kterým jste se zavázali).
• [ ]Integritě dat nelze věřit a nelze ji opravit na místě.
• [ ]Skutečného používání je zatím málo, takže je málo chování, které by bylo potřeba zachovat.

Kolik jednotlivé možnosti skutečně stojí?#

Přímým nákladem je čas inženýrů. Větším nákladem je to, co ten čas vytlačí. Dluh, který necháte na místě, dál zdaňuje každou budoucí funkci; přepis pozastaví roadmapu a utrácí peníze za znovupostavení toho, co už existuje.

To je argument proti ignorování problému, ne argument pro přepis. Přepis má vlastní náklady, které se snadno podcení:

• Zmrazení funkcí. Zatímco se staví nový systém, ten starý dostává jen urgentní opravy — a konkurence dál dodává.
• Znovuobjevené požadavky. Každý tichý okrajový případ, který stará aplikace zvládala, je potřeba najít znovu, často až díky uživatelům.
• Migrace dat. Přesun produkčních dat do nového schématu vyžaduje skripty, zkoušky nanečisto, validaci a plán pro návrat zpět.
• Dva systémy. Až do přepnutí platíte provoz, monitoring a zabezpečení obou.

Náklady na záchranu a refaktoring se ohraničují snáz, protože každá změna je malá a dá se ocenit i ověřit samostatně. Proto je stavíme jako sprinty s pevným rozsahem, ne jako otevřenou práci za hodinovou sazbu.

Pokud musíte přepisovat, použijte vzor strangler fig#

Vzor strangler fig (škrticí fíkovník), který popsal Martin Fowler, nahrazuje systém po částech místo všeho najednou. Před stávající aplikaci postavíte směrovací vrstvu, v novém systému vytvoříte jednu schopnost, pošlete na ni odpovídající provoz a opakujete, dokud starý systém nemá co dělat. Stará aplikace po celou dobu obsluhuje uživatele.

1. Předsaďte rozhraní (seam). Reverse proxy, edge middleware nebo API gateway, která umí směrovat podle cesty nebo funkce.
2. Vyberte první část. Zvolte něco hodnotného a dobře ohraničeného — často oblast s nejhoršími chybami nebo nejčastějšími změnami.
3. Postavte ji nově, s testy. Včetně dat, která vlastní, a rozhodněte, jak se data během přechodu synchronizují se starým systémem.
4. Přesměrovávejte provoz postupně. Za feature flagem, nejdřív interním uživatelům, pak určitému procentu, pak všem.
5. Smažte starou cestu v kódu. Část je hotová, až když stará implementace zmizí, ne když nová existuje.

// Next.js proxy (middleware) jako rozhraní pro strangler fig:
// převedené cesty jdou na novou službu, vše ostatní zůstává ve staré aplikaci.
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();
}

Směrování je ta snadná část. Ta těžká jsou data. Dokud běží oba systémy, musí mít každý kus dat právě jednoho vlastníka: buď je čte a zapisuje nová služba a stará aplikace přistupuje přes ni, nebo zůstává zdrojem pravdy stará databáze a nový kód z ní čte až do přepnutí. Zápis stejných záznamů z obou systémů bez jasného vlastníka je přesně to, co u strangler migrací vede k rozjetým datům, která už nikdo nedokáže sesouhlasit. Vlastnictví rozhodněte pro každou část, sepište ho a přidejte kontrolu, která obě strany porovnává, dokud stará cesta nezmizí.

Tento vzor promění jednu velkou sázku typu všechno, nebo nic v mnoho malých a vratných sázek. Když se některá část nepovede, přesměrujete provoz zpět. Když se v půlce změní priority, pořád máte funkční produkt.

Jak se rozhodnout na základě důkazů#

Rozhodujte po krátkém strukturovaném auditu, ne podle první reakce na kód. Audit by měl písemně odpovědět na čtyři otázky: co je nebezpečné právě teď, co vás zpomaluje, jestli datový model unese další fázi produktu a kolik sprintů by stála každá z možností.

Pokud nedokážete ukázat na tu část základů, kterou nejde opravit na místě, přepis zatím nepotřebujete.

Přesně tak funguje náš Rescue Audit. Stojí pevně 690 € a trvá 3 pracovní dny. Projdeme repozitář, databázi a její policy, přihlašování, platby, nasazení a monitoring a dodáme mapu rizik seřazenou podle priority a doporučení — záchrana, refaktoring, nebo přepis — s písemným zdůvodněním. Pokud s námi budete pokračovat, cena auditu se vám do záchrany započte ze 100 %. Záchrana a refaktoring pak probíhají ve 2týdenních sprintech s pevným rozsahem od 4 900 €.

Přepis nedoporučíme, dokud ho audit písemně neprokáže. Ne proto, že by přepisy byly vždycky špatně, ale proto, že důkazní břemeno by měla nést ta nejdražší možnost.

Jak vám Backloo může pomoct#

Začněte bezplatnou 60sekundovou kontrolou připravenosti a zjistěte, které oblasti vypadají nejslabší. Pokud chcete úplný písemný verdikt, stránka záchrana AI aplikací popisuje audit i navazující sprinty a backendové systémy pokrývají případy, kdy základy opravdu potřebují vyměnit. Kód, repozitář i cloudové účty zůstávají po celou dobu vaše. Pokud jde hlavně o připravenost na produkci, může vám stačit náš checklist před spuštěním a checklist Supabase RLS — nebo se nám ozvěte a popište, co máte.