Jednotná konfigurace projektu: co se stane, když ji podceníte

Typickou chybou je, že konfigurace existuje, ale nikdo ji nečte. Když do týmu přijde nový člověk, často si nastaví prostředí podle sebe a až při prvním pushi zjistí, že něco nefunguje. Tomu předejdete tím, že do dokumentace projektu přidáte krátký návod, jak prostředí nastavit, a do CI přidáte kontrolu, která ověří, že se konfigurace shoduje. Pokud nějaký nástroj nejde snadno nakonfigurovat, zvažte, jestli ho vůbec potřebujete.

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.

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í.

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.

Jak zajistit, aby se konfigurace skutečně používala Nejdůležitější je, aby byla konfigurace vynucená automaticky, ne jen doporučená. Zaveďte pre-commit hook, který spustí kontrolu stylu a formátování, a pokud selže, commit se nepovede. Ujistěte se, že je soubor s pravidly součástí projektu od prvního dne, ne až po měsíci, kdy se nasbírají špatné návyky. Dále sjednoťte verze nástrojů – pokud každý má jinou verzi linteru, výsledky se liší. Používejte lockfile pro závislosti a konfigurace, ať je reprodukovatelnost zaruč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.

Při samotné retrospektivě pak dejte prostor každému členovi týmu, a to rovnoměrně. Tichý kolega, který mlčí, protože ho přerušil extrovert, má často nejcennější postřehy. Vyhraďte proto pevný časový limit, třeba pět minut na osobu, a během něj nikdo neskáče do řeči. Pokud se objeví ostrá kritika, nechte ji zaznít a hned se zeptejte: „Co by podle tebe pomohlo?" Tím se vyhnete tomu, aby se schůzka proměnila v diskuzi o pocitech bez konkrétního výstupu.

Začněte tím, že si v každém IDE nebo editoru definujete pro každý jazyk samostatný profil nebo workspace. Většina moderních nástrojů to umožňuje přes takzvané workspace settings. Určete pro každý jazyk vlastní formátovač, linter a pravidla pro zalamování řádků. Například Python nebude tolerovat stejnou šířku řádku jako JavaScript. Pokud toto nastavíte globálně, bude se vám kód v každém jazyce formátovat jinak, než tým očekává. Typická chyba je mít pro všechny soubory jednotný formát, což vede k nekonečným diskuzím v code review.

Než začnete rozesílat životopisy, zkuste si odpovědět na tři otázky: Jaký problém řeším? Proč mě baví právě toto? Jakou technologii bych si vybral pro nový projekt a proč? Pokud nedokážete odpovědět jasně, vraťte se k učení. Typický začátečník si myslí, že musí znát všechno – od mikroservisů po strojové učení. Ve skutečnosti stačí jeden jazyk, jeden framework a jedna oblast, ve které se stanete opravdu dobří. Hluboká znalost jedné věci je na pohovoru vždy přesvědčivější než povrchní přehled o všem.

Jak zvládnout přepínání mezi jazyky bez ztráty kontextu Vyzkoušejte funkci automatické detekce typu souboru podle přípony a podle obsahu. IDE si sám přepne zvýrazňování syntaxe a načte příslušné pluginy. Důležité je ale nastavit i klávesové zkratky pro přepínání mezi jednotlivými jazykovými režimy. Například když upravujete soubor .tsx, měl by se vám aktivovat linter pro TypeScript a React. Když otevřete soubor .py, měla by se vypnout kontrola typů z TypeScriptu a zapnout Pythoní linter. Většina nástrojů to umí, ale je potřeba si to vědomě nakonfigurovat. Bez toho se vám stane, že vám IDE hlásí chyby v souborech, které zrovna nespouštíte, a vy ztrácíte čas.