Refaktoring

Refaktoring nevyrobí viditelnou funkci, takže nikdy nevyhraje nad požadavkem zákazníka s termínem. Jde do backlogu, backlog je plný a ta část kódu, která ho potřebuje nejvíc, dál roste, protože přes ni teče každá nová funkce. Za půl roku by „později“ stálo třikrát víc a to z něj zase dělá něco, co nelze obhájit.

Cesta ven je přestat z něj dělat samostatný projekt. Refaktorujte to, čeho se právě dotýkáte, jako součást téže změny: checkout potřebuje slevy, tak nejdřív rozbijte šestisetřádkovou funkci na ceny na testovatelné části a pak přidejte slevy. Stejný tiket, stejné review, lepší výsledek. Výjimka je velká strukturální práce — jedna sdílená komponenta místo čtyř kopií — a ta si zaslouží vlastní rozpočet i vlastní příběh.

Nech kód trochu lepší, než jsi ho našel. Pokaždé, když soubor otevřete, opravte jednu drobnost: zavádějící název, duplicitní pomocnou funkci, funkci se šesti parametry sraženou do jednoho objektu. Malé a stálé vyhrává nad velkým a vzácným úklidem, který se srazí s každou otevřenou větví a nikdy se pořádně nezrecenzuje.

To pravidlo má mez. Opravovat cokoli, na co cestou k deadlinu narazíte, udělá z jednoho úkolu pět a skutečnou změnu schová v moři šumu. Recenzent nepozná, co je oprava chyby a co úklid. Držte commity s refaktoringem oddělené od commitů s chováním a máte obojí: čitelný diff i čistší kód.

Refaktoring bez testů není refaktoring, ale doufání. Když oblast nemá pokrytí a není čas ho rychle doplnit, poctivé možnosti jsou dvě: napsat první test nad současným chováním, nebo to nechat být. Ani nějaké moduly si víc péče nezaslouží — report pro čtyři lidi v administraci nebo endpoint, který se příští kvartál ruší, je špatná investice.

Refaktoring navíc nikdy neopraví produktový problém. Když je proces matoucí, přepsání kódu ho jasnější neudělá. Nejdřív opravte proces a pak kód, který ho implementuje.