Rector

Rector je přesně ten typ nástroje, který začne dávat smysl ve chvíli, kdy se v projektu nahromadí příliš mnoho mechanických změn. Jednu třídu člověk upraví ručně. Deset tříd taky. Ale jakmile se bavíme o stovkách souborů, upgradu PHP, přechodu na novější verzi frameworku nebo sjednocení starých patternů, ruční práce přestává být dobrý nápad. Je pomalá, únavná a snadno v ní vznikají chyby.

Na Rectoru je pro mě zajímavé hlavně to, že se nesnaží být další formatter. Je to nástroj, který rozumí AST a umí dělat cílené refaktoringové kroky. Když se používá rozumně, může výrazně zkrátit práci na modernizaci codebase. Ne proto, že by za vývojáře rozhodoval, jak má aplikace vypadat, ale protože umí převzít nudnou a opakující se část práce.

Kde mi Rector dává smysl

Nejčastěji bych po Rectoru sáhl při upgradech PHP, Symfony nebo Laravel projektů, při čištění staršího kódu a při postupném zavádění novějších jazykových konstrukcí. Pokud se v aplikaci roky přidávaly funkce bez většího úklidu, často se najde hodně míst, kde jde bezpečně sjednotit zápis, doplnit typy, odstranit zastaralé postupy nebo převést starý pattern na současnější podobu.

Důležité je slovo postupně. Rector není nástroj, který bych pustil na velký projekt a bez čtení výsledku všechno sloučil. Mnohem lepší je rozdělit změny na malé kroky, spouštět ho v dry-run režimu, číst diff a průběžně pouštět testy. V takovém workflow je výborný, protože vývojáři nebere kontrolu. Jen mu odstraní velkou část mechanické práce.

Refaktoring, který se dá kontrolovat

U refaktoringu je největší problém důvěra. Pokud nástroj upraví stovky řádků, musím vědět, proč to udělal a jestli je změna bezpečná. Rector má v tomhle výhodu, protože pracuje přes pravidla. Člověk si může vybrat, jaké sady pravidel chce použít, co zapnout až později a co naopak do projektu nepatří.

Prakticky to znamená, že se dá postupovat po vrstvách. Nejdřív jednoduché a nízkorizikové úpravy, potom přísnější pravidla, později větší strukturální změny. Když je k tomu dobrá testovací sada, statická analýza a code review, Rector se stává poměrně bezpečným pomocníkem. Bez těchto pojistek může jen vyrobit hodně změn, které vypadají elegantně, ale nikdo jim pořádně nevěří.

Proč ho mít v CI

Rector nemusí být jen nástroj, který člověk spustí jednou za čas při velkém úklidu. Dává smysl i v CI, minimálně v dry-run režimu. Pokud projekt obsahuje pravidla, na kterých se tým shodl, může pipeline rychle ukázat, že nově přidaný kód jde proti domluvenému směru. To je často lepší než řešit stejné poznámky opakovaně v code review.

Samozřejmě bych byl opatrný s automatickým přepisováním bez kontroly. U některých pravidel je to v pořádku, u jiných chci vidět diff. Ale i samotný dry-run má hodnotu. Připomíná, že codebase nemá zůstávat stát na místě a že část údržby se dá udělat systematicky, ne jen podle nálady.

Na co si dát pozor

Rector není odpověď na špatnou architekturu. Neopraví doménový model, nevymyslí lepší hranice modulů a neřekne, které technické rozhodnutí bylo špatně. Umí ale pomoct s tím, aby se projekt dal snáz posouvat dál. U starší codebase je to někdy přesně to, co člověk potřebuje: nejdřív odstranit mechanický dluh, teprve potom řešit větší návrhové změny.

Nejlepší výsledky podle mě přicházejí ve chvíli, kdy je Rector součástí širšího vývojového procesu. Spustit pravidla, přečíst diff, pustit testy, zkontrolovat statickou analýzu a teprve potom změnu sloučit. V takovém režimu není Rector kouzelná automatika. Je to spíš velmi rychlý kolega na repetitivní refaktoring, kterému musí člověk pořád určovat mantinely.