Refaktoring, nebo přepsat od nuly? Jak se rozhodnout

Refaktoring je úprava kódu, která zlepší jeho strukturu a nezmění, co software dělá. Refaktoring, nebo přepsání od nuly, je rozhodnutí o tom, kolik měsíců roadmapy jste ochotni zastavit. Většinou vyhraje refaktoring po malých krocích, protože produkt během něj dál vydělává.

Přepsání od nuly dává smysl ve třech případech: kód dělá špatnou věc, nevlastníte ho, nebo stojí na technologii bez podpory. Níže je rozhodovací tabulka a postup, jak refaktorovat bez zastavení roadmapy.

AI dnes píše všechen náš kód, za výsledek ručí senior. Filip předtím roky vyvíjel SaaS, který denně používalo 60 000+ lidí. Ani jednou se nepřepisoval od nuly. Měnil se malými změnami přes review, přímo v živém produktu.

Proč je velké přepsání skoro vždy dražší, než se zdá?

Přepsání vypadá čistě, protože nový kód ještě nemá historii. Tu historii ale potřebujete. Za každou divnou podmínkou ve starém kódu bývá něčí reklamace.

Nejčastější důvody, proč se přepsání prodraží:

Kdy refaktorovat a kdy přepsat: rozhodovací tabulka

Pozor na poslední řádek. „Nikdo tomu nerozumí“ je nejčastější argument pro přepsání. Zároveň nejhorší. Nový tým, který starému kódu nerozumí, ho přepíše bez oprav, které v něm jsou.

Přepsání bývá i nejjednodušší upsell. Při auditu produktu jednoho zakladatele se nabízelo monorepo a přepsání backendu do TypeScriptu. Napsali jsme opak: repozitáře jsou v pořádku, TypeScript přidávejte po modulech a začněte přihlášením a právy.

Jak refaktorovat bez zastavení roadmapy?

AI tu dělá to, co je pomalé a nudné. Testy na existující chování, přesuny kódu, přejmenování. Senior rozhoduje, co se mění a v jakém pořadí. Jaká pravidla na to AI dáváme, popisujeme v článku Pravidla pro AI kód v týmu.

Bez testů a review vám AI technický dluh jen zrychlí. Proto říkáme, že agent je model plus rámec. Rámec je to, co špatnou změnu zastaví.

Kdy je přepsání od nuly správná volba?

Když kód nevlastníte. Pokud původní systém nepatří vám, není co refaktorovat: postaví se nový a data se přesunou.

I při přepsání platí stejné pořadí. Nejdřív data a pochopení, co systém opravdu dělá. Potom obrazovka po obrazovce, ne všechno v jeden den.

Před rozhodnutím si projděte šest bodů. Zaškrtněte, co o vašem systému platí:

Nejvíc váží čtvrtý bod. Pokud kód dělá správnou věc, jen špatně, refaktorujte.

Kdy to nedoporučujeme

• Máte seniora, který systém zná a má na něj čas. Refaktorujte sami. Tabulka výše vám stačí.
• Systém se za pár měsíců vypíná. Neinvestujte do kódu, který končí. Investujte do přesunu dat.

Chcete rozhodnout s někým, kdo to dělá denně?

Senior se zapojí do vašeho repozitáře a pull requestů od prvního dne. Nejdřív testy, potom změny po malých krocích a roadmapa běží dál. Takhle pracujeme jako externí vývojář pro produktový tým.

Napište nám, která část kódu vás brzdí. Ozveme se do dvou pracovních dnů a společně vybereme, co vyřešíme jako první.

Pokud si chcete nejdřív promluvit, domluvte si meeting na 15 minut s Filipem.

Kterou část vašeho kódu byste nejraději zahodili, a proč?

Časté otázky

Kdy refaktorovat a kdy přepsat kód od nuly?

Refaktorujte, když kód dělá správnou věc, ale špatně se mění. Přepište ho, když dělá špatnou věc, kód nevlastníte nebo technologie ztratila podporu. I pak přepisujte po částech, ne najednou.

Dá se refaktorovat bez testů?

Dá, ale je to hazard. Nejdřív napište testy na současné chování, i s jeho chybami. Teprve potom měňte kód. Bez testů se o chybě dozvíte od zákazníka.

Jak dlouho trvá refaktoring?

Nemá pevný konec a to je v pořádku. Dělá se průběžně v běžných pull requestech, tam, kde právě pracujete. Samostatný refaktoringový projekt na měsíce se většinou nedokončí.

Pomůže AI s refaktoringem?

Ano, při psaní testů, přesunech kódu a přejmenování. Rozhodnutí, co měnit a v jakém pořadí, zůstává na seniorovi. Bez testů a review AI chyby jen zrychlí.