Verzování, které zabíjí spolupráci: kde začátečníci chybují

Než stránku zveřejníte, zkuste ji otevřít v jiném prohlížeči a zmenšit okno na šířku telefonu. Zkontrolujte, zda se nic nepřekrývá a zda se text dá číst bez vodorovného posouvání. Platí, že jednoduchá stránka, která se načte rychle a drží strukturu, obstojí lépe než přeplácaný kód. Kdo pochopí rozdíl mezi obsahem a vzhledem, tomu stačí základy k tomu, aby postavil funkční web a nemusel vše předělávat.

První konkrétní krok: oddělte reprezentaci od identity. Nikdy neposílejte klientům interní databázové klíče jako primární identifikátor v URL. Místo „/objednavky/4711" použijte stabilní, veřejný identifikátor, který si sami generujete a který přežije migraci tabulek. Když se datový model změní – sloučíte tabulky, přejdete na UUID, rozdělíte entitu – veřejné ID zůstane stejné a klienti nic nepoznají.

Na co se zapomíná nejčastěji: nastavit si jméno a e-mail, aby byly commity dohledatelné, a zkontrolovat, že v repozitáři nejsou přístupové údaje. Klíče, hesla a tokeny se do historie dostanou snadno a odstranit je zpětně je otrava. Pokud se to stane, okamžitě tyto údaje zneplatněte, ne až po úklidu historie. Dále si zvykněte před každým commitem spustit, co se spustit dá – testy, kontrolu stylu nebo alespoň build. Verzování samo o sobě kvalitu nehlídá, jen uchovává to, co mu předáte.

Nemíchejte odpovědnosti a nestyďte se psát komentáře Kód, který zároveň počítá, formátuje a posílá data na obrazovku, se nedá testovat ani znovu použít. Oddělte logiku od vstupu a výstupu. Funkce, která jen vrací hodnotu, se testuje snadno; funkce, která přímo mění DOM, se testuje špatně. Stejně tak nemíchejte asynchronní a synchronní operace v jedné funkci, pokud to není nutné — výsledkem bývá nečitelný řetězec .then() a await promíchaný dohromady. Držte se jednoho stylu v celém souboru.

Než napíšeš samotný test, zjisti, jaký testovací nástroj už v projektu je. V jazycích jako Java, C# nebo JavaScript existuje řada frameworků a většina projektů má alespoň jeden nakonfigurovaný. Podívej se do konfiguračních souborů a do složky s testy. Pokud tam žádný není, zvol ten nejjednodušší, který umí spouštět testy z příkazové řádky. Nemusíš řešit pokrytí ani mockování, teď jde jen o to, aby jeden test proběhl a měl jasný výsledek.

Začněte tím, že si v nastavení klávesových zkratek vypíšete všechny akce obsahující slovo refactor nebo rename. Projděte seznam a ke třem nejčastějším přiřaďte kombinaci, kterou zvládnete jednou rukou. Typicky jde o přejmenování symbolu, přesun do jiného souboru a extrakci proměnné nebo metody. Pokud si nejste jistí, co která akce dělá, spusťte ji na cvičném projektu, ne na produkčním kódu. Zkratky se učí svalovou pamětí, ne čtením dokumentace.

Struktura, která drží test pohromadě Každý test má tři části: příprava, akce a ověření. V přípravě vytvoříš vstupní hodnoty a objekty. V akci zavoláš testovanou funkci. V ověření porovnáš skutečný výsledek s očekávaným. Tuhle strukturu dodrž i v prvním testu, i když bude mít jen tři řádky. Pojmenuj test tak, aby z názvu bylo jasné, co se testuje a co se očekává – například „secti_dve_kladna_cisla_vrati_soucet". Název testu je dokumentace pro tebe i pro kolegy.

První unit test vzniká nejlépe ve chvíli, kdy máš v kódu malou funkci, která dělá jednu věc a vrací hodnotu. Nemusí to být nic složitého – stačí funkce, která sečte dvě čísla, převede formát data nebo ověří, zda je řetězec prázdný. Vyber si právě takovou funkci. Pokud začneš testovat metodu, která sahá na databázi, síť nebo souborový systém, první test tě odradí dřív, než ho dokončíš.

Poslední pravidlo zní: verzujte i drobnosti a průběžně. Odkládat první commit do chvíle, kdy je vše hotové, znamená přijít o celou historii rozhodování. Radši méně souborů a častěji než jeden velký krok jednou za měsíc. Verzování není administrativa navíc, je to nástroj, který vám umožní vrátit se k funkčnímu stavu, porovnat varianty a vysvětlit, proč je kód takový, jaký je.

Hlavní větev není pracovní plocha Druhá častá chyba je představa, že stačí commitovat a nahrávat rovnou do hlavní větve. U malého projektu to chvíli funguje, ale jakmile se přidá druhý člověk nebo experimentální úprava, začne vznikat zmatek. Zaveďte jednoduché pravidlo: každá změna, která má vlastní účel, dostane vlastní větev. Vytvořte ji z aktuálního stavu hlavní větve, pracujte v ní, commitujte po malých krocích a teprve hotovou věc sloučte zpět. Malé commity s výstižnou zprávou vám po půl roce řeknou, proč se řádek změnil. Zprávy typu „oprava" nebo „úpravy" tuto informaci nesdělují a při hledání chyby jsou k ničemu.