Přepsat celou aplikaci od nuly zní lákavě, dokud si člověk neuvědomí, kolik byznys logiky je ukryté v kódu, kterému nikdo pořádně nerozumí. Nový projekt vypadá čistě jen do chvíle, než začnou přicházet požadavky na funkce, které starý systém řešil roky a nikdo je nikdy nezapsal. Refaktoring po částech je pomalejší, ale nevyžaduje zmrazení vývoje. Klíčem je zavést testy na kritické cesty dřív, než se čehokoli dotknete. Bez nich je každá změna riskantní a tým brzy ztratí odvahu cokoli upravovat.

Začněte tam, kde se kód mění nejčastěji. Složky, které se upravují každý sprint, mají největší návratnost investice do vyčištění. Izolujte moduly pomocí jasných rozhraní a postupně nahrazujte globální stav explicitními závislostmi. Pomůže také zavést lintovací pravidla, která nový špatný kód vůbec nepustí do repozitáře. Pokud si nejste jisti, jaké konvence nastavit, inspirujte se osvědčenými postupy na vyvojarska.cz, kde najdete praktické rady pro psaní čitelného kódu. Starý kód nemusí být dokonalý hned, stačí, aby byl o něco srozumitelnější než včera.

Nepodceňujte dokumentaci rozhodnutí. Komentář, který vysvětluje, proč nějaká funkce existuje, má větší cenu než popis toho, co dělá. Během refaktoringu si veďte seznam míst, která jste obešli, ať se k nim můžete vrátit. Zaveďte code review i pro malé změny, protože právě drobné úpravy často rozbijí něco neočekávaného. Důležité je měřit pokrok – počet testů, doba sestavení, počet otevřených issue. Bez metriky se refaktoring zvrhne v nekonečnou činnost bez konce.

Nakonec přijměte, že starý kód tu s vámi zůstane delší dobu. Cílem není dokonalost, ale udržitelnost. Každý sprint věnujte pár hodin údržbě a nestavte refaktoring jako projekt s koncem. Tým, který pravidelně čistí, nemá potřebu utíkat k přepisu na zelené louce. Vyhnete se tak měsícům bez nových funkcí a riziku, že nová verze bude mít stejné chyby jako ta stará.