Když pokrytí testy klame: měřte správně, ať nemáte falešný pocit jistoty

Jak vybrat první úkol, který nezpůsobí konflikt Ideální první příspěvek je malý, jasně ohraničený a má označení „good first issue" nebo „help wanted". Pokud takové označení nevidíte, hledejte problémy v dokumentaci, překladech nebo jednoduché opravy chyb. Vyhněte se velkým refaktorům, změnám architektury nebo příspěvkům, které mění chování celé aplikace. Takové změny vyžadují hlubokou znalost kódu a často končí nekonečnými diskusemi. Místo toho se soustřeďte na konkrétní, dobře popsaný problém, který můžete vyřešit v krátkém čase.

Když se řekne databáze, většině vývojářů se vybaví tabulky s řádky a sloupci, tedy klasický SQL. Jenže moderní aplikace často pracují s daty, která se do pevné struktury nevejdou – třeba s dokumenty, grafy nebo časovými řadami. Právě pro tyto případy existuje NoSQL. Nejedná se o jednu technologii, ale o rodinu databází, které se liší způsobem ukládání i dotazování. Než se do NoSQL pustíte, je důležité pochopit, kdy dává smysl a kdy naopak zvolit osvědčený SQL.

Retrospektiva týmu často skončí u tří vět: „Vše bylo dobré", „Trochu nám to skřípalo" a „Musíme to zlepšit". Příště se pak sejdete s vědomím, že se nic nezmění, a vy i kolegové začnete schůzku vnímat jako nutné zlo. Problém přitom nebývá v tom, že by lidé nechtěli mluvit, ale v tom, že nemají žádný rámec, jak své postřehy formulovat. Strukturovaná zpětná vazba mění chaotickou výměnu názorů v konkrétní akce, které mají šanci přežít až do dalšího sprintu.

Při nasazení na server se často zapomíná na ošetření selhání. Pokud se build povede, ale nasazení selže kvůli výpadku serveru, pipeline skončí chybou, ale co dál? Mějte připravený rollback – buď starší artefakt, nebo skript, který vrátí předchozí verzi. GitHub Actions umožňuje definovat kroky, které se spustí vždy, i když předchozí selže, pomocí podmínky if: always(). To se hodí pro odeslání notifikace nebo pro vyčištění dočasných souborů.

Zachyťte kontext dřív, než se ztratí Nejčastější chybou je, že začnete od řešení. Někdo řekne „Zvyšte odhady" a všichni přikyvují, jenže nikdo neví, proč vlastně odhady selhávají. Místo toho nechte každého člena týmu napsat tři věty o tom, co se dělo v uplynulém období, a to před schůzkou. Můžete použít jednoduchou tabulku se sloupci: Co se povedlo, Co se nepovedlo, Co nás překvapilo. Důležité je, aby se popisovaly situace, ne lidé. Teprve když máte fakta na stole, můžete se ptát na příčiny a hledat společná řešení.

Dalším častým úskalím je, že se tým snaží vyřešit deset problémů najednou. Pak se každému věnuje deset minut, nic se nedotáhne a na konci nikdo neví, kdo za co zodpovídá. Vyberte si maximálně tři hlavní témata, která mají největší dopad na týmovou spolupráci, a pro každé z nich určete jednoho vlastníka. Vlastník nemusí problém vyřešit sám, ale je zodpovědný za to, že navrhne první krok a dohodne termín kontroly. Bez tohoto kroku je retrospektiva jen povídáním.

Nezapomínejte ani na kontrolu minulých opatření. Pokud na začátku schůzky nezkontrolujete, co se splnilo, tým rychle ztratí motivaci. Udělejte z toho samostatný bod programu: „Co jsme si minule slíbili a jak to dopadlo?" Když se něco nesplnilo, zeptejte se proč, a buďto to přesuňte do nové akce, nebo to škrtněte. Tento jednoduchý rituál ukáže, že retrospektiva má skutečný dopad, a lidé začnou brát své závazky vážněji.

Na závěr si dejte pozor na to, abyste nesklouzli k hodnocení, ale zůstali u pozorování. Místo „Ty jsi zase nesplnil deadline" řekněte „V úkolu č. 4 došlo ke dvoudennímu zpoždění, co bylo příčinou?" Tento posun od obviňování k analýze umožní otevřenou diskuzi, ze které vzejdou opatření, která tým skutečně přijme. Až příště uvidíte, že někdo začne mluvit o tom, kdo za co může, připomeňte celé skupině pravidlo: zaměřujeme se na proces, ne na osoby.

Pokrytí kódu testy je jedno z nejčastěji špatně interpretovaných čísel ve vývoji softwaru. Mnoho týmů ho bere jako cíl, ale ve skutečnosti jde o nástroj, který má odhalit slabá místa. Základní metrika, která se počítá jako poměr řádků, větví nebo funkcí pokrytých testy k celkovému počtu, vám řekne, kolik kódu se při testech spustí. Neřekne vám ale, zda testy skutečně ověřují to podstatné — jestli kontrolují správné chování, okrajové případy nebo chybové stavy. Proto je třeba měřit nejen počet řádků, ale i kvalitu testů a jejich schopnost odhalit chyby.

Když se rozhodnete přispět do open source, nejčastější chybou není nedostatek znalostí, ale špatný start. Místo abyste se vrhli na první issue, které uvidíte, začněte prozkoumáním projektu. Přečtěte si soubor s pokyny pro přispěvatele, pokud existuje. Většina větších projektů má jasně daná pravidla, jak vypadá dobrý pull request, jak psát commit messages a jaké testy se spouští. Bez této znalosti riskujete, že vaše práce bude zamítnuta, i když je technicky správná.