Vyberte jednu aplikaci, ideálně malou a dostatečně důležitou, aby její selhání bolelo, ale ne tak kritickou, aby případný výpadek ohrozil firmu. Zmapujte ruční kroky: sestavení, testy, kontrola závislostí, nasazení do testovacího prostředí, schválení, nasazení do produkce. Každý ruční krok, který lze zautomatizovat, nahraďte skriptem nebo fází pipeline. Cílem není dokonalost, ale to, aby šla změna nasadit jedním příkazem a aby selhání bylo vidět dřív než v produkci. Teprve až tato jedna cesta funguje spolehlivě, rozšiřujte na další aplikace.

Kdy se vyplatí centrální konfigurace a kdy ne Centrální konfigurace dává smysl ve chvíli, kdy tým pravidelně řeší stejné nastavení: pravidla pro formátování, kontrolu typů, testovací skripty nebo nastavení editoru. Tyto věci patří do jednoho místa, odkud si je každý projekt vezme. Naopak věci specifické pro konkrétní službu, jako jsou cesty k datům nebo parametry nasazení, mají zůstat lokálně. Pokud se snažíte centralizovat i něco, co se v každém projektu liší, vznikne z konfigurace nečitelný soubor plný výjimek. To je typický důvod, proč se sjednocení po čase rozpadne.

Pro rychlejší práci se vyplatí naučit se tři až čtyři klávesové zkratky, které používáte denně: přejmenování, extrakce, přesun a změna signatury. Zbytek nechte na kontextovém menu. Důležité je také pravidelně spouštět testy po každé automatické změně. Testy odhalí případy, kdy nástroj změnil chování jinak, než jste čekali — například kvůli přetíženým metodám nebo generikům.

Ruční přepisování názvů proměnných, přesouvání metod nebo rozdělování dlouhých funkcí je pomalé a náchylné k chybám. Vestavěné nástroje v editoru nebo IDE zvládnou stejnou práci za zlomek času, pokud je používáte správně. Klíčem není znát všechny klávesové zkratky, ale vědět, kdy který nástroj nasadit a kde je jeho limit.

Začni názvy. Proměnná data, temp nebo x neříká nic. Místo d napiš datumObjednavky, místo arr klidně seznamKurzu. U funkcí používej sloveso: spocitejCenu(), nactiUzivatele(). Pokud název potřebuje komentář, je pravděpodobně špatný. Boolean pojmenuj jako tvrzení: jePrihlasen, maOpravneni, ne flag.

Praktický postup je postupný. Vyberte jednu oblast, například formátování kódu, a sjednoťte ji jako první. Zaveďte ji tak, aby fungovala i bez ručního zásahu, a teprve po ověření přidejte další. U každé změny si předem řekněte, jak poznáte, že funguje: sníží se počet konfliktů při slučování, zmizí opakované opravy stejné chyby, nový člen týmu spustí projekt bez dodatečného vysvětlování. Bez těchto měřítek se sjednocení zvrhne v debatu o preferencích.

Základní volba stojí mezi jedním sdíleným repozitářem a více repozitáři s centrální konfigurací. Sdílený repozitář znamená, že všechny části projektu leží pohromadě a konfigurační soubory jsou na jednom místě. Výhodou je okamžitá viditelnost změn a jednodušší zavádění nových členů týmu. Nevýhodou je horší izolace: změna v jedné části může nechtěně ovlivnit jinou a nástroje musejí zvládat větší objem dat. U více repozitářů je potřeba vyřešit, odkud se konfigurace bere a jak se synchronizuje.

1. Pište v rozkazovacím způsobu a v přítomném čase. Formulace jako "Přidat validaci vstupu" nebo "Opravit chybu v parseru" čte člověk přirozeně. Minulý čas ("Přidal jsem validaci") svádí k tomu psát o sobě, ne o změně. První řádek by měl být krátký, ideálně do 50 znaků, a měl by říct, co commit dělá, ne proč jste ho vytvořili vy.

Kdy je lepší nástroj vypnout a udělat změnu ručně Automatické extrahování metody nebo konstanty funguje spolehlivě u krátkých, jasně ohraničených bloků. Jakmile ale blok obsahuje vnořené cykly, výjimky nebo závislosti na vnějším stavu, nástroj často vytvoří metodu s příliš mnoha parametry. To je signál, že refaktoring potřebuje nejdřív zjednodušit logiku, ne ji přesouvat. V takovém případě je lepší změnu rozdělit na dvě fáze: nejprve upravit strukturu ručně, potom nechat IDE doladit názvy a přesuny.

5. Konzistence je důležitější než dokonalost. Tým by se měl dohodnout na jednotném stylu: jazyk, čas, formát prvního řádku, používání předpon. Ať už zvolíte češtinu nebo angličtinu, držte se jí. Pokud tým používá šablonu, vyplňte ji vždy. Nejde o to psát literární díla, ale o to, aby každý commit nesl jasnou informaci. Pravidelná kontrola logu při code review pomůže udržet kvalitu.

Nejčastější začátečnická chyba je refaktoring „na jeden zátah" bez průběžné kontroly. Moderní IDE umí přejmenovat symbol napříč celým projektem, ale jen pokud správně rozpozná, co symbol znamená. Pokud máte v kódu řetězce, dynamické přístupy nebo reflexi, přejmenování je bezpečné jen tehdy, když nástroj upozorní na nejednoznačnosti. Vždy si před potvrzením projděte náhled změn, který IDE nabízí.