Proč verzovat kód, i když pracujete na projektu sami?

Nejčastější začátečnická chyba je začít nástroji. Tým koupí nebo rozjede několik služeb, postaví první pipeline a čeká, že se kultura změní sama. Jenže DevOps stojí na dohodách: kdo schvaluje změny, kdo nese odpovědnost za incident, smí běžet neúspěšný build, než se začne řešit. Bez těchto domluv je automatizace jen rychlejší způsob, jak vyrábět chaos. První rekonstrukce koupelny krok za krokem proto není instalace, ale krátká schůzka, na které se sepíše, jak dnes změna putuje od nápadu do produkce a kde se zdržuje.

Nakonec myslete na zálohu a sdílení. Lokální repozitář je fajn, ale poškozený disk znamená konec. Nastavte si vzdálený repozitář, kam budete pravidelně nahrávat změny. I když pracujete sólo, získáte tím klid a možnost pracovat z jiného počítače. Před každým nahráním si projděte, co přesně odesíláte, ať neposíláte rozdělanou práci nebo citlivá data. Verzování není jednorázový úkol, ale návyk. Čím dřív ho přijmete za vlastní, tím méně času strávíte hašením požárů a tím víc prostoru zbyde na skutečné programování.

Statická analýza a formátování rozhodují o každodenní pohodě Druhé kritérium je podpora nástrojů, které kontrolují kód ještě před spuštěním. Hledej prostředí, které umí spustit kontrolu typů a hlásit chyby přímo v editoru, ne až v terminálu. Stejně důležité je automatické formátování při uložení. Nastav ho jednou a nech ho pracovat na pozadí. Pokud formátovač koliduje s dalším nástrojem, vznikají hádky o mezery a zbytečné rozdíly v gitu. Vyber jeden nástroj pro formátování a jeden pro kontrolu stylu, ne tři zároveň.

Během diskuze držte tři kategorie: co bylo dobré, co bylo špatné a co je nejisté. Třetí kategorie je často nejužitečnější, protože se v ní skrývají věci, o kterých se mlčí. Každý bod se musí převést na rozhodnutí: buď se změní, nebo se výslovně řekne, proč se měnit nebude. Neslibujte, že se něco udělá, když na to není kapacita. Prázdný slib je horší než žádný, protože příští retrospektiva začne nedůvěrou.

U rozsáhlejších projektů oceníš skok na definici a zpět. Otestuj to na cizí knihovně, ne jen na vlastním kódu. Prostředí, které neumí dohledat definici v nainstalovaném balíčku, ti při ladění moc nepomůže. Stejně tak si ověř, jak zvládá velké soubory. Otevři soubor s několika tisíci řádky a zkus osvětlení v obýváku něm hledat. Zamrzání při každém stisku klávesy je signál, že dané prostředí není pro tvůj styl práce vhodné, i kdyby mělo sebelepší vzhled.

Nezapomínej na ladicí běh. Nastav breakpoint, spusť program a zkontroluj, jestli vidíš hodnoty proměnných v okamžiku zastavení. Některá prostředí vyžadují doplňkový konfigurační soubor, jiná fungují okamžitě. Pokud ladění vyžaduje ruční zápis konfigurace, je to přijatelné, ale jen když rozumíš každému řádku. Zkopírovaná konfigurace bez pochopení bývá častým zdrojem chyb, které se projeví až za běhu.

Instalace je přímočará. Vytvořte virtuální prostředí, aktivujte ho a nainstalujte pytest pomocí správce balíčků. Ověření provedete příkazem pytest --version. Testy se ukládají do souborů, jejichž název začíná na test_ nebo končí na _test. Samotné testovací funkce musí mít také prefix test_. pytest je sám najde bez jakékoli registrace. Spuštění je pak otázkou příkazu pytest v kořeni projektu. Pro podrobnější výstup použijte pytest -v, pro zastavení po první chybě pytest -x.

Poslední věc, která rozhoduje o výsledku, je tón. Zpětná vazba nemá být obhajoba ani hodnocení člověka. Když někdo řekne, že něco nefunguje, není to útok. Facilitátor to musí říct nahlas, jinak se lidé začnou bránit a diskuze se změní v hádku o vině. Struktura drží emoce na uzdě jen do chvíle, kdy ji někdo začne používat jako zbraň. Proto je lepší mluvit o procesech a rozhodnutích než o lidech a jejich vlastnostech.

Začněte tím, že si vyberete nástroj. Dnes je standardem Git, ale klidně můžete použít i jiný distribuovaný systém. Rozdíl pocítíte hlavně v tom, jak pohodlně se větví a slučují změny. Pro webové vývojáře je klíčové, aby šel snadno propojit s editorem a abyste nemuseli přemýšlet nad každým příkazem. Nainstalujte si Git, ověřte verzi v terminálu a nastavte si jméno a e-mail, které se budou zapisovat do historie. To je vše, co potřebujete pro první commit.

První commit by měl obsahovat základní kostru projektu. Pak už postupujte po malých krocích. Každá změna, která dává smysl sama o sobě, si zaslouží vlastní commit s výstižnou zprávou. Vyhněte se hromadným commitům typu „oprava" nebo „úpravy". Zprávy pište v rozkazovacím způsobu a snažte se do první řádky vejít do padesáti znaků. Větší celek pak popište v delším textu. Díky tomu se v historii vyznáte i po měsících a snadno dohledáte, kdy a proč se něco změnilo.