V neposlední řadě si dejte pozor na přehnaný optimismus plynoucí z „známého prostředí". I když děláte podobný úkol jako minule, objeví se změny v knihovnách, v prostředí nebo v požadavcích. Vždy přidejte alespoň malou rezervu na neznámé. Když je úkol nový, klidně zdvojnásobte hrubý odhad – realita se tomu často blíží.<br>
<br>
<br>
<br>
Když odhadujete čas na vývojový úkol, snadno se zaměříte na viditelné činnosti – psaní kódu, návrh obrazovky, nastavení databáze. Skryté činnosti, jako jsou schůzky, čekání na odpověď, ladění, testování nebo psaní dokumentace, ale tvoří často 30 až 50 % celkového času. Pokud je nevezmete v úvahu, bude váš odhad vždy příliš optimistický.<br>
<br>
<br>
<br>
<img src="https://www.cenikyremesel.cz/upload/references/gallery/full/6145c1538cd14.jpg" style="max-width:420px;float:left;padding:10px 10px 10px 0px;border:0px;">Prakticky doporučuji: pro interní API, které obsluhuje vaši vlastní frontendu a vyvíjí se rychle, zvolte GraphQL. Pro veřejné API určené širokému spektru klientů, kde je důležitá stabilita a předvídatelnost, zůstaňte u REST. Pokud si nejste jisti, začněte s REST — je jednodušší a univerzálnější. GraphQL lze vždy přidat později, pokud se ukáže, že REST nestačí na rostoucí požadavky na výkon a flexibilitu.<br>
<br>
<br>
<br>
<span style="font-weight: bold;">Nejprve si definujte</span> měřitelné cíle. Typicky to může být zkrácení doby nasazení z týdne na jeden den, snížení počtu chyb v produkci nebo zmenšení čekací doby na testovací prostředí. Konkrétní čísla vám pomohou ověřit, jestli vaše snahy mají smysl. Nezavádějte změny plošně – vyberte jeden malý tým nebo jeden projekt, kde můžete nové postupy vyzkoušet bez velkého rizika.<br>
<br>
<br>
<br>
Skryté činnosti nejde odstranit, ale lze je odhadnout. Začněte si je zapisovat, počítejte s nimi a kontrolujte zpětně. Po třech až pěti úkolech uvidíte strukturu, která vám umožní dělat odhady, na které se dá spolehnout. Výsledkem nebude dokonalý plán, ale mnohem menší stres z nepředvídaných prodlev a lepší komunikace s ostatními.<br>
<br>
<br>
<br>
Důležité je také sledovat vlastní historii. Po dokončení úkolu si zapište, kolik času jste skutečně strávili, a porovnejte s odhadem. Časem zjistíte, že u některých typů úkolů děláte systematickou chybu – třeba podceňujete čas na testování nebo na integraci. Oprava této chyby je cennější než jakýkoli obecný vzorec.<br>
<br>
<br>
<br>
Další pastí je verzování samotného kódu podle data, nikoliv podle sémantické verze. Pokud přidáváte nové funkce, ale zároveň měníte staré, zvyšte major verzi. Pokud jen opravujete chyby, zvyšte minor verzi. Pokud měníte jen interní detaily, zvyšte patch. Toto pravidlo musí být napsané v dokumentaci projektu a každý člen týmu ho musí dodržovat. Bez toho se rychle stane, že dvě verze knihovny mají stejné číslo, ale různé chování, což je nejhorší možný scénář.<br>
<br>
<br>
<br>
Když nasadíte měření, buďte opatrní na falešně pozitivní výsledky. Testy, které jen spustí kód bez ověření výstupu, uměle zvyšují pokrytí. Kontrolujte, že každý test obsahuje aserce (např. assertEquals). Bez nich je pokrytí k ničemu. Doporučuji také měřit pokrytí během CI, nikoli jen lokálně, aby bylo číslo standardizované. Typická chyba začátečníků je měřit pokrytí až po proběhnutí všech testů, ale to neukáže, co se stane při selhání. Ideální je měřit pokrytí po každém testu zvlášť a agregovat výsledky podle potřeb.<br>
<br>
<br>
<br>
První kroky: automatizace a verze Začněte s automatizací opakovaných úkonů. Nejdřív zmapujte, jak probíhá nasazení aplikace dnes. Pokud se dělá ručně pomocí příkazů na serveru, zapište všechny kroky do skriptu. Tento skript pak uložte do verzovacího systému a postupně ho vylepšujte. Stejně tak začněte verzovat konfigurace a infrastrukturu – popis prostředí by měl být v kódu, ne v dokumentu. Tím získáte možnost kdykoli reprodukovat stejné prostředí pro testování i produkci.<br>
<br>
<br>
<br>
Jak měřit pokrytí, aby dávalo smysl Základní metrikou je řádkové pokrytí, které říká, kolik řádků kódu bylo spuštěno při běhu testů. Tento údaj získáte snadno pomocí nástrojů jako Istanbul pro JavaScript nebo JaCoCo pro Javu. Ale pozor na past: 100% řádkové pokrytí neznamená, že je kód bez chyb. Mnohem důležitější je pokrytí větví, které ověřuje, zda byly testovány obě cesty v podmínkách (true i false). Pokud máte složité podmínky, sledujte i pokrytí podmínek, které kontroluje jednotlivé výrazy v logických operátorech. Pro praktické použití doporučuji kombinovat řádkové a větvové pokrytí, protože řádkové může snadno maskovat netestované větve.<br>
<br>
<br>
<br>
Při práci s debuggerem se nebojte použít breakpointy místo tisku proměnných do konzole. Moderní IDE vám umožní procházet kód řádek po řádku, sledovat hodnoty v reálném čase a podmíněně zastavit běh. To je zvlášť užitečné při hledání logických chyb. Zároveň si dejte pozor na automatické formátování: pokud používáte nástroj jako je Black, nastavte jej tak, aby nesahalo do kódu proti vaší vůli. Je lepší formátovat vědomě než nechat IDE měnit strukturu bez vašeho vědomí, což vede ke zbytečným změnám v repositáři.
