Starý kód není automaticky špatný. Pokud funguje, nepadá a tým mu rozumí, přepis může napáchat víc škody než užitku. Problém nastává ve chvíli, kdy každá změna trvá neúměrně dlouho, testy chybí nebo se nový vývojář bojí čehokoli dotknout. To jsou signály, že se vyplatí zvážit refaktoring či postupný přepis. Rozhodnutí by nemělo vycházet z pocitu, že kód je „ošklivý", ale z měřitelných potíží: rostoucí počet chyb, pomalé nasazování, nemožnost pokrýt logiku testy.

Než začnete cokoli přepisovat, oddělte to, co lze měnit průběžně, od toho, co vyžaduje zásadní zásah. U menších modulů stačí postupný refaktoring – přidat testy, rozdělit dlouhé funkce, odstranit mrtvý kód. U velkých monolitů je realističtější strategie „strangler fig": nová část běží vedle staré a provoz se na ni přesouvá po částech. Pomůže také držet se zásad, které popisuje průvodce jak psát čistý kód v JavaScriptu – čitelnost a malé funkce snižují riziko, že se při migraci něco rozbije.

Klíčové je nezasahovat do produkce naslepo. Zaveďte feature flagy, aby šlo novou verzi kdykoli vypnout bez nasazení. Pište testy ještě před přepisem, ideálně charakterizační, které zachytí současné chování i s jeho chybami. Data migrujte po malých dávkách a vždy mějte možnost vrátit se zpět. Sledujte metriky – chybovost, latenci, využití – a porovnávejte starou a novou cestu vedle sebe. Pokud se čísla zhorší, přepis zastavte dřív, než se problém rozšíří.

Nakonec počítejte s tím, že přepis nikdy není jen technická záležitost. Tým musí vědět, proč se to dělá, jaký je plán a kdo za co odpovídá. Bez jasné komunikace vzniká paralelní vývoj dvou verzí a únava z nekonečné migrace. Lepší je menší, dokončený krok než velkolepý plán, který zůstane v polovině.