Odhad času bez skrytých činností: proč realita neodpovídá plánu

Dalším úskalím je podceňování oprav chyb a technického dluhu. Ve stávajícím kódu se při implementaci nové funkce často objeví problém, který nesouvisí s vaším úkolem, ale musí se vyřešit, aby vše fungovalo. Mějte v odhadu vyhrazenou dobu na „nečekané ladění", která pokryje i tyto situace. Dobrým pravidlem je rozdělit práci na dílčí kroky a každý z nich ohodnotit dvěma čísly: optimistickým a pesimistickým. Výsledný odhad pak nechte mezi těmito hodnotami, blíže k pesimistickému konci.

Nakonec si osvojte zvyk testovat své vlastní rozhraní jako uživatel – ne jako vývojář. Vypněte vývojářské nástroje, zkuste aplikaci používat bez znalosti kódu. Klikněte na všechno, co vypadá klikatelně, a sledujte, co se stane. Najdete tak desítky drobností, které by vám jinak unikly. Až budete příště předávat práci, projděte si ji z pohledu někoho, kdo vidí aplikaci poprvé. Tohle je nejlevnější způsob, jak zlepšit kvalitu vašeho UI/UX – a výsledek ocení jak klienti, tak koncoví uživatelé.

Nejdřív si ujasněte, co budete verzovat. Webový projekt obvykle obsahuje zdrojové kódy, šablony, styly, skripty a konfigurační soubory. Do verzování nepatří vygenerované soubory, jako jsou minifikované CSS nebo JavaScript, cache, nahrané obrázky ani lokální konfigurace s hesly. Pro tyto soubory si připravte seznam ignorovaných souborů hned na začátku. Pokud ho nevytvoříte, budete do historie ukládat balast, který znepřehlední každý diff a zpomalí práci s repozitářem.

Častou chybou je plánovat úkoly těsně za sebou bez rezervy na přepínání kontextu. Když programátor přechází mezi dvěma úkoly, mozek potřebuje čas na obnovení souvislostí. Stejně tak schůzka uprostřed dne rozdělí práci na dva kratší bloky, které jsou méně efektivní než jeden souvislý celek. Pokud víte, že vás čeká porada, naplánujte si práci na menší celky, které lze dokončit mezi schůzkami. Do odhadu pak zahrňte také čas na zápis poznámek nebo předání informací kolegům.

Jak vyčíslit neviditelné, když nemáte data z minulosti Prvním krokem je rozlišit činnosti, které jsou přímo spojené s úkolem, a ty, které jsou jen jeho okolím. Například psaní nové funkce je přímá práce, ale její integrace do stávajícího systému, konfigurace testovacího prostředí nebo ladění rozhraní s jiným týmem jsou skryté náklady. U každého úkolu si položte otázku: co musí být hotové, aby funkce fungovala v ostrém provozu? Seznam těchto činností si napište a odhadněte čas na každou z nich zvlášť. Klíčové je nepodcenit opakovanou práci – pokud úkol vyžaduje změny ve více částech systému, počítejte s časem na synchronizaci a testování všech variant.

Na závěr si dejte pozor na přehnané množství pluginů. Instalace desítek rozšíření může zpomalit prostředí a způsobit konflikty. Vybírejte jen to, co skutečně využijete, a pravidelně kontrolujte, která rozšíření jsou aktivní. Pokud si osvojíte práci s klávesovými zkratkami a využijete vestavěné funkce, zjistíte, že většinu úkolů zvládnete bez zbytečných přídavků. Rozhodnutí o IDE by nemělo být jednorázové – po půl roce práce se vyplatí znovu vyhodnotit, jestli vám nástroj stále vyhovuje, a případně přejít na efektivnější řešení.

Pokud se vám první pozice nelíbí, neunáhlujte se s výpovědí. Zkuste vydržet alespoň rok – získáte tím reálné zkušenosti a lepší vyjednávací pozici. Ale pokud je prostředí toxické nebo se vůbec nerozvíjíte, je na místě změna. Před odchodem si ale zmapujte, co jste se naučili, a použijte to v dalším kole hledání. První práce není o tom, hned najít ideál, ale o tom, postavit se na nohy – a to se vám při správné přípravě rozhodně podaří.

A co testy, které selhávají jen občas? To je nejhorší druh chyby – nekonzistentní selhání. Nejčastěji za tím stojí sdílený stav, časová závislost (např. použití DateTime.Now) nebo pořadí testů. Řešením je eliminovat všechny tyto faktory. Časové hodnoty vkládejte jako parametr, ne jako pevnou hodnotu uvnitř metody. Pokud testujete něco, co závisí na aktuálním čase, nechte si čas předat nebo použijte injektovatelné hodiny. Jinak se test stane nedeterministickým a vy ho budete muset opravovat častěji než samotný kód.

Když začnete psát jednotkové testy v C# s NUnit, první věc, kterou objevíte, je, že samotné psaní testů není to nejtěžší. Největší úskalí přichází ve chvíli, kdy se testy začnou navzájem ovlivňovat a vy ztrácíte přehled o tom, co vlastně testujete. Typická chyba začátečníků? Sdílení stavu mezi testy. Pokud použijete statickou proměnnou, která se mění v jednom testu a ovlivní výsledek druhého, přestanou být testy izolované. A izolace je základní princip, bez kterého se jednotkové testy mění v noční můru.