Co rozhoduje o tom, zda uspějete v první vývojářské práci?

Základní dělení je mezi permisivními licencemi a copyleftovými. Permisivní licence dovolují kód použít i v uzavřeném produktu, obvykle stačí zachovat informaci o autorství a text licence. Copyleftové licence naopak vyžadují, aby odvozené dílo zůstalo pod stejnou licencí. Rozdíl se neprojeví u samostatně volaného programu, ale u kódu, který se stane součástí výsledného binárního celku. Právě tam vzniká nejvíc sporů.

U velkých datových sad se návrh REST API láme na dvou místech: jak stránkovat a jak filtrovat. Chyby v těchto dvou oblastech se neprojeví při testování s deseti řádky, ale při milionu záznamů shodí databázi nebo vrátí nekonzistentní výsledky. Základem je rozhodnout, zda použijete offsetovou, nebo kurzorovou paginaci, a to ještě předtím, než napíšete první endpoint.

Poslední věc, kterou si napište ještě před prvním commitem: jak poznáte, že je změna bezpečná? Odpověď není „otestujeme to". Odpověď je, že máte sadu příkladů reálných odpovědí z produkce a při každé úpravě modelu je znovu spustíte proti nové verzi. Pokud se výstup liší, máte změnu kontraktu. Tento jednoduchý zvyk odhalí většinu problémů dřív, než si jich všimne klient. A to je přesně to, co odděluje API, které přežije roky, od toho, které se po půl roce přepisuje.

Pravidelné schůzky a měření toku Kanban stojí na dvou pravidelných setkáních. Krátké denní setkání u tabule slouží k tomu, aby si lidé řekli, co blokuje tok. Nemá trvat déle než patnáct minut a nemá se měnit v reportování vedení. Druhé setkání je jednou za dva týdny a věnuje se číslům: jak dlouho karty leží ve frontě, kde vznikají zácpy, kolik jich projde za týden. Sledujte průměrnou dobu od zadání po dodání, ne počet odpracovaných hodin. Právě doba průchodu odhalí, kde metodika nefunguje.

Jak vypadá první měsíc a kde se nejčastěji chybuje V praxi strávíte první týdny čtením existujícího kódu, nastavováním prostředí a opravou malých chyb. Není ostuda trávit hodiny nad konfigurací. Ostudou je nezeptat se, když něco nefunguje, a blokovat tým na dva dny. Zvykněte si psát si poznámky a ptát se konkrétně: „Zkoušel jsem to takto, dostal jsem tuto chybu, co ještě můžu ověřit?" Tím ukážete, že přemýšlíte, ne že jen čekáte na odpověď.

Při návrhu REST API nad velkými datovými sadami se stránkování a filtrování neřeší až na konci, ale hned u návrhu dotazů a indexů. Špatně zvolený způsob stránkování se projeví až ve chvíli, kdy tabulka přeteče cache a databáze začne skenovat miliony řádků. Rozhodnutí mezi offsetovým a kurzorovým stránkováním proto patří k prvním krokům, ne k posledním.

Kanban vypadá jednoduše: pár sloupců, barevné kartičky a limity na rozpracovanou práci. V praxi ale většina týmů skončí u tabule, která se po měsíci přestane aktualizovat. Metodika pro kanban není o nástroji, ale o dohodě, jak tým pracuje. Než začnete cokoli nastavovat, sepněte si na papír, co chcete zlepšit: příliš mnoho rozdělané práce, čekání na schválení, nebo neviditelné priority. Bez tohoto cíle skončíte u estetické tabule bez užitku.

Třetí věc, kterou týmy podceňují, je definice hotového. Nestačí napsat „hotovo". Sepište konkrétní podmínky: kód je otestovaný, dokumentace je aktualizovaná, zákazník potvrdil převzetí. Bez toho se karty vrací ze sloupce hotovo zpět a tabule ztrácí důvěryhodnost. Definice hotového se týká každé karty bez výjimky, i té nejmenší.

První práce v IT není o tom, kolik toho umíte nazpaměť, ale jestli dokážete doručit funkční řešení a nebát se zeptat. Firmy u juniorů nečekají hotové odborníky. Hledají lidi, kteří se učí rychle, čtou cizí kód a umí přiznat, že něco nevědí. Pokud na pohovoru předstíráte znalosti, které nemáte, pozná se to na prvním code review.

Druhým pravidlem je limit rozpracované práce. Ten musí být nižší, než je počet lidí v týmu. Pokud máte pět lidí, nastavte limit tři až čtyři karty v jednom sloupci. Vyšší číslo znamená, že lidé začnou pracovat na všem najednou a nic nedokončí. Limity se týkají sloupců, kde vzniká hodnota, ne fronty čekajících úkolů. U fronty naopak držte počet položek co nejnižší, ideálně jen to, co zvládnete do dvou týdnů.

Nejčastější chybou je zavést kanban shora bez zapojení lidí, kteří práci dělají. Tabule pak odráží přání manažera, ne realitu. Další chybou je příliš mnoho pravidel najednou; začněte se dvěma až třemi a další přidávejte, až se ty první zažijí. Vyhněte se také tomu, aby se karty přesouvaly automaticky podle stavu v jiném nástroji. Ruční přesun nutí tým o stavu přemýšlet. Metodika má sloužit toku práce, ne naopak. Pokud po měsíci tabule nikoho nezajímá, není problém v lidech, ale v tom, že pravidla neodpovídají skutečné práci.