Retrospektiva, která konečně něco zlepší: strukturovaná zpětná vazba
Pozor na častý omyl, že zpětná vazba musí být vždy pozitivní, jinak tým „zraní". Konstruktivní kritika je ale základ zlepšování. Naučte se formulovat výtky jako pozorování bez hodnocení. Místo „neustále měníš zadání" použijte „v posledních třech sprintech se zadání měnilo dvakrát, což posunulo termíny". Vyhnete se tím obviňování a otevřete cestu k řešení. Stejně tak ale neignorujte ocenění – pokud někdo odvedl skvělou práci, řekněte to s konkrétním příkladem, ne jen „díky za práci".<br>
<br>
<br>
<br>
Psaní prvního unit testu často vypadá jako zbytečná komplikace. Dokud projekt roste a vše funguje, testy se odkládají na „až bude čas". Jenže ten čas nikdy nepřijde. Přitom stačí začít s jedním malým testem, který ověří chování jedné metody. Nemusíte pokrýt vše najednou. Cílem je vytvořit si návyk a postupně budovat bezpečnou síť, která vás ochrání před regresemi.<br>
<br>
<br>
<br>
Pokud nedostanete odpověď nebo vás odmítnou, neberte to osobně. Trh je plný firem, které hledají různé typy lidí. Zkuste to znovu, ale poučte se: upravte životopis, dodělejte projekt, naučte se novou technologii. Každý neúspěch je zpětná vazba. Důležité je vydržet a posílat dál. Často se první práce najde přes známé – dejte vědět na sociálních sítích, že hledáte, a nebojte se zeptat v komunitních skupinách. Osobní doporučení má velkou váhu.<br>
<br>
<br>
<br>
Dalším krokem je vytvoření portfolia. Nemusí jít o rozsáhlé projekty – stačí tři až pět menších aplikací, které ukážou, že umíte pracovat s daty, rozhraními a řešit běžné problémy. Důležité je, aby každý projekt byl dokončený a nasazený na veřejném hostingu. Personalisté i techničtí vedoucí ocení, když si můžou aplikaci vyzkoušet online, ne jen prohlížet kód na GitHubu. Nezapomeňte ke každému projektu přidat krátký popis: co řeší, jaké technologie používáte a jaké výzvy jste překonali.<br>
<br>
<br>
<br>
Začněte u jednotkových testů. Ty by měly pokrývat všechny klíčové výpočty, validace a rozhodovací logiku. Píšete je ve stejném jazyce jako aplikaci, nejlépe přímo u třídy nebo funkce. Snažte se, aby každý test ověřoval jednu konkrétní věc a nezávisel na databázi, souborech ani síti. Typická chyba je testovat přes HTTP endpoint, když stačí zavolat metodu přímo. Tím testy zpomalíte a znejistíte – pak vám stačí, že se změní jeden JSON klíč, a spadne vám deset testů, které přitom ověřují úplně jinou logiku.<br>
<br>
<br>
<br>
Když pyramidu postavíte správně, získáte rychlou zpětnou vazbu při každém commitu. Vyzkoušejte si to na malém projektu: začněte s jednotkovými testy pro kritickou logiku, přidejte pár integračních testů pro napojení na databázi a teprve poté jeden dva end-to-end testy pro hlavní flow. Uvidíte, že se vám bude lépe refaktorovat a přidávat nové funkce, aniž byste se báli, že něco rozbijete. Pamatujte: dobrá testovací pyramida není o kvantitě testů, ale o tom, kde je umístíte.<br>
<br>
<br>
<br>
Typická chyba, kterou v praxi vidím, je snaha pokrýt end-to-end testy úplně všechno. Pak se stane, že jeden test trvá dvě minuty a celá sada půl hodiny. Vývojáři čekají na výsledek, ztrácí kontext a testy se stávají spíše brzdou než pojistkou. Řešení je jednoduché: použijte pravidlo 80/15/5 – 80 % jednotkových, 15 % integračních a 5 % end-to-end testů. Většinu funkcionality totiž ověříte rychlými a spolehlivými testy na nižších vrstvách, a pomalé testy si necháte jen na nejdůležitější scénáře.<br>
<br>
<br>
<br>
Na závěr si ověřte, že každý akční krok má smysl pro celý tým, ne jen pro někoho. Pokud někdo navrhne „nový plugin do našeho nástroje", zeptejte se, jak to pomůže ostatním a co to obnáší za práci navíc. Dobrá retrospektiva končí tím, že každý rozumí, co se bude dít dál a proč. A hlavně – dodržte to. Nic nezabije důvěru v retrospektivu rychleji, než když se naplánované kroky nikdy neuskuteční. Struktura je jen nástroj, ale bez pravidelného vyhodnocování zůstane prázdnou formalitou.<br>
<br>
<br>
<br>
Typickou chybou juniorů je, že se přihlašují na pozice, na které nemají dovednosti, a pak jsou zklamaní z odmítnutí. Místo toho se zaměřte na firmy, které nabízejí juniorské programy nebo stáže. Tyto pozice jsou navržené tak, aby vás doučily a měly s vámi trpělivost. Pokud takovou pozici neseženete, zkuste menší firmy nebo startupy, kde je větší šance, že dostanete šanci i s menšími zkušenostmi. Nezapomeňte také na networking – účastněte se setkání vývojářů, hackathonů nebo online komunit. Osobní doporučení často otevře dveře, které by jinak zůstaly zavřené.<br>
<br>
<br>
<br>
Než začnete psát test, vyberte si jednoduchou funkci – ideálně čistou, bez závislostí na databázi, souborech nebo síti. Dobrým kandidátem je metoda, která přepočítává cenu s DPH, validuje e-mail nebo formátuje datum. U takové funkce snadno nastavíte vstup a ověříte výstup. Vyhněte se na začátku metodám, které pracují s globálním stavem nebo volají statické služby. To přináší zbytečné komplikace a testy budou křehké.