Jak realisticky odhadovat délku softwarových projektů

Na co si dát pozor: nepište testy jen pro pokrytí kódu – pokrytí 80 % je k ničemu, pokud testujete jen triviální větve. Zaměřte se na rizikové části aplikace. Také se vyvarujte testovacích dat, která jsou závislá na pořadí spuštění. Každý test by měl fungovat samostatně a připravovat si vlastní data. A pokud vaše end-to-end testy selhávají náhodně, nestrkejte hlavu do písku – opravte příčinu, jinak ztratíte důvěru v celou sadu.

Když už víte, čím přispějete, nastudujte si, jak projekt funguje. Přečtěte si soubory jako CONTRIBUTING, README a případně i dokumentaci k architektuře. Zjistěte, jak se spouští testy, jaký se používá styl kódu a jak se píší commit messages. Pokud máte jakýkoli dotaz, zeptejte se v diskuzi nebo na oficiálním komunikačním kanálu – je lepší se zeptat předem než později předělávat půl práce.

Další pastí je implicitní konverze typů. Pokud máte sloupec VARCHAR a porovnáváte ho s číslem, databáze často provede konverzi na každém řádku, což opět znefunkční index. Dbejte na to, aby typy v podmínkách odpovídaly typu sloupce.

Před nasazením NoSQL si udělejte malý test. Navrhněte, jak byste řešili tři nejdůležitější dotazy vaší aplikace v relační databázi a v NoSQL. Porovnejte, který model je jednodušší na implementaci a údržbu. Pokud zjistíte, že v NoSQL musíte data ukládat redundantně a složitě synchronizovat, je pravděpodobně lepší zůstat u klasického SQL. Na druhou stranu, pokud vaše aplikace potřebuje škálovat na desítky tisíc zápisů za sekundu a data nevyžadují složité vztahy, NoSQL může být správná volba.

Při práci na více feature větvích také vždy synchronizujte svůj lokální repozitář s originem, ale ne jen jednou na začátku. Průběžně si stahujte změny z mainu a rebasujte svou větev. Můžete si nastavit automatický fetch, ale raději si na to udělejte zvyk. Klíčem je, aby vaše větev nebyla nikdy příliš vzdálená od mainu. Pokud na ní pracujete déle než týden, zvažte, zda nemá smysl rozdělit ji na menší části, které lze dílčím způsobem začlenit.

Při práci s NoSQL se vyvarujte dvěma častým chybám. První je použití NoSQL jen proto, že je „moderní", bez jasného důvodu. Druhým problémem je nedostatečné navržení datového modelu. V NoSQL se často doporučuje ukládat data tak, jak je budete číst (denormalizace). To znamená, že pokud potřebujete zobrazit objednávku s položkami, uložíte je společně v jednom dokumentu, místo abyste je rozdělovali do více tabulek. To vede k výkonnostnímu zisku, ale musíte pečlivě zvážit, jak se data mění, abyste se vyhnuli nekonzistencím.

Tip: Pokud máte testy, které trvají déle než pár sekund, rozdělte je do vrstev podle rychlosti. Rychlé jednotkové testy spouštějte při každém commitu, pomalejší integrační při každém pull requestu a end-to-end testy až před nasazením. Tím získáte rychlou zpětnou vazbu a zároveň nezanedbáte důležité scénáře.

Samotné psaní kódu je jen část práce. Až budete mít něco hotového, vytvořte pull request – tedy žádost o začlenění vašich změn. V popisu jasně napište, co děláte, proč to děláte a jak jste to otestovali. Odkázat na příslušné issue je samozřejmostí. Počkejte na review a berte připomínky jako pomoc, ne jako kritiku. Typická chyba je bránit každou řádku svého kódu nebo naopak mlčet a čekat, až někdo něco řekne. Obě extrémní polohy jsou kontraproduktivní.

Základní princip je jednoduchý: čím nižší vrstva, tím více testů byste měli mít. Jednotkové testy by měly tvořit nejširší základnu – jsou rychlé, stabilní a přesně ukazují, která část kódu selhala. Integrační testy pak ověřují spolupráci mezi komponentami, a měly by jich být desítky. End-to-end testů by mělo být jen minimum – pouze kritické uživatelské scénáře, které nelze pokrýt nižšími vrstvami.

Základním krokem je rozdělení projektu na malé, nezávislé úkoly. Místo odhadu celého modulu „fakturace" odhadněte jednotlivé kroky: návrh databáze, API endpointy, formuláře, testy. Každý úkol by měl být dostatečně malý na to, aby jeho odhad nepřesáhl pár dní. U větších celků hrozí, že zapomenete na skryté závislosti. Doporučuji použít techniku „t-shirt sizes" nebo Fibonacciho posloupnost (1, 2, 3, 5, 8...), která nutí přemýšlet v relativních velikostech, ne v přesných hodinách.

Testovací pyramida není jen módní pojem, ale praktický nástroj, který vám pomůže udržet náklady na testování pod kontrolou a zároveň zajistit vysokou kvalitu kódu. Mnoho týmů ji ale chápe špatně – buď píší příliš mnoho jednotkových testů, nebo naopak spoléhají hlavně na end-to-end testy, které jsou pomalé a křehké. V tomto článku si ukážeme, jak pyramidu skutečně využít v každodenní práci.